Non-Human Identity Management for MCP Agents

MCP agents create a structural identity gap: the protocol drops the human user's context at every tool-call boundary, leaving the server with no record of who authorized what. Closing that gap means treating every agent as a first-class non-human identity, with its own lifecycle, its own scoped credentials, and continuous authorization, rather than a borrowed service account standing in for a person who's long gone from the transaction.

Why human identity disappears at every MCP tool-call boundary

A person types a request. An agent picks it up, decides what needs doing, and calls out to an MCP server to reach a tool or a data source. At that moment, the human who started the chain is gone. The MCP server sees an authenticated agent request. It does not see the person who asked for it, and it has no way to know what that person actually approved.

CoSAI's post-RSAC 2026 analysis frames the harder question this creates: who authorized this action, through what chain, and with what scope. In a conventional application, that question barely needs asking. One authenticated caller makes one request, and the identity behind it stays attached the whole way through. MCP breaks that continuity on purpose, by design, every time an agent hops from one server interface to the next. Each interface is a new trust boundary, and each hop can make decisions on behalf of the original caller with nothing written down about what that caller actually agreed to.

The server authenticates something: usually a static API key, sometimes a service account credential. That credential proves the agent is allowed to talk to the server. It proves nothing about the human on whose behalf the agent is acting, what task they delegated, or how far their authorization was meant to extend. None of this is a bug waiting on a patch. It's how MCP routes are built to work, and every section that follows is really about what happens once that gap is left open.

The existing non-human identity estate

MCP agents don't arrive into a clean environment. They land inside a non-human identity estate that was already sprawling and already under-governed, and that's what turns an architectural quirk into an immediate liability. Non-human identities, service accounts, API keys, workload credentials, now outnumber human users by at least fifty to one, and AI agents are the fastest-growing, least-governed group inside that population.

The habits that built this estate are ordinary and hard to break. Developers grant an agent broad permissions to get a prototype running, ship it, and move to the next task without ever narrowing what that agent can touch. Saviynt's 2026 identity security trends report names the pattern as a triple threat: agentic risk, where agents end up acting with elevated administrative privileges that exceed what their own creators hold; a governance deficit, where identities that move at machine speed are still managed through manual, human-speed review cycles; and a visibility gap, where most security leaders cannot say how many agents are active in their environment or what those agents can reach.

Orphaned credentials sit at the center of the problem. A service account outlives the team that built it, or a project ends and nobody revokes the key it depended on, and that account keeps running, invisible, until someone finds it in an incident review. Human identity programs still have entitlement sprawl of their own to sort out. Hand that same unresolved process a population of identities that move autonomously, make their own decisions, and operate continuously, and the failure doesn't just repeat. It compounds it, because the thing being governed now moves faster than the governance built to watch it.

What attackers do when agent identity is absent

The absence of agent identity is the exploitable condition behind incidents already documented in production systems. The clearest pattern is a confused deputy vulnerability: CoSAI describes how an MCP server acting as an OAuth proxy can be manipulated into using another user's credentials to carry out privileged operations it was never meant to authorize. The server's role as an intermediary is the attack surface itself, not some rare misconfiguration found on the margins.

Token pass-through compounds the same weakness. When an MCP server takes a user's OAuth token and forwards it downstream without modification, anything sitting in that chain can impersonate the original user, and the service on the receiving end has no way to tell a passed-through token from one obtained the legitimate way.

These are not edge cases dreamed up in a lab. Trend Micro found 492 MCP servers exposed to the internet with no authentication at all, and CVE-2026-32211, carrying a CVSS score of 9.1, documents an Azure DevOps MCP authentication bypass where API keys and tokens sat accessible without any credential check. A separate analysis covering thousands of MCP servers found more than a third vulnerable to server-side request forgery, with AWS credential theft demonstrated through MarkItDown. None of this requires a sophisticated adversary. You just need an MCP deployment that skipped identity controls the security field has understood for decades, applied now to a protocol that routes around them by default.

Treating agents like service accounts fails, and first-class agent identity requires something different

Reaching for a service account or a borrowed developer credential when you stand up an agent feels like the fast path, but it is the exact decision that produces the governance gap described above. Service accounts were built for static, predictable processes: a scheduled job, a backend integration, something that runs the same way every time and rarely changes shape. Agents are nothing like that. They act autonomously, make multi-step decisions, and chain calls across systems, and a static credential was never designed to scope or constrain that.

A service account also carries no lifecycle tied to the work it's doing. It persists long after whatever task justified it has ended, accumulates permissions nobody remembers granting, and eventually becomes one more orphaned credential sitting in the environment as an active risk. CoSAI's Agentic IAM paper addresses this directly, formalizing the idea that agents need to be treated as first-class identities, distinct from both human users and traditional service accounts, with each agent receiving a unique identity bound to verifiable claims about its code, its model, and the runtime environment it operates in.

So what does a first-class agent identity actually look like in practice? It starts with a unique identifier that belongs to that agent alone, never shared with another agent and never inherited from a human account it happens to be acting for. It needs a named business or technical owner, a real person who can vouch for why the agent exists and what it's meant to do. It needs an approved purpose and a defined trust level set before the agent is ever allowed to run. It needs a documented lifecycle state, so anyone looking at the identity can tell whether it's provisioned, active, suspended, or already deprovisioned. And its credential and expiration details need to tie to that verified instance, not to a template shared across a fleet of agents doing unrelated work.

NHIMG's 2026 analysis adds a further requirement that ties all of this together: a chain of delegation, where every action an agent takes must be cryptographically traceable back to the human who authorized it. Without that chain, an organization doesn't have governance. It has activity it can't explain after the fact.

Microsoft's Entra platform shows what enforcing this looks like at scale, through Agent Identity Blueprints: reusable templates that define the permissions, roles, and governance policies attached to a whole class of agents at once. If you disable a blueprint, every agent identity built from it blocks instantly. Identity infrastructure for agents is moving from an optional add-on to a requirement built into the platform itself, and containment at that speed is only possible once agents are first-class identities to begin with.

The authentication and authorization stack replacing static credentials

A coherent authentication and authorization stack for MCP agents is taking shape through 2026, but much of it still rests on Internet-Drafts, not ratified standards. If you build on this stack, you need to treat the ground as still shifting, not settled.

The MCP specification dated 2026-07-28 is a central piece of that shift. It removes protocol sessions, drops the initialization handshake, and hardens authorization with OAuth 2.1, Resource Indicators, issuer verification, and new extension handling. That makes agent authentication considerably more enterprise-ready, but it also exposes hidden session dependencies and confused-deputy risks that many existing deployments were never built to absorb.

Around that specification, a broader protocol stack is forming. OAuth 2.1 with PKCE handles browser-based agents. JWT bearer assertions cover service-to-service flows. Signed agent identity tokens carry the full delegation chain end-to-end, so a downstream system can see not just who's calling now but who authorized the call at the start.

Token exchange, defined under RFC 8693, directly addresses the confused deputy vulnerability. CoSAI's recommendation on this point is unambiguous: never pass an OAuth token through unchanged. Perform token exchange at every trust boundary instead: it produces a new token scoped to that specific operation and leaves behind an auditable exchange record. SPIFFE and SPIRE solve a related but separate problem, hop traceability at the workload level. A cryptographic SPIFFE ID can travel through the execution chain as the subject or actor inside a token exchange flow, so every hop an agent makes leaves a verifiable record behind it.

Delegation itself needs a hard rule, and the one emerging across these sources is scope narrowing: a child agent may receive the same authority as its parent or less, but never more, simply because work was handed down a chain. Delegation tokens need explicit actor and subject claims so the custody of that authority stays visible at every step, rather than blurring the further it travels from the original request.

None of this is finished standards work. As of these sources, the IETF Internet-Draft on AI agent authentication and authorization, draft-klrc-aiagent-auth-03, was published July 6, 2026, alongside a SCIM profile for AI agents and WIMSE applicability drafts, and none of it has been ratified as an RFC. OAuth 2.1 itself remains an Internet-Draft. Teams building agent identity systems on this stack are building on drafts, and that should shape how much flexibility they build into the implementation.

Credential lifecycle management: provisioning, rotation, and cleanup for ephemeral agents

The Cloud Security Alliance recommends that enterprises run a credential audit before Q4 2026, timed ahead of NIST's planned publication of its AI Agent Interoperability Profile. The audit's job is specific: find every agent or agentic workflow running under shared credentials, service account keys, or IAM roles that were never provisioned for that agent specifically. Each one it finds is both a governance gap and an attack surface already in use.

NHIMG's 2026 analysis lays out five lifecycle phases every agent identity has to pass through: Discovery, Classification, Vaulting, Rotation, Cleanup. The logic behind it is plain. An organization cannot protect an identity it cannot see, so discovery must happen before classification assigns a trust level, before vaulting secures the credential, and before rotation and cleanup keep it from decaying into an orphaned account.

Credentials belong at runtime, not at rest. You should issue them when the agent actually needs them and let them expire automatically afterward. No permanent secret belongs sitting in a prompt, in source code, in an agent's memory, or in a configuration file waiting to be found. A short-lived credential should be tied to four specific things: the verified agent instance using it, the task it was approved for, the resource it's permitted to touch, and the time window it's allowed to operate within. A credential that outlives any one of those four constraints has become a governance gap, whether or not anyone's watching it yet.

Ownership keeps all of this enforceable. Every machine identity needs a human owner who can vouch for why it exists. Where an account has no owner, the default action should be deprovisioning rather than a wait-and-see review.

NHIMG points to metrics that show whether an organization actually has operational control over this process, rather than a policy document describing one: credential rotation success rate, meaning how many credentials rotate automatically versus requiring a human to step in; coverage hygiene, meaning what share of non-human identities actually sit inside a management platform versus turning up only when an audit goes looking; and incident response latency, the time between a breach occurring and it being contained.

What a useful audit trail for agent actions records

Logging that an action happened is not the same as recording who authorized it, and agent audit trails have to answer the second question, not just the first. A useful trail answers six things: who requested the outcome, which agent acted, what authority it used, why the action was allowed, what information influenced the decision, and what changed as a result. If you miss any one of those six, an incident review ends up reconstructing guesses instead of facts.

A shared trace identifier needs to connect the full workflow across every hop an agent takes. Without one, a multi-agent chain leaves behind disconnected fragments of log data scattered across systems, not a sequence anyone could actually reconstruct after something goes wrong.

The CoSAI Agentic IAM paper, approved by the CoSAI Technical Steering Committee on March 20, 2026, formalizes this standard: agents need to be verifiable, auditable identities with lifecycle management, context-aware controls, and risk-based enforcement comparable to what already applies to human and service identities. Agent identity governance is the same discipline the security field already applies to people, extended to a population that now outnumbers them fifty to one and moves at a speed no human-paced process was ever built to track.