Editor's note: in July 2026, four months after publication, I graded every claim in this piece against what the ecosystem shipped. Read the follow up. Sentences below that cite events after February 2026 are marked as editor's notes, and figures quoted from two industry surveys that could not be verified on the publishers' sites have been replaced with qualitative statements.

We're deploying autonomous systems that can read files, call APIs, send messages and execute code, and a shared account alone cannot tell us which agent performed an action.

Shared credentials make it harder to distinguish agents and their human sponsors. This is an architectural risk, not a prevalence estimate: an earlier version cited a CSA survey that we could not locate, so those survey claims have been removed.

A useful review starts with the identity presented on each request, the authority delegated to it and the record of the resulting action.

The three identity models that don't fit

Most identity patterns in production were designed around humans, services or narrowly scripted bots. AI agents reuse pieces of those models, but their dynamic tool use and delegated authority expose gaps between them.

Human sign-in often includes interactive consent or an MFA challenge. OAuth also supports unattended clients; the missing context is which agent task the resulting credential is being used for. An AI agent operates autonomously. In unattended workflows, a human does not approve each action at execution time.

Services commonly authenticate with API keys, client certificates or workload identities. They operate behind stable contracts and permission boundaries. AI agents are different because they can dynamically compose tools and actions from context, and the underlying model is nondeterministic. The same agent, given the same tool, may take different actions depending on its context, prompt, conversation history and the model's probabilistic output. A static permission set either grants too much for most tasks or too little for some.

Bots are automated scripts with narrow, predefined behavior. A CI bot runs a pipeline. A Slack bot responds to commands. Their actions are enumerable. An AI agent's actions are not. They emerge from the interaction between the model, the user's request, available tools and the agent's context window.

A shared API key identifies a credential holder, not necessarily the agent instance or person responsible for an action. Workload identities and delegated tokens can improve attribution when the application validates and records them.

The delegation problem

When a human asks an AI agent to "summarize my recent emails," a chain of delegation begins that needs explicit scope and attribution.

The user delegates authority to the agent. The agent connects to an MCP server that provides email access. The MCP server calls an API on the user's behalf. At each hop, a trust decision is made, and each needs a scope enforced by the receiving service.

OAuth 2.0 has a concept of delegation: a user authorizes a client application to act on their behalf, with specific scopes. An agent runtime can be an OAuth client, but OAuth scopes alone may not express all task-specific constraints. The runtime may use a registered client and predefined scopes while selecting actions dynamically. It's a runtime that decides which tools to call, with which parameters, based on a natural language conversation.

An individual Internet-Draft, OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents by Thilina Shashimal Senarath and Ayesha Dissanayaka of WSO2, explored this gap in 2025 by extending OAuth authorization code delegation for AI agents. Revision 02, dated August 26, 2025, proposed the following flow:

  1. The client application initiates an authorization request with a requested_actor parameter.
  2. The user authenticates and explicitly consents to the agent acting on their behalf.
  3. An authorization code is issued.
  4. The agent exchanges this code, along with an actor_token and a PKCE verifier, for a delegated access token.
  5. The resulting JWT contains both the user's identity (sub) and the agent's identity (act), creating an auditable delegation chain.

This is a meaningful proposal, but it is an individual submission with an expiry date of February 27, 2026. It has not been adopted by a working group, it is not an IETF standard and it should not be described as a production MCP capability.

The trust chain across several hops

The delegation problem compounds when agents interact with multiple tools and services. Consider a realistic setup:

one request · three independently authorized serversdelegation chain
1user → agent                    delegates authority
2agent → server A (file system)  reads config → finds database URL
3agent → server B (database)     queries with the URL from server A → obtains the data
4agent → server C (email)        sends the results → data leaves
5three authorizations · one permission set nobody approved
Each server was authorized on its own. No server knows about the others, and the agent is the only entity with full context.

Three MCP servers. Each one was independently authorized. But the agent's behavior across them creates an emergent permission set that nobody approved. The agent can read a file, extract a database connection string from it, query the database and email the results. A data exfiltration pipeline assembled from individually benign tools.

No MCP server in this chain knows about the others. Server C (email) doesn't know that the data it's sending came from Server B (database), which got its connection string from Server A (file system). Without host-level controls or correlated telemetry, none of these servers has enough context to enforce the intended end-to-end data flow.

The browser same-origin policy is a useful analogy for separating origins, but it is not a direct equivalent of tool authorization. MCP hosts can add isolation and per-tool permissions; the protocol alone does not decide how a host combines data and instructions from several servers.

What happens without agent identity

The consequences of this identity gap are already visible.

Attribution becomes harder. A shared credential can identify an account while leaving the specific agent, task and human sponsor ambiguous. Record these separately and bind them to authenticated context.

Investigation loses context. Detection can still use host and network signals, but distinct identities and tool-level records help determine which agent was affected and what authority it used.

You can't enforce least privilege. The principle of least privilege requires knowing who's requesting what. If the agent is authenticated as a shared service account, every agent gets the same permissions. That shared credential alone cannot distinguish "this specific agent, running this specific task, on behalf of this specific user." Additional authenticated context and application-level policy are needed.

Accountability needs more than a login. Reviewers may need the agent instance, accountable owner, model and tool versions, requested action and outcome. A generic service credential does not supply that complete record.

What agent identity should look like

The building blocks exist. They're just not connected yet.

SPIFFE (Secure Production Identity Framework for Everyone) provides workload identity without static credentials. SPIFFE IDs are URIs tied to workloads rather than humans, and they support short lived, automatically rotating credentials. Editor's note: on April 30, 2026 HashiCorp published "SPIFFE: Securing the identity of agentic AI and non-human actors", positioning SPIFFE as the identity framework for agents, with each agent receiving a SPIFFE ID and certificate from a SPIRE server.

SPIFFE models workload identity, and a workload may comprise multiple running instances. Whether an agent receives instance level identity therefore depends on selectors, attestation and registration design. For agent runtimes whose instances carry different context or delegated authority, a more granular identity may be required:

spiffe id · instance levelexample
1spiffe://org.example/ns/production/agent/research-agent/instance/a1b2c3

Not just research-agent, but this specific instance, with its specific context, tools and session.

The individual OAuth draft explored a useful token structure. A JWT with sub (user), act (agent) and azp (client) creates an auditable chain: "Agent X performed action Y on behalf of User Z through Client W." This is the minimum information needed for meaningful audit trails.

A2A adds discovery and security metadata for agent to agent communication. Agent Cards are conventionally published at /.well-known/agent-card.json, and the v0.3.0 release of July 30, 2025 added a signatures field to the Agent Card. With a trusted signing key, a client can verify card integrity and publisher metadata; that signature alone does not prove per call authorization or runtime behavior. Editor's note: A2A v1.0.0, released March 12, 2026, formalized JWS signatures over canonicalized card content in section 8.4 of the specification.

NIST is now working on this directly. On February 17, 2026, NIST's Center for AI Standards and Innovation launched the AI Agent Standards Initiative, which covers agent identity and authorization. Its concept paper, "Accelerating the Adoption of Software and AI Agent Identity and Authorization," invited stakeholder input through April 2, 2026.

The complete agent identity stack

Putting these building blocks together, here is what a production agent identity architecture requires.

  1. Instance identity. Each agent instance gets a unique, cryptographically verifiable identity, via SPIFFE or a similar workload identity framework. This identity is short lived and automatically rotated. It answers: "which specific agent process is this?"
  2. Delegated authorization. When an agent acts on behalf of a user, the delegation is explicit and scoped. A standardized delegation flow would bind user identity, agent identity and permitted actions; the individual draft discussed above shows the shape but has no standing. It answers: "what is this agent allowed to do, and on whose behalf?"
  3. Tool level policy. Each tool invocation is authorized individually, not just the connection to the MCP server. Connecting to a database server doesn't grant blanket query access; the agent is authorized for specific operations. It answers: "is this specific action, with these specific parameters, permitted?"
  4. Cross agent trust. When agents communicate via A2A or similar protocols, both parties still need authenticated transport, trusted identity metadata and an authorization decision for the interaction. Signed discovery metadata is one input, not the complete decision. It answers: "is the agent making this request trustworthy for this specific interaction?"
  5. Continuous audit. Every action is logged with full context: agent instance ID, user delegation, tool called, parameters passed, result returned. Not monthly reviews, but real time monitoring against expected behavior. It answers: "what happened, and does it match expected behavior?"

I have not found public evidence of a broadly deployed stack implementing all five layers end to end. That is a limit of this review, not evidence that such deployments do not exist.

The gap between now and then

Do not infer deployment prevalence from the architecture described here. The previously cited survey editions could not be substantiated consistently; this article now uses documented standards and explicit design examples rather than those adoption claims.

What you can do today

The full stack described above is where the industry needs to go. But you don't need to wait for NIST or the IETF to ship before improving your posture.

  • Stop using shared credentials for agents. If every agent authenticates with the same API key, you have no identity. You have a shared password. Issue per agent credentials, even if it's just unique API keys as an interim step.
  • Record tool decisions and outcomes. Don't just log that an agent connected to a server. Record each tool decision and outcome, with redaction and access controls for sensitive arguments and responses. This is the audit trail you'll need when something goes wrong.
  • Scope tool access per agent. Not every agent needs every tool. If an agent's job is to summarize documents, it doesn't need access to email sending or code deployment tools. Enforce this at the MCP server level or through a control boundary.
  • Pin your MCP server versions. Identity alone does not establish the integrity or behavior of the tools an agent uses. Pin versions, hash tool definitions and alert on changes.
  • Treat agent security like infrastructure security. AI agents are infrastructure now. They deserve the same rigor as your production services: unique identities, scoped permissions, monitored access and incident response procedures.

The standards work is underway: NIST opened its AI Agent Standards Initiative on February 17, 2026, the IETF individual draft on delegated agent authorization is dated August 26, 2025 and SPIFFE is being extended to agent workloads. But your agents are running in production today, and the identity gap exists right now.

References