Treat AI agents as non-human identities

AI agents and MCP setups do more than chat. They hold credentials, call tools and act under your organisation’s name. That makes each one a non-human identity — a machine identity your team must own, vault and rotate.

Treat those non-human identities with the same seriousness you give service accounts. Not as throwaway strings in a config file.

Start free beta · Secrets vault

Related: agent credentials without pasting keys · secrets sprawl in AI teams · AI agent security · stop pasting API keys into AI chat

Agents create identities, not just chats

A chat session ends. An agent that can call APIs does not.

Once a coding tool or agent package can reach GitHub, Slack, billing or your internal APIs, it is acting as something. That something needs an owner, a place for its credentials and a way to change those credentials without rewriting every setup.

If you only govern human logins, you are missing the identities that now do the work.

What non-human identity means for AI teams

In security language, a non-human identity is any credentialed actor that is not a person: a service account, a workload identity, a bot token, an API key tied to a system.

For AI teams the list is growing fast. Agent packages. MCP connections. Shared tool configs. Automation that runs overnight.

NHI security here is not abstract. It is knowing which agents exist, which credentials they use and who can change them. Non-human identity management for AI work means inventory, vaulting and clear ownership — before the next paste into a shared thread.

Machine identity is the same idea with a different label. The point is the same: identities need owners.

Where the secrets actually live

Credentials for these identities rarely sit in one vault. They land where people work:

• Hardcoded values in shared MCP config files

• Tokens pasted into agent packages or skill text

• Keys dropped into chat “just for this run”

• Personal .env copies that outlive the project

Each copy is another place a screenshot, export or fork can expose the value. That is secrets sprawl under another name.

Agent credentials belong in a vault, referenced by name — not in the package body.

What recent MCP incidents show

Recent research and advisories make the pattern concrete.

In mid-September 2026, Hush Security’s State of MCP Configuration research (also summarised at hush.security/state-of-mcp) reviewed roughly 82,000 public MCP configs. About one in eight credential slots held hardcoded secrets. The report frames the risk as non-human identity exposure and argues for vaulting instead of inline secrets.

At the end of September, The Hacker News covered a flaw in the official MCP Python SDK: a malicious MCP server could steal OAuth client secrets, codes and PKCE material. Fixes landed in Python SDK 1.30.0 and 2.2.0.

In early October, al-ice.ai summarised three further MCP SDK advisories (dated around 2–3 Oct 2026). Cross-origin redirects could leak custom API-key headers and OAuth bodies such as refresh_token and client_secret. Separate advisories covered experimental task-session issues. Public GitHub advisories include GHSA-6prh-2h8m-c8cw, GHSA-5h93-6whr-6q8j and GHSA-22jm-h49p-29qw.

None of this means every MCP server is unsafe. It does mean credentials in configs and client paths are a live NHI problem — not a theoretical one.

Owners, rotate-by-overwrite and no silent copies

Every agent credential should have an owner. Someone who can say which systems it unlocks and when it last changed.

Rotation should be overwrite, not archaeology. Put the new value in the vault under the same name. Packages that only hold the name keep working. Hunting chat pastes and exported packages is what you do when sprawl already won.

Joyst’s vault does not add expiry policies or scheduled auto-rotation. You rotate by overwriting the named secret when you need to. Values cannot be read back after write. That is deliberate: the vault stores the value; people and packages refer to the name.

A private catalogue beats a public list

Public MCP discovery keeps growing. Observatory-style counts around early October 2026 put the official MCP Registry near 39,000 servers (MCP Registry Observatory; see also agent economy registry stats).

A public list is useful for finding servers. It is not an approve-list for your company.

A private MCP catalogue is where your organisation registers the servers it may use, syncs tools, adds notes and sets folder permissions. People still connect those endpoints in the AI tools they already use. Joyst does not sit in the live call path as a gateway today.

For build-time framing around agents, see AI agent security. For MCP security framing, see MCP security. For a practical checklist, see MCP security best practices.

Vault the value; reference the name

Store working credentials in a secrets vault. Refer to them by name in skills, prompts and agent packages.

Agent packages should carry secret name hints — never the credential values. Link catalogue MCP endpoints, not tokens.

When a workflow calls an approved service, substitution happens only on outbound HTTP requests, in the headers or body. The call returns status and body only, never the secret value.

How-tos: add and use secrets and controlled substitution.

This vault is for AI work. It sits alongside infrastructure secrets managers. It does not replace them. Comparison angle: secrets management tools for AI agents.

Soft path to the vault and catalogue

If agents and MCP configs still carry hardcoded secrets:

1. Stop adding new keys to configs, packages and chat.

2. Inventory which non-human identities your AI workflows actually use.

3. Move working values into the vault; refer by name.

4. Register approved MCP servers in a private catalogue.

5. Overwrite anything that already leaked into a shared thread or public config.

Primary next step: the secrets vault. Then the MCP catalogue and agents overview.

FAQ

Is a non-human identity the same as a service account?

Often overlapping, not identical. A service account is one common form. AI teams also create identities through agent packages, MCP configs and API keys tied to tools. The shared need is ownership, vaulting and rotate-by-overwrite.

Does Joyst replace our secrets manager?

No. Infrastructure tools protect production systems. Joyst’s vault holds credentials for AI workflows — skills, agents and MCP setups — with name-based references. Use both where each fits.

Does Joyst detect shadow AI?

No. Start from an inventory of skills, prompts, MCPs and secrets you already approve. Joyst does not scan the organisation for unapproved AI tools.

Does Joyst sit in the live MCP call path?

No. The catalogue registers and documents servers. Host clients connect the endpoints. Joyst does not proxy live third-party MCP tool calls today.

Start free beta · Book a demo · Pricing