When a human uses an application, identity is straightforward. They authenticate through a login screen, receive a session, and every action they take is attributed to their account. The entire identity infrastructure of the modern web—OAuth, OIDC, SAML—was designed for this model: a human at a keyboard, proving who they are.
AI agents break this model fundamentally. An agent isn’t a user. It can’t click a consent screen, complete a CAPTCHA, or approve an OAuth redirect in a browser. It operates autonomously, often on behalf of a user who isn’t present. It may chain through multiple tools, each requiring different credentials. And it may need to prove not just its own identity, but the identity of the user it represents, the organization it belongs to, and the specific permissions it’s been granted.
Enterprise identity for agents isn’t a configuration problem. It’s an architecture problem.
The three identity questions
Every agent interaction raises three distinct identity questions that traditional authentication conflates into one:
Who is the agent? The agent itself is a software component that needs its own identity—separate from the user it serves and the platform it runs on. In production, you may have dozens of agent instances running simultaneously. You need to know which specific agent is making a request, what version it’s running, and what capabilities it’s been granted.
Who is the user? When an agent acts on behalf of a human, the downstream system needs to know which human. Not just for authorization, but for audit trails, data scoping, and compliance. The agent’s actions must be attributable to a specific person, even when that person isn’t present.
What is the agent allowed to do? The intersection of the agent’s capabilities and the user’s permissions determines what should actually happen. An agent with access to the CRM, acting on behalf of a user who only has read permissions, should not be able to modify records—regardless of what the agent’s own credentials allow.
Traditional OAuth flows answer one of these questions well (who is the user?) but struggle with the other two.
Why OAuth alone falls short
OAuth 2.0 and its successor OAuth 2.1 were designed for a specific interaction pattern: a user delegates limited access to a third-party application through an interactive browser flow. This works when the user is present to grant consent. It breaks down in several agent-specific scenarios:
Unattended operation. Agents run continuously, processing tasks at 3 AM when no user is available to re-authenticate. OAuth tokens expire. Refresh tokens have limits. The agent needs credentials that work without human interaction, but with clear attribution to the human who authorized the work.
Multi-hop delegation. An agent calls a tool server via MCP, which calls an external API, which triggers a webhook back to another service. Each hop crosses a trust boundary. OAuth wasn’t designed for credential chains that span four or five services—the original token’s scope and audience don’t propagate cleanly through intermediaries.
Dynamic tool selection. An agent discovers at runtime that it needs to call a tool it hasn’t been pre-authorized for. Traditional OAuth requires pre-registration of scopes and redirect URIs. An agent that dynamically selects tools from an MCP registry can’t pre-register for every possible integration.
Machine-to-machine context. When two agents communicate via A2A protocol, there’s no user in the loop at all. Both parties are software. OAuth’s user-consent model doesn’t apply, but you still need mutual authentication, authorization, and audit.
The identity architecture
Production agent identity systems layer multiple mechanisms to address these gaps:
Client credentials for agent identity
OAuth 2.1’s client credentials grant provides machine-to-machine authentication without user involvement. The agent authenticates with its own client ID and secret (or certificate) and receives a token scoped to its own permissions. This establishes the agent’s identity as a first-class entity.
POST /oauth/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
&client_id=agent-order-processor-prod
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=eyJhbGciOiJFUzI1NiIs...
&scope=orders:read orders:update
The critical detail: client credentials authenticate the agent, not the user. For operations that need user context, you need an additional layer.
Token exchange for delegation
RFC 8693 (OAuth 2.0 Token Exchange) enables the delegation chain that agents require. An agent holding its own credentials can exchange them—along with proof of user authorization—for a new token that represents “agent X acting on behalf of user Y.”
POST /oauth/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=eyJ...user_token...
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&actor_token=eyJ...agent_token...
&actor_token_type=urn:ietf:params:oauth:token-type:access_token
&scope=orders:read
The resulting token carries both identities. Downstream services can enforce policies like “this agent can read orders, but only for customers assigned to this user.” Audit logs record both the human principal and the agent that executed the action.
Workload identity with SPIFFE
For agents running as containerized workloads in Kubernetes or cloud environments, SPIFFE (Secure Production Identity Framework for Everyone) provides cryptographic identity without secrets management. Each agent workload receives a SPIFFE Verifiable Identity Document (SVID)—an X.509 certificate or JWT that attests to the workload’s identity based on its runtime context.
| Identity Method | Best For | Credential Type | Rotation |
|---|---|---|---|
| Client credentials | Registered agent applications | Client secret or JWT assertion | Manual or scheduled |
| Token exchange | User-delegated agent operations | Composite token (agent + user) | Per-session |
| SPIFFE/SPIRE | Containerized agent workloads | Auto-rotated X.509 or JWT SVID | Automatic (minutes) |
| Mutual TLS | Service mesh agent communication | X.509 certificates | Automatic |
SPIFFE’s advantage for agents is automatic credential rotation. SPIRE (the SPIFFE Runtime Environment) issues short-lived certificates—typically valid for minutes, not months—and rotates them without agent involvement. A compromised credential is useful for minutes, not until someone notices and revokes it.
MCP’s authorization model
The Model Context Protocol addresses agent authentication for tool connections specifically. As of the 2025-11-25 specification, MCP defines an OAuth 2.1 framework where the MCP client acts as an OAuth client and the MCP server acts as a resource server. For remote Streamable HTTP connections, the flow is:
- Client discovers the server’s authorization metadata
- Client performs OAuth 2.1 with PKCE to obtain an access token
- Token is included in subsequent MCP requests via the
Authorizationheader - Server validates the token and enforces scopes
This works well for the initial connection, but MCP deliberately doesn’t define how to propagate user identity through the connection, how to handle multi-hop delegation when an MCP server calls another MCP server, or how to scope tool-level permissions beyond what OAuth scopes provide.
Credential scoping patterns
The most dangerous pattern in agent identity is over-provisioned credentials. An agent that receives a broad token—“access all of CRM”—when it only needs to read a single customer record violates least privilege and amplifies the blast radius of any compromise.
Per-tool scoping. Issue credentials scoped to specific tools or operations, not entire services. An agent calling query_orders should receive a token scoped to orders:read, not orders:*. MCP tool annotations can inform scoping decisions—servers can declare whether a tool is read-only or has side effects.
Time-bounded tokens. Agent tokens should expire aggressively. For synchronous tool calls, tokens valid for minutes are sufficient. For long-running tasks, use refresh mechanisms with re-authorization checkpoints. Never issue tokens valid for days to autonomous software.
Context-bound credentials. Bind tokens to the specific context in which they’ll be used—the agent instance, the session, the task. A token issued for “order processing task #4521” shouldn’t be reusable for “customer data export task #4522.”
Down-scoping at each hop. When an agent propagates credentials through a tool chain, each hop should reduce scope, not maintain or expand it. The agent holds a broad delegation; the token it passes to a specific MCP server should be down-scoped to only what that server needs.
The delegation chain problem
In production agentic systems, the delegation chain can become complex:
- User authorizes the agent platform to act on their behalf
- Platform issues credentials to a specific agent instance
- Agent connects to an MCP server with scoped credentials
- MCP server calls an external API on behalf of the original user
- External API triggers a webhook that reaches another service
At each link, the system must answer: who authorized this? What are they allowed to do? And if something goes wrong, who is accountable?
Record the full chain. Every token should carry or reference the complete delegation chain—from the original user consent to the current hop. This is essential for audit compliance in regulated industries.
Enforce consent boundaries. The user consented to a specific scope of agent activity. If the delegation chain reaches a service the user didn’t explicitly authorize, the chain should break—not silently succeed.
Implement chain depth limits. Delegation chains that exceed a defined depth indicate either an architectural problem or a potential attack. Set maximum chain lengths and alert when they’re approached.
Enterprise implementation considerations
Separate agent identity from user identity in your IdP. Agents should be first-class entities in your identity provider—with their own records, credential policies, and lifecycle management—not hacked into user accounts or service accounts that weren’t designed for autonomous software.
Build an agent credential vault. Centralize the secrets, certificates, and tokens that agents use. Integrate with your existing secrets management (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) but add agent-specific policies: automatic rotation schedules, usage monitoring, and revocation triggers tied to anomaly detection.
Plan for credential revocation at agent speed. When a human’s access is revoked, there’s usually a grace period. When an agent’s credentials are compromised, every second counts—an agent can make thousands of API calls per minute. Build instant revocation capabilities into your agent identity infrastructure.
Monitor credential usage patterns. An agent that suddenly requests scopes it has never used, authenticates from an unexpected network, or dramatically increases its API call volume may be compromised. Behavioral baselines for agent credential usage are as important as they are for human accounts—and harder to establish, because agent behavior is more variable.
Design for zero trust. Every agent request should be authenticated and authorized independently, regardless of network location. Agents running inside your corporate network are not inherently trustworthy. Mutual TLS, token validation, and scope checking should apply to every interaction, not just those crossing the network perimeter.
The bigger picture
Agent identity is where the enterprise security model meets the reality of autonomous software. The answer isn’t to abandon OAuth—it’s to layer additional mechanisms on top: workload identity for the agent itself, token exchange for delegation chains, aggressive scoping for least privilege, and comprehensive audit trails for accountability.
The organizations that get this right will build agent systems their security teams can approve and their compliance teams can audit. The ones that skip it—handing agents broad service account credentials and hoping for the best—will learn the hard way that autonomous software with over-provisioned access is a security incident waiting to happen.
Identity isn’t just the first step in agent security. It’s the foundation everything else builds on.