OAuth and SPIFFE for AI Agent Identity

Okta called agents "the fastest-growing identity in the enterprise and the least governed," and the numbers behind that claim are uncomfortable. Gartner projects that by 2028, the average Fortune 500 company will have more than 150,000 agents in active use. Rubrik Zero Labs puts the current non-human to human identity ratio across the modern enterprise at roughly 45:1; in cloud-native environments, Entro Labs' H1 2025 research puts it higher still. AI-related credential exposures are now the fastest-growing single category in GitGuardian's State of Secrets Sprawl 2026 report. These numbers describe a structural governance gap, not a tooling gap that a better dashboard closes.

Bearer tokens were designed for human-initiated sessions: bounded in duration, initiated with human judgment, terminated when the session ends. Agents act at machine speed, chain many calls without pausing, and pursue goals without any natural stopping point. The assumptions baked into bearer token design simply do not hold when the principal is a long-running autonomous process rather than a person who eventually closes a browser tab. A bearer token handed to an autonomous agent is like giving someone a house key and then discovering they've sublet the house to a thousand strangers — technically the same key, but nothing like the original arrangement.

Static API keys make the problem materially worse. They are long-lived by design, easily hardcoded, and trivially leaked. The target system sees only that a known key was presented; it cannot tell which workload presented it, from where, or when. Auditability collapses at precisely the moment accountability matters most. Dynamic, multi-cloud agent execution paths compound this further, because a static key cannot be scoped to the environment where a given agent instance is actually running.

Service accounts, extended naively to agents, repeat the structural mistakes of early cloud IAM: shared across workloads by default, permitting long-lived keys, with no per-instance identity. Microsoft Entra's pre-Agent ID reality was engineering teams spinning up ad-hoc service principals with no consistent policy, no designated owner, and no expiration date anyone could agree on. Gartner found in 2026 that the vast majority of enterprise agents are over-permissioned and that more than half access sensitive information. That is the predictable consequence of applying human-centric access models to non-human principals. It is not an accident.

The underlying failure is assumption collapse: every access control built around human-paced judgment degrades when a non-human acts at machine speed with no natural stopping point. Authentication and authorization are now separate problems that require separate solutions. Proving what a workload is, and constraining what it can do on behalf of whom, are distinct concerns, which is exactly why one framework cannot responsibly cover both.

What SPIFFE Actually Provides: Cryptographic Workload Identity Without Long-Lived Secrets

SPIFFE, the Secure Production Identity Framework for Everyone, is an open standard for issuing cryptographically verifiable identities to software workloads based on their runtime provenance. Each workload receives a SPIFFE ID, packaged in an SVID (SPIFFE Verifiable Identity Document), delivered as an X.509 certificate from a SPIRE server. Identity is bound to what the workload is and where it is running, not to a secret that can be exfiltrated and replayed somewhere else entirely. Google Cloud's Agent Identity implementation issues X.509 certificates valid for 24 hours, renewed automatically, with no human touchpoint in the rotation cycle and therefore no human failure point either.

Three properties make SPIFFE particularly suited to agentic environments. First, unique per-workload identity means no shared credentials across agent instances, so every instance is individually attributable when something goes wrong. Second, federated trust means identities can be validated across organizational and cloud boundaries without a shared secrets store, which matters enormously when agents operate across multi-cloud or partner environments. Third, dynamic credentialing means issuance and rotation happen automatically at a cadence that static keys cannot match and that humans could not sustain manually at this volume even if they wanted to.

SPIFFE embodies Zero Trust at the workload layer. Every workload-to-workload call is authenticated with a verifiable, short-lived identity; trust is never assumed from network location alone. Production deployments at Uber, Stripe, and Netflix predate the AI agent wave by years. The standard is proven at scale under adversarial conditions, which is more than can be said for most identity frameworks being retrofitted onto agents today.

What SPIFFE does not do is equally important to understand. It proves the workload's identity. It does not encode what that workload is authorized to do on behalf of a user. Authorization policy, scope delegation, and user-context actions live entirely outside SPIFFE's boundary. That is correct separation of concerns, not a limitation, and it is precisely where OAuth belongs.

What OAuth Provides: Delegated Authorization for Agents Acting on Behalf of Users

OAuth's core function is representing a user's authorization, not the caller's identity. When an agent calls an API or an MCP server to act on a user's behalf, the downstream system needs to know whose authorization is being exercised. SPIFFE cannot carry this information; it was never meant to. OAuth scopes, consent flows, and token exchange are the mechanisms for encoding and delegating that user-context authorization across service boundaries.

The current MCP authorization specification, released November 2025, formalizes OAuth 2.1 as the standard for MCP. MCP servers are OAuth 2.1 resource servers; clients must implement OAuth 2.0 Protected Resource Metadata (RFC 9728) for authorization server discovery and Resource Indicators (RFC 8707) for resource-specific token issuance. Dynamic Client Registration (RFC 7591) is optional in the spec but practically necessary for zero-touch agent onboarding at any meaningful scale.

OAuth's failure mode in agentic contexts is specific and worth naming clearly: when there is no user context, OAuth is being misapplied. Pure machine-to-machine agent calls, where one agent is verifying another agent's trustworthiness rather than acting for a human, have no natural OAuth principal. Forcing OAuth into this pattern through client credentials produces over-broad, unauditable access with no runtime provenance and no meaningful rotation. The audit properties are indistinguishable from a static API key. Protocol complexity added; security not.

Okta's Cross-App Access protocol illustrates how user-context delegation should work at enterprise scale. An orchestrator submits a user token and the requested scope; Okta evaluates the agent access policy and returns a short-lived, one-time-use ID-JAG token downscoped to the specific task. Early adopters include Anthropic, Zoom, and Slack, meaning the protocol is being built around real multi-agent orchestration patterns, not hypothetical ones someone sketched on a whiteboard.

How SPIFFE and OAuth Fit Together in a Two-Layer Agent Identity Architecture

The two frameworks answer different questions about the same agent call. SPIFFE answers: is this the workload it claims to be, and is it running in the expected environment? OAuth answers: is this workload authorized to act on behalf of this user, with these scopes, against this resource? Both questions must be answered on every call to achieve a genuine Zero Trust posture. One without the other leaves a gap that adversaries and over-permissioned agents find quickly in practice, usually in that order.

The layered model places SPIFFE as the foundational runtime identity layer, with OAuth sitting on top for user-context delegation. The bridge between them is OAuth Token Exchange (RFC 8693): an agent presents its SVID to an authorization server and exchanges it for a downstream-scoped OAuth token calibrated to the specific task. IETF Transaction Tokens (draft-ietf-oauth-transaction-tokens) carry call-chain context across services and agents, preserving who initiated the chain across many orchestration hops. Without this, the audit trail for a complex agent workflow becomes forensically useless once the chain exceeds two hops. The IETF draft draft-ietf-oauth-spiffe-client-auth-02 (June 2026) formalizes how clients authenticate to an OAuth authorization server using SPIFFE JWT-SVIDs or X.509-SVIDs, which is the protocol-level bridge that makes the two systems interoperable rather than just philosophically compatible.

Dynamic Client Registration closes the onboarding gap that makes this architecture operationally viable. Registering thousands of agent instances as OAuth clients manually is not a process anyone has actually sustained; it breaks immediately at scale. DCR extensions allow authorization servers to accept SPIFFE-issued tokens as software statements, so the SVID becomes the proof that earns an OAuth client registration without human intervention. The agent bootstraps its own OAuth participation from its cryptographic workload identity.

Inside the trust domain, SPIFFE SVIDs govern workload-to-workload calls. At the API boundary, OAuth governs access to external resources and user-scoped actions. The hybrid pattern lets organizations maintain a consistent Zero Trust posture without maintaining a different identity model for every layer of the stack, which is the kind of operational complexity that quietly kills security programs.

Where to Apply Each Framework: A Decision Map Based on the Type of Agent Interaction

Agent-to-agent calls within a trust domain. Use SPIFFE. Mutual TLS with SVIDs gives each agent cryptographic proof of the other's runtime identity. No user principal exists in this call; OAuth client credentials applied here produce over-broad, unauditable access. The canonical pattern is an orchestrator agent calling a sub-agent inside the same SPIRE trust domain.

Agent calling an external API or MCP server on behalf of a user. Use OAuth on top of SPIFFE. The SVID establishes the agent's identity; Token Exchange produces a user-scoped downstream token calibrated to the task. The MCP authorization specification requires OAuth 2.1 at this layer; there is no compliant alternative for MCP deployments. Scope should be downscoped to the specific task and not reused across calls. Okta's Cross-App Access one-time-use token pattern operationalizes this correctly.

Agent-to-agent calls crossing organizational or trust-domain boundaries. SPIFFE federated trust handles cross-domain workload identity without a shared secrets store. OAuth Transaction Tokens carry the call-chain context across the boundary, preserving the authorization lineage of who initiated the chain and under what scope.

Purely autonomous agent actions with no user delegation. SPIFFE identity scoped with fine-grained RBAC at the resource layer, with no OAuth token in the flow. The dominant failure mode here is over-permissioning, already pervasive according to Gartner's 2026 findings. Every autonomous agent in this category needs a defined access envelope, an owner of record, and an audit trail someone will actually look at. Microsoft Entra's agent identity blueprints address this directly.

The common mistake across all of these: using OAuth client credentials as a substitute for workload identity. The resulting credential is long-lived, broad, and carries no runtime provenance. The practical test is simple — call it the identity smell test. If you cannot answer "what workload presented this credential, from where, and at what time," the identity layer is insufficient. Client credentials alone will never answer that question, no matter how many scopes you apply.

How Enterprise Identity Providers Are Implementing the Two-Layer Model Today

Microsoft Entra Agent ID

Microsoft GA'd Agent ID in April 2026. An agent identity is a specialized service principal that carries no credentials of its own; it acquires short-lived tokens through its blueprint, contingent on user or admin consent. Agent identity blueprints are reusable templates that define owners, sponsors, the access envelope, and audit behavior, applied consistently across every instance of a given agent type. Conditional Access, Identity Protection, and Privileged Identity Management all extend to non-human identities under this model, meaning the same Zero Trust controls that govern human access now govern agents through the same policy framework. This directly addresses the ad-hoc service principal problem that was endemic before: no owner, no expiration, no policy, no one who remembered creating it in the first place.

Okta for AI Agents

Okta extends the Okta Integration Network's catalog to cover agent platforms including Boomi, DataRobot, and Google Vertex AI, providing a single console for discovering sanctioned agents and surfacing shadow agents operating outside IT visibility. The Cross-App Access flow is the operational centerpiece: an orchestrator submits a user token and scope, and Okta returns a short-lived, one-time-use ID-JAG token downscoped to the specific task. The kill switch capability lets administrators deactivate an agent to prevent new token requests when behavior is anomalous, a response mechanism that static credential models structurally cannot offer. Okta also works alongside existing enterprise IdPs, so organizations can retain Entra ID or Ping for human identities and layer Okta's agent governance on top without forcing a rearchitecture of the human identity stack, which is a meaningful concession to operational reality.

Google Cloud Agent Identity

Google Cloud's implementation is SPIFFE-native. Each agent receives a unique SPIFFE identity and X.509 certificate on deployment, valid for 24 hours and automatically renewed. Access tokens are cryptographically bound to the agent's X.509 certificate, meaning token theft is insufficient for impersonation because the corresponding private key never leaves the workload. Developers cannot generate long-lived service account keys for agents; the design eliminates the static credential failure mode by construction rather than by policy. Policy-based enforcement is harder to sustain than structural impossibility, and Google's architecture reflects that judgment directly. That distinction matters more than it initially appears.

HashiCorp Vault

Vault 1.21 introduced native SPIFFE authentication: Vault issues secrets to workloads that authenticate using X.509-SVIDs, making the SPIFFE identity the authoritative basis for secrets access decisions. A workload can authenticate to Vault using its cryptographically verifiable runtime identity and receive a dynamically issued, short-lived secret scoped to its access envelope, with no static credential in the chain at any point. For organizations already running SPIRE, Vault 1.21 integrates into the trust hierarchy directly, without requiring a parallel credential management system.

Across all four implementations, the pattern holds: runtime identity is cryptographic and short-lived, user-context delegation is scoped and auditable, and the two layers are explicitly separated and explicitly connected. The question these architectures are actually designed to answer is one that boards and regulators are increasingly asking: what can your agents do, on whose behalf, and how do you know? Most organizations deploying agents today cannot answer it. The ones running this model can.