AI Agent Identity and Authentication Patterns

The numbers are stark, and they don't flatter anyone. Okta's September 2025 research found that 91% of organizations are already running AI agents, yet only 10% have a coherent strategy for managing non-human identities. That gap isn't a temporary lag between adoption and governance. It's a structural condition, and security teams that treat it as a maturity problem they'll eventually outgrow are misreading what's actually happening.

Gartner projects that Fortune 500 companies will operate over 150,000 AI agents by 2028, up from fewer than 15 in 2025. The deployment curve is exponential. The governance infrastructure is essentially flat.

Obsidian Security's research quantifies what ungoverned agents do with the access they hold. Agents move 16 times more data than human users, which means a compromise doesn't stay bounded to one session or one system. Roughly 90% of agents carry excessive privileges, typically around 10 times more access than their actual workflows require. An agent that needs to read a single data warehouse table is often credentialed to write across the entire schema. That asymmetry is a precondition for catastrophic lateral movement, not a hypothetical one.

The OWASP Non-Human Identities Top 10, published in 2025, documented 24 million leaked NHI credentials on GitHub that year. Seventy percent of credentials leaked in 2022 were still valid at the time of that report. Long-lived, over-scoped credentials don't expire on their own; they accumulate and remain exploitable across years. Knostic's 2025 research found that only 28% of organizations have the CEO owning AI governance, and only 17% have board-level accountability. The exposure is documented. Organizations are continuing to outrun their own controls, and the margin is widening.

Giving Agents Their Own First-Class Identity

Each AI agent must exist as a distinct, individually registered principal in the enterprise IAM platform. Not a shared service account. Not an extension of a human user's identity. Not a credential shoved into an environment variable during a rushed deployment. First-class means the agent has a documented owner accountable for its behavior, participates in the same access review cadence as human identities, and can be revoked immediately and surgically without touching anything else.

Shared service accounts are the most common failure mode, and the damage is almost always invisible until an incident forces the question. When multiple agents share a single credential, attribution collapses entirely. An action logged against a shared identity tells an auditor nothing about which agent took it, under what task context, or with whose authorization. This isn't theoretical; it's the reason post-incident investigations in agentic environments so often produce inconclusive findings. I've watched forensic timelines dissolve into ambiguity because no one could say with confidence which of four agents made a particular API call. That ambiguity has real operational cost.

Authentication mechanics require a fundamentally different approach than those designed for humans, because agents can't respond to MFA prompts. Cryptographic attestation fills that role: short-lived certificates issued by trusted PKIs, with private keys stored in hardware security modules where operationally feasible, and workload identity federation to bind the agent's identity to the infrastructure it runs on. For API and tool access, agents authenticate using OAuth 2.0 client-credentials grant or token exchange. Reusing a human OIDC SSO flow is not a workaround; it's a liability that will eventually be exploited.

Discovery is also a structural concern. As agent fleets grow, agents need a reliable mechanism for finding and verifying each other before interaction, without resorting to out-of-band credential sharing. The Agent Name Service concept, sometimes called ANS, describes a capability-aware directory that enables structured discovery within a governed perimeter. It hasn't fully landed in production environments yet, but the problem it addresses is already here.

Both Okta, with its AI Agents product reaching general availability in April 2026, and Microsoft, with Entra Agent ID reaching general availability the same month, now treat agent identity as a supported first-class primitive. Agents can be registered, inventoried, and managed alongside human identities within existing enterprise identity platforms. The capability exists in production. Most organizations simply haven't made the decision to use it.

Scoping Credentials So a Compromised Agent Can't Move Laterally

Registration solves attribution. Scoping solves blast radius. These are related but distinct controls, and conflating them is a common architectural mistake with serious consequences.

The primary mechanism is short-lived tokens issued per task or per session. These tokens carry only the permissions required for the immediate subtask, not the full permission set the agent identity is authorized to hold in aggregate. Expiry is tied to the expected duration of the specific workflow, not an arbitrary long time-to-live. No long-lived API keys should appear in agent configuration files, container images, or environment variables. That pattern is exactly what produced 24 million leaked NHI credentials on GitHub.

Scope pinning goes further. Even within a session, the token should be narrowed to the minimum necessary permission for each discrete action. An agent authorized to read from a data warehouse shouldn't carry write privileges simply because the agent identity holds them in aggregate. Most implementations stop at provisioning and consider the work done. That's where things break.

There is also what I'd call the credential-encounter problem, and most architecture discussions skip past it entirely. When an agent retrieves content, whether a document, an email, or a code repository, that content often contains a credential: an API key, an access token, a database password. The naive behavior is pass-through; the agent encounters the credential and uses it. The correct behavior treats any encountered credential as a new intent-declaration event requiring explicit re-authorization. A processing layer should inspect agent-accessible outputs for credential-like patterns and route identified credentials to a secure vault rather than exposing them to the agent's context window.

There's also a forensic dimension to scoping that rarely appears in access-control discussions. A short-lived, scoped token is a precise record of what was authorized at what moment. When an incident occurs, the relevant question isn't just "what happened" but "what was the agent authorized to do at that instant." A scoped token makes that question answerable. A broad, persistent credential makes it unanswerable, and every investigation that starts from that epistemic deficit compounds in difficulty as the chain of events grows longer.

Delegated Authority: Acting on Behalf of a User Without Becoming That User

The delegation scenario is commonplace in agentic workflows. A human user instructs an agent to book a calendar event, file a support ticket, or query a financial database, and the agent needs to carry some of that user's authority to complete the task. How that authority is carried determines whether the interaction is auditable, revocable, and safe.

The wrong pattern is impersonation, and it remains widely deployed. In impersonation, the agent logs in as the user or reuses the user's session token to make requests on their behalf. There is no separate audit trail for agent actions versus user actions; the log shows the user doing something the user never directly did. The user's full permission set is exposed to whatever the agent encounters downstream. Revoking the agent's access requires touching the user's account, which creates operational risk that multiplies quickly at scale.

The correct pattern is constrained delegation via OAuth 2.0 token exchange, defined in RFC 8693. Under this model, the agent receives a token scoped specifically to what the user has consented to for a particular task. The downstream system receives a token carrying both the user's identity and the agent's identity, producing dual attribution in the audit record. The agent can't exceed the user's permissions, and it can't use the user's full permission set without explicit per-scope consent.

The OpenID Foundation's October 2025 whitepaper on identity management for agentic AI identified delegated authority as one of the genuinely open problems at the standards level. The mechanics of token exchange are mature. What remains unresolved is the governance question of how much delegation a user should be able to grant an agent, under what conditions, and who is accountable when the agent exceeds the spirit of that delegation in ways that are technically within scope. None of that unresolved governance work is a reason to delay implementation. The token exchange pattern is available now and represents a substantial improvement over impersonation even without a fully settled standard.

Microsoft's Entra Agent ID implements delegation as a specialized service principal that acquires short-lived tokens only after the user or tenant administrator has consented to the relevant scopes. That architecture is instructive regardless of which identity platform an organization uses, because it demonstrates concretely how the token exchange model maps to production infrastructure.

Identity Chaining Across Multi-Agent Systems and Why It Compounds Risk

Single-agent delegation is tractable. Multi-agent orchestration is where identity problems compound in ways that are qualitatively harder to govern, and where risks that look manageable in isolation begin to interact badly.

The typical scenario: an orchestrator agent receives a task, decomposes it into subtasks, and invokes specialist subagents to handle each. Each subagent calls tools, queries APIs, or invokes additional agents. The original user's delegated authority propagates through this chain, potentially traveling several hops away from the original consent event. A compromised subagent at hop three can affect systems the user never intended to reach, using authority the user never intended to extend that far. The original consent event, which probably involved a human making a reasonable-sounding decision, bears no resemblance to what actually executes downstream.

The Cloud Security Alliance's Agentic Identity Governance Framework identifies non-deterministic behavior, multi-hop delegation, and the need for continuous runtime authorization as the core dimensions that separate agentic IAM from traditional non-human identity management. These three properties in combination are what makes multi-agent chains a distinct governance domain, not simply a scaled-up version of a familiar problem.

The correct design principle is monotonic scope reduction: the effective permission set should never increase as a request moves deeper into a chain. Each agent receives a token scoped to at most what the calling agent held, and typically less, calibrated to the specific subtask.

Three mechanisms must be coordinated to make this work. Token propagation ensures the original delegation token travels with the request, rather than each hop minting a fresh full-scope token. Chain attestation requires each agent to verify the registered identity of the agent that called it, not just the token; a valid token presented by an unregistered agent should not be honored. Audit trail continuity means the log for a multi-agent workflow must reconstruct the entire chain as a single traceable sequence, from the orchestrator through every subagent, every tool invocation, and every data access. A log that records each hop in isolation is forensically useless after an incident, which is also precisely when it will be needed most.

CoSAI Workstream 4 on Agentic Identity and Access Management, which published its framework in March 2026, uses the vocabulary of "trust boundaries" between agents. Security teams should internalize that framing now, because it will appear consistently in vendor documentation and standards references as this area matures.

Enterprises operating multi-agent workflows without chain attestation are operating blind. In regulated environments, that's an audit failure waiting to be discovered. In unregulated ones, it's a liability waiting to materialize.

How MCP Gateways Enforce Identity Policy Across Agent Fleets

The Model Context Protocol has become the dominant mechanism by which agents interact with external tools and data sources. Its adoption creates a specific surface problem: when MCP clients talk directly to MCP servers without a centralized control point, authentication is inconsistent, policy enforcement is per-server and therefore uneven, and audit logs are fragmented or absent entirely. A gateway layer resolves these problems structurally rather than requiring each MCP server to implement its own access controls. In practice, most servers won't.

A properly designed MCP gateway authenticates the agent before any request reaches a tool or API. It enforces role-based access control at the tool level, not just at the server level, which matters because an agent authorized to use a particular MCP server shouldn't necessarily be authorized to use every tool that server exposes. It applies rate limiting and scope constraints per agent identity, and it produces a unified audit log across all agent-to-tool interactions. That unified log is the only practical path to audit trail continuity in a fleet of any meaningful size.

OAuth 2.1 was incorporated into the MCP specification in June 2025, giving compliant gateways a consistent, modern authentication standard to enforce. The MCP roadmap identifies gateway and proxy patterns, enterprise-managed authentication, and audit trails as core production requirements.

Speakeasy's AI control plane operates in this space: a governed distribution layer for MCP servers and AI agents that enforces RBAC tied to existing identity providers, detects shadow agents operating outside the governed perimeter, applies real-time blocking for prompt injection and PII leakage, and surfaces cost and usage telemetry.

Evaluating any gateway in this space comes down to four questions. Does it integrate with the organization's existing identity provider, or does it require maintaining a parallel identity store? Does it enforce RBAC at the individual tool level? Does it produce audit logs capable of reconstructing multi-agent chains as single traceable sequences? Does it detect shadow agents operating outside the governed layer entirely? That last criterion matters more than it initially appears. According to Okta's data, the governance gap isn't primarily in agents that security teams have chosen not to govern; it's in agents they don't know exist.

Okta's Open Integration Network covers more than 8,200 integrations, including dedicated support for major agent platforms. A gateway that connects to this ecosystem inherits that integration surface rather than rebuilding it.

What Security and Platform Teams Should Implement First

Each step here creates the precondition for the next. Implementing these out of sequence produces security theater, which is worse than doing nothing because it generates false confidence while the actual exposure continues to grow.

Start with discovery. Agents are already in the environment whether security teams know it or not. Shadow AI detection must precede any formal rollout of governance tooling. The objective is a complete catalog: every agent, its owner, the systems it touches, and how it currently authenticates. Without this baseline, registration is incomplete, scoping targets the wrong things, and the gap between governed and ungoverned populations stays invisible.

From there, registration. Using whichever identity platform the organization already operates, whether Okta for AI Agents, Entra Agent ID, or an equivalent, register each discovered agent as a distinct first-class identity. Assign an owner. Assign a review cadence. Establish the kill switch. This step transforms the catalog from a list into a governed inventory.

Credential remediation comes next, and it's often the most operationally intensive phase because the accumulated debt in most environments is substantial. Audit current agent configurations for embedded API keys, shared service-account passwords, and long-lived tokens. Replace them with short-lived, scoped tokens issued per task or per session. The discomfort of this step is proportional to how long the problem was deferred, which in most organizations is longer than anyone wants to admit out loud.

Then delegation structure. For agents that act on behalf of human users, implement the token exchange pattern defined in RFC 8693. Ensure the consent event is logged, and that the delegation record includes the user, the agent, the scopes, and the timestamp. Eliminate any remaining impersonation patterns.

Finally, chain governance. For multi-agent workflows, implement token propagation, chain attestation, and audit trail continuity. Validate that the effective permission set doesn't increase at any hop. Confirm that logs reconstruct full chains as traceable sequences, not disconnected fragments.

The governance gap between deployment velocity and identity infrastructure isn't closing on its own. The patterns required to address it, first-class registration, scoped short-lived tokens, constrained delegation, chain attestation, are available and implementable today. Most organizations already know what to do. What they're actually deciding is how much exposure they're willing to carry until something forces the issue.