Agent Identity

The missing primitive in agent infrastructure.

This page is the detailed case for agent identity as the foundational missing layer in agent infrastructure. For the broader argument about why agents need fundamentally different primitives from humans, see the vision page.

The problem

As AI agents move from chat interfaces into production systems — running asynchronously, using tools, acting on behalf of users — a new class of infrastructure problem emerges. It is not a capability problem. The models are capable enough. It is an authority problem.

When an agent calls an API, writes to a database, sends a message, or triggers a workflow, the systems receiving those actions need to know:

Today, most agent systems cannot answer these questions reliably. Tokens get passed around. Credentials get embedded in prompts. Permissions are granted at setup time and never revisited. There is no audit trail that captures the full chain of delegation.

Credentials vs. identity

There is a critical distinction that most tooling conflates: credentials are how access is exercised; identity is how authority is modeled.

An OAuth token proves that access was granted. It does not tell you which agent is acting, what task it was delegated to complete, whether that task is still in scope, or whether the user who originally granted access intended it to cover this specific action.

Tokens without identity context are powerful and unaccountable — exactly the wrong combination for autonomous systems acting in the world.

What operational identity means for agents

Operational identity is not about naming agents or giving them personalities. It is the data layer that answers, at runtime:

Why everything else depends on it

Agent identity is not one primitive among many. It is the substrate the others run on.

The missing abstraction

Production agent systems require a complete, legible chain:

user → agent → runtime → tool → action

Each arrow in that chain represents a delegation — an authority transfer that needs to be modeled, constrained, auditable, and revocable. Most tooling today models fragments of this chain. Auth providers handle the first link. Secret managers handle credentials. MCP gateways handle tool access. But no layer currently owns the full chain: who is this agent, what was it delegated to do, and does this action fall within that scope?

That abstraction is missing. It is the gap that makes agent systems harder to trust, audit, and safely deploy at scale.

The reframe

The agent primitive stack, reframed with identity at the base:

You can build agents without solving identity. Developers do it every day. But those agents cannot be safely deployed in production, cannot be audited after the fact, cannot have their authority reliably revoked, and cannot participate in multi-agent systems without assuming permissions they were never explicitly granted.

Identity is not a feature to add later. It is the layer everything else is built on.

The scope of the problem

The identity gap is not a niche concern. It sits at the intersection of rapid adoption and unresolved infrastructure.

Gartner projected that by 2028, 33% of enterprise software applications will include agentic AI, up from less than 1% in 2024. That growth curve means millions of agent deployments operating across enterprise systems — each one making authorization decisions, accumulating credentials, and taking actions that need to be auditable. The identity layer is not optional at that scale; it is the precondition for safe deployment.

The OWASP Top 10 for LLM Applications lists Excessive Agency (LLM08) as a top risk: agents performing actions with broader permissions than the task required. This is not a model alignment failure — it is an identity and authorization failure. The agent was never given a mechanism to know what it was actually authorized to do for this specific task.

The framework landscape confirms the gap. As of 2026, none of the major open-source agent frameworks — LangChain, CrewAI, AutoGPT, Semantic Kernel — ship a first-class agent identity primitive. Credentials are passed through environment variables at agent startup. CrewAI's agent definition includes role, goal, and backstory fields — personality identity, not operational identity. There is no task-scoped delegation model in any of them.

The Model Context Protocol (MCP) authorization specification defines an OAuth 2.1-based flow for MCP clients to authenticate with MCP servers. This authenticates the MCP client application — not the specific agent making the request, and not the task it is performing. The spec explicitly defers agent-level identity to the host application. The protocol that is becoming the standard for agent tool access has no task-scoped delegation primitive.

The non-human identity problem predates agents. CyberArk's 2024 Identity Security Threat Landscape Report found that non-human identities — service accounts, API keys, bots — already outnumber human identities in enterprise environments by a ratio of 45:1. Agents are the next order-of-magnitude expansion of non-human identities, with the added complexity that they act autonomously and across system boundaries.

IBM's Cost of a Data Breach 2024 report found that compromised credentials remain the most common initial attack vector, accounting for 16% of breaches. As agents multiply the number of active credentials in enterprise environments — and as those credentials are embedded in prompts, passed through orchestrators, and inherited across delegation chains — this attack surface grows proportionally.

Concrete failure modes

The absence of agent identity is not a theoretical risk. It produces specific, reproducible failure patterns in production systems today.

How analogous problems were solved

The agent identity problem is not novel. It is a new instance of a class of problems that the infrastructure industry has solved before — for services, for workloads, and for delegated human access. The prior art is directly applicable.

The standards landscape

The standards work relevant to agent identity is nascent but real. No single specification addresses the full problem. Several address important pieces.

The closest existing token format is defined by RFC 9068: JSON Web Token Profile for OAuth 2.0 Access Tokens. It standardizes JWT claims for access tokens, including sub (subject), azp (authorized party), and the act (actor) claim defined in OpenID Connect for representing impersonation and delegation chains. These claims are the raw material for agent identity tokens — but no framework currently populates them with agent-specific semantics.

RFC 8693 (OAuth 2.0 Token Exchange) is the most directly applicable standard for the delegation narrowing problem. It defines how a client can exchange one token for a narrower-scoped token, with the exchange recorded in the token's act claim chain. Applied to agents: each time an orchestrator delegates to a subagent, it exchanges its token for a narrower one. The subagent can only act within the scope of that exchange. This is the mechanism the ecosystem needs — it exists as a standard, but no agent framework implements it.

The MCP authorization specification (March 2025 revision) defines an OAuth 2.1-based flow for MCP clients to authenticate with MCP servers. This is a meaningful step: it gives MCP deployments a standard authentication handshake. But it authenticates the MCP client application, not the agent running within it, and not the specific task being performed. The spec explicitly defers authorization policy to the host. Task-scoped agent identity is out of scope for the current MCP auth model.

The SPIFFE Workload API demonstrates how cryptographically attested workload identity can be delivered to processes without static secrets — each workload proves its identity through its execution context, not through a credential it stores. Extending this model to agents running as ephemeral tasks rather than persistent services is the next engineering problem.

Large cloud providers have moved toward dynamic workload identity for compute resources. Google's Workload Identity Federation and Microsoft's Entra Managed Identity both eliminate long-lived credentials for compute workloads by issuing short-lived tokens at runtime. These are the right model — but they target persistent compute resources, not the ephemeral, user-delegated, potentially nested execution model of agents.

What a solution looks like

A complete agent identity layer has three required properties. These are not design preferences — they are the minimum required to close the failure modes above.

These properties are not novel. They are what PKI, OAuth, and service mesh already provide for other actor types. The missing work is applying them specifically to agents: ephemeral, delegated, potentially nested, operating across tool boundaries on behalf of users who expect to remain in control.

Reading

References spanning the core argument, relevant standards, security research, framework gaps, and analogous solved problems: