AI Agent Identity and Authentication Between Services
The ratio alone is clarifying. Non-human identities now outnumber human identities 144 to 1 in large enterprise environments, up from 92 to 1 in the first half of 2024. That is a 44% year-over-year growth rate. What lives inside that ratio: service accounts, API keys, OAuth tokens, certificates, CI/CD pipeline credentials, and now AI agent identities, all compressed into a single governance problem that most organizations are nowhere near solving.
AI agent identities are the fastest-growing segment within that broader non-human identity population, projected at a compound annual growth rate exceeding 25% from 2026 to 2035, according to Meticulous Research. The operational volume behind that projection is not abstract. CrewAI has reported over 60 billion agent runs on its platform, with more than 100,000 multi-agent execution groups processed daily. Every inter-agent call is, in principle, an authentication event. In practice, most are handled as anything but.
By 2027, 86% of enterprises expect to deploy AI agents, and 42% plan to develop more than 100 agent prototypes, according to a 2025 WEF analysis. That same analysis found that 78% of organizations lack formal policies for creating or decommissioning AI agent identities, and 51% report no clear ownership of AI identities at all. A Cloud Security Alliance report published in 2026 found that 16% of organizations do not track the creation of AI-related identities at all.
You cannot authenticate identities you have not inventoried. Governance is a prerequisite to every mechanism discussed in the rest of this piece, and right now, for most organizations, it does not exist.
The Specific Ways Long-Lived Secrets and Static Credentials Fail in Agent Pipelines
The engineer who drops an API key into an environment variable is not being reckless. They are being practical in the absence of better tooling. The problem is that this shortcut, repeated across an organization shipping agents at scale, produces an architecture whose failure modes are systemic rather than local.
GitGuardian's State of Secrets Sprawl 2026 found 28.65 million hardcoded secrets added to public GitHub repositories in 2025 alone, a 34% year-over-year increase. AI-related secrets grew 81% year-over-year to more than 1.27 million exposures, the fastest growth of any single credential category. These numbers describe a structural tendency, not a discipline problem.
The longevity problem compounds the exposure problem. Many non-human credentials persist far longer than any human account would tolerate: roughly half are over a year old, a meaningful fraction persist between five and ten years. A credential that old, scoped broadly and never rotated, presents an enduring attack surface.
The tj-actions incident in March 2025 is instructive. Attackers compromised a widely-used GitHub Action by stealing a single personal access token, then used it to exfiltrate secrets from CI/CD logs across more than 23,000 repositories. One credential, one compromise, systemic blast radius. Research from Meticulous Research indicates that over 80% of identity-related breaches are linked to compromised non-human credentials such as service accounts.
The failure mode is architectural. A long-lived secret grants persistent access with no scope boundary. An agent compromised at 2:00 a.m. on a Tuesday remains a trusted insider indefinitely with no automatic expiry to bound the damage. Better secret hygiene applied to the same underlying design does not fix this. The fix is credentials that are short-lived by construction, scoped to a specific action at issuance, and automatically rotated.
Workload Identity and Short-Lived Tokens as the Architectural Foundation
Workload identity binds a cryptographic identity to a specific compute unit: a container, a serverless function, an agent process. The identity is issued at runtime by a trusted authority, not stored at rest waiting to be exfiltrated. Rather than binding identity to a human or to a static secret sitting on disk somewhere, this model ties it to the workload itself.
Tokens are short-lived, measured in minutes or hours rather than months. Scope is declared at issuance: an agent orchestrating a travel booking receives a token scoped to "read calendar, write itinerary," not "access all calendar data for all users." Rotation is automatic.
SPIFFE and its runtime implementation SPIRE provide the workload identity layer beneath the token layer. Every agent process receives a cryptographic identity document called an SVID at startup, issued by a SPIRE server, valid for a short window, and automatically renewed. The SVID establishes who the agent is. The token layer, typically OAuth 2.1, establishes what it is permitted to do.
OAuth 2.1 with the Client Credentials flow handles machine-to-machine authentication without a user in the loop: the agent authenticates with its own client identifier and credential and receives a scoped access token. The Resource Indicators extension, required for protected remote MCP servers since mid-2025, ensures tokens are audience-bound. A token issued for Service A cannot be replayed against Service B. JWT structure enforces this at the claims level: the audience claim names the intended recipient, the subject claim carries the agent's identity, the expiry claim enforces the validity window. Audience binding is a structural requirement in any multi-service agent topology.
Least privilege operates here as a runtime constraint rather than a one-time policy decision made at provisioning. The scope of authority narrows to the specific task at hand, for the specific duration of that task.
What this architecture does not solve is the harder problem: when agents call other agents across an authorization chain, how does the service at the far end verify who originally authorized the action, and under what scope?
Delegated Authorization When Agents Call Other Agents
The topology emerging in production looks roughly like this: a user authorizes an orchestrator agent, which delegates work to sub-agents, which call external APIs. Each hop in that chain raises the same question: how does the service at the end know the token it received traces back to a legitimate grant from the original user, and that scope has not been inflated somewhere along the way?
This is categorically harder than agent-to-service authentication. The sub-agent did not receive its token from the user; it received it from the orchestrator. The external API has no direct relationship with the orchestrator. The delegation chain needs to be cryptographically recorded and verifiable, not just asserted in plaintext by the agent making the request.
OAuth 2.0 RFC 8693, the token exchange specification, provides one mechanism. Agent A presents its token to an authorization server, which issues a new token for Agent B carrying the original subject and a narrowed scope. The delegation is recorded in the token itself. Each hop produces a new token with traceable lineage, and the authorization server acts as the enforcing intermediary.
Macaroons and capability tokens offer an alternative that avoids the round-trip to an authorization server at each hop. The orchestrator issues an attenuated token to the sub-agent: a credential carrying the original grant but with restrictions baked in. The sub-agent can use it but cannot escalate beyond what the orchestrator held. Attenuation is offline, which matters at the execution speeds multi-agent pipelines operate at.
The A2A protocol, as currently specified, leaves a gap here. Agent cards carry self-declared identities with no attestation binding. When Agent A delegates to Agent B, there is no mechanism that verifies A's authority, constrains B's scope, or logs the delegation for audit purposes.
A well-formed delegation chain should carry the original principal, the identity attestation of each delegating agent, the scope at each hop (narrowing only, never widening), an expiry that sub-agents inherit rather than reset, and an audit record tied to a specific task rather than an open session. These pieces exist separately across the standards landscape. They do not yet exist as a single implemented protocol.
The confused deputy problem is the named failure mode that tight delegation scope defends against. A sub-agent with broad ambient authority can be manipulated by prompt injection in retrieved content to take actions the original user never authorized. The agent acts within its granted authority, which was simply too wide. Scope-constrained delegation chains are the architectural defense, and most deployments skip them because building them is genuinely hard.
Where the Standards Stand, and Where They Leave Gaps
The Model Context Protocol, launched by Anthropic in November 2024, became a widely adopted standard for agent tool invocation. OpenAI adopted it in March 2025, as did Microsoft Copilot Studio. Python and TypeScript SDK downloads crossed 97 million monthly by late 2025. It was donated to the Linux Foundation's Agentic AI Foundation in December 2025.
The authentication story has been slower. OAuth 2.1 was added as an optional authorization layer in 2026. A Knostic security scan of approximately 2,000 MCP servers found that every single one lacked authentication. The standard exists. The adoption does not.
The IETF currently has four Internet-Drafts in early stages targeting different facets of the agent identity problem: an Agent Identity Management System draft addressing agent lifecycle and identity issuance; a Workload Identity in Multi-Service Environments draft addressing cross-service workload identity; an Agentic JWT draft defining a JWT claims profile for autonomous agents; and a SCIM for agents draft addressing provisioning and deprovisioning at scale. Each solves a real and distinct problem. None of them, individually or collectively, provides a single implemented protocol combining offline attenuable delegation, chained policy enforcement, provenance-aware completion records, and transport bindings across MCP, A2A, and HTTP simultaneously.
The OpenID Foundation is exploring extensions to OpenID Connect that would carry agent context alongside user identity, addressing the provenance question in delegated flows. SCIM for agents addresses a related but distinct gap: lifecycle management. An agent spun up for a task should be deprovisioned when the task ends, not left running with valid credentials against a service it no longer needs to reach.
For teams shipping agents today, the standards are behind the deployments. Builders are assembling workable solutions from OAuth 2.1, SPIFFE, and short-lived JWTs. That combination is coherent and defensible. The standards will consolidate this eventually, but production timelines have not historically waited on the IETF's calendar, and this cycle is no different.
How Zero Trust Principles Apply to Agents, and Where Current Frameworks Were Not Built to Reach
Zero Trust's foundational premise is "never trust, always verify." The complication is that most Zero Trust implementations verify once at session initiation and then extend trust for the duration of that session. An agent does not operate in sessions the way a human does. It makes dozens or hundreds of discrete action decisions within what the framework classifies as a single session, each of which is an independent trust decision the original authentication never evaluated.
Gartner noted in December 2025 that SASE providers would need to adapt because agentic AI created a new class of principals their platforms were built to secure in other ways. The session model is load-bearing in traditional Zero Trust architecture, and agents operate outside it as a normal condition.
The reframe that fits is not access control but action control: governing what an agent is permitted to do after it has authenticated, continuously, not just at login. This requires continuous re-verification at each action rather than each session, policy enforcement that is dynamic and context-aware, a registry of agent identities mapping each agent to its permitted tools and data sources, and audit trails recording not just which service an agent accessed but which tool it called, with which parameters, under which delegation, at which time. Most current Zero Trust implementations provide none of this for agents.
The ambient authority problem compounds this. AI agents executing inside SaaS applications frequently inherit broad, persistent authority from the OAuth grants the application already holds. The Zero Trust layer never evaluates them as independent actors. The agent inherits the application's permissions, and the framework sees nothing unusual, because from the framework's perspective nothing unusual has occurred.
The Cloud Security Alliance's Agentic Trust Framework maturity model offers a practical staging guide for organizations trying to match agent authority to their actual confidence in the identity model. The spectrum runs from read-only agents with no external writes, through agents that recommend actions requiring human approval, up to progressively more autonomous tiers.
Microsoft announced an expansion of its Zero Trust framework in August 2026, including AI-focused assessment capabilities and a DevSecOps pillar specifically addressing agentic workloads. Cloudflare's network architecture enforces identity and policy at the edge, across both human and non-human traffic, within the request path rather than as a bolt-on layer. Continuous inspection built into the network does not require a separate security overlay, which matters when inter-agent call volumes approach the figures CrewAI is already reporting.
MCP Server Authentication in Practice: The Cloudflare Approach as a Working Model
The deployment problem MCP server operators face without a centralized gateway is predictable and, based on the Knostic scan result, widespread. Developers distribute dozens of individual server endpoints; each has its own authentication implementation, or none; there is no consistent policy, no centralized logging, no data loss prevention.
Cloudflare's MCP Server Portals architecture addresses this with a single centralized gateway through which MCP servers are registered. Clients configure one Portal endpoint; policy is enforced once, consistently, across all downstream servers.
What the gateway layer provides in practice: OAuth 2.1 enforcement at the portal boundary, so agents must present a valid, scoped token to reach any downstream MCP server; centralized logging, so administrators can see which agent authenticated to which portal and when; data loss prevention guardrails that prevent specific data categories from passing to specific MCP servers regardless of what the agent requested; and consistent policy enforcement across all registered servers without requiring each server to implement its own authentication stack.
Cloudflare Durable Objects address a related but distinct problem: state management for long-running agentic workflows. An agent orchestrating a multi-step workflow needs somewhere to hold session context, track delegation state, and maintain continuity across tool calls. Durable Objects provide per-agent state that persists at the edge, near the agent's execution environment.
The connection to the delegation problem described earlier is direct. The portal functions as the authorization server in a token exchange flow. When an orchestrator agent requests a token for a sub-agent to use against a specific MCP server, the portal enforces scope constraints, validates the delegation chain, and issues a token with lineage the downstream server can verify. This is RFC 8693 instantiated in a production gateway rather than described as a design pattern. It does not solve every open problem in agent delegation; it solves the immediate, concrete problem of MCP servers deployed without any authentication at all, which is where the field currently stands.
Production systems ship first. Standards follow. The teams that built working systems while the working groups were still deliberating on terminology have a say in what the final standard looks like.
