AI Agent Identity in 2026:Delegation Chains, Workload Identity, and the Protocols Racing to Contain Them

An agent that answers one question and hands back control does not need its own identity — the human asking it is identity enough. An agent that reads a support ticket, calls a billing API, hands a sub-task to a second agent, and that second agent calls a third-party service on a different company's infrastructure absolutely does, and 2026 is the year that second shape of deployment — agents calling agents, across organizational boundaries, unattended — went from an edge case to the default architecture for anything beyond a single-tool chatbot.

The evidence is in how fast the identity industry moved to build for it. Microsoft shipped Entra Agent ID, extending its existing workforce identity governance to agents as first-class, auditable non-human identities. Okta brought the open Cross App Access standard into core Okta SSO on August 24, 2026, positioning it as the enterprise-managed authorization layer for the Model Context Protocol specifically. Auth0 — an Okta brand — took its Auth for GenAI platform generally available in November 2025 and added on-behalf-of token exchange for MCP in May 2026. WorkOS, the newest entrant, opened early access to Agent Auth on September 2, 2026, built from the ground up around agents having their own revocable identity rather than borrowing a human's. Four well-funded identity platforms converging on the same problem within roughly a year of each other is not a coincidence; it is a market responding to a gap that got expensive fast.

This guide assumes you already have, or are about to build, agents that call other agents, other companies' APIs, or tools outside your own trust boundary — the point where identity, not just capability, starts to matter. If you're earlier in the decision of which orchestration framework to build on in the first place, our guide to AI agent orchestration frameworks covers that layer separately, and our multi-agent systems architecture guide covers when a multi-agent design is worth the added complexity at all.

A confused deputy is a program with more authority than the task in front of it needs, misused because nothing ever narrowed it down. It is one of the oldest problems in computer security, and it is also, almost exactly, the default architecture most teams build their first agent with: the agent runs as a service account or inherits the calling user's token wholesale, so an agent built to summarize a customer's support history can typically also write to that customer's billing record — not because anyone decided it should be able to, but because the credential handed to it doesn't distinguish between the two.

This is manageable, if uncomfortable, when there is exactly one agent and one human watching it. It stops being manageable the moment an orchestrator agent spawns a sub-agent to handle part of the task, and that sub-agent calls a third-party tool or a different company's API. WorkOS's own engineering writing on this makes the point plainly: authenticating a single agent is a solved problem — OAuth handles that — but the real challenge surfaces when an agent spawns another agent, which calls a third, which touches production data, and nothing in a typical token tracks that chain of custody.

The architectural fix several vendors in this space converge on independently is a two-identity model: the agent has its own identity, separate from the user or service account it is acting for, and its effective permissions at any moment are the intersection of what the user is allowed to do and what that specific agent is allowed to do — never simply "whatever the user could do." This is a different concern from sandboxing and credential scoping, which limits what a single agent's tool calls can do once it has a credential; agent identity is about knowing, and being able to prove and revoke, which agent is holding that credential and acting on it right now.

The mechanism underneath nearly every serious proposal for agent delegation is not new — it is RFC 8693, OAuth 2.0 Token Exchange, published by the IETF in January 2020, years before agentic AI made the problem urgent. Token Exchange defines a protocol for one party to trade a security token for another, and it includes an act claim built specifically for delegation: it identifies the actor currently operating on behalf of a subject, and critically, the claim is nestable, so a single token can carry the full sequence of every actor that has held and passed it along.

Concretely, this means a downstream system receiving a request can, in principle, look at the token and reconstruct the whole chain: this user authorized this orchestrator agent, which delegated to this sub-agent, which is the one actually making the call right now. Without this, every hop past the first collapses into invisibility — a tool or API three hops deep in a delegation chain sees only the original human's identity, with no record of which agent actually made the specific call, which is precisely the gap a compromised or misbehaving sub-agent exploits without anything downstream noticing.

None of the agent-specific extensions above are finished, ratified standards yet — only RFC 8693 itself is. That gap between "the base mechanism is a decade-old finished standard" and "the agent-specific chaining on top of it is still being drafted" is the single most important status fact in this entire space, and it is why every vendor platform covered in the next section is, underneath its own branding, implementing a proprietary version of the same not-yet-standardized idea.

Beyond the two chaining drafts above, a small cluster of related IETF work is moving in parallel, each aimed at a different sliver of the same problem: an individual draft on cross-domain authorization information sharing for agents describes the case where an orchestrator in one organization delegates authority to agents running in two others, and each receiving domain has to independently verify the delegation chain and confirm the delegated scope never exceeds what the originating principal actually authorized. A separate draft on attenuating agent tokens addresses scope narrowing specifically — making sure a token's authority shrinks, never grows, as it passes through each additional hop of a delegation chain.

A useful, checkable signal of how unfinished this layer still is: a June 2026 academic gap analysis (arXiv:2606.31498) examined five agent interoperability protocols — MCP, A2A, ACP, ANP, and ERC-8004 — against a six-dimension governance taxonomy covering membership, deliberation, voting, dissent preservation, human escalation, and audit and replay. It found voting and dissent preservation universally absent across all five, and deliberation support absent or at best partial. That paper is about governance of agent communities, not identity specifically, but the finding matters here: even the protocols that have made real progress on knowing which agent is talking have made comparatively little progress on the layer above it — who gets a say, and how a decision an agent made gets contested after the fact.

Six options now cover the practical range a team is likely to choose between: four identity platforms, each extending a different existing IdP relationship, plus one open workload-identity standard and one protocol-level discovery mechanism that sit underneath and beside the application-layer platforms rather than competing with them directly.

The pattern worth naming: none of the four application-layer platforms is trying to be a universal, vendor-neutral standard. Each is explicitly built to extend whichever identity relationship you already have — Entra ID for a Microsoft shop, Okta for an Okta shop, Auth0 for a customer-facing product already using Auth0, and WorkOS for a team building agent identity without an existing enterprise IdP to extend. That is a healthier state than one company owning the whole layer, but it also means the interoperability burden — making an agent identity issued by one platform legible to a partner using a different one — falls on the IETF chaining drafts and protocol-level mechanisms covered in the rest of this guide, not on any single vendor.

Everything above operates at the application layer — a platform issuing a token that says what an agent is authorized to do. Two other layers matter and are frequently skipped: whether the process making a request is actually the software it claims to be, and whether a receiving agent can trust a stranger's claim of identity before ever talking to it.

SPIFFE (Secure Production Identity Framework For Everyone), graduated by the Cloud Native Computing Foundation in September 2022 alongside its open-source runtime SPIRE, answers the first question. A workload — an agent container, an MCP server, any running process — receives a SPIFFE ID, a URI in the form spiffe://trust-domain/path, and a short-lived credential called an SVID, verified at connection time via mutual TLS rather than read out of a bearer token that anyone who intercepts it could replay. This matters more for agents than for ordinary web applications specifically because agent workloads spawn sub-processes, scale up and down, and get rescheduled onto different infrastructure far more dynamically than a typical service — an OAuth token can be correctly scoped and still be sitting on a process that isn't actually the software it claims to be. Infrastructure vendors including HashiCorp, Aembit, and Solo.io now publish reference architectures applying SPIFFE specifically to AI agent fleets; treat their specific implementation claims (rotation intervals, deployment topology) as vendor material worth verifying against your own environment, not settled fact, the same way we treat any single vendor's architecture claims throughout this guide.

The second question — can a receiving agent trust a stranger's identity claim before talking to it — is what the A2A protocol's Signed Agent Cards and the proposed Agent Name Service are built to answer. An Agent Card is a JSON document an A2A-compatible agent publishes, describing its identity, capabilities, and how to authenticate with it; a Signed Agent Card adds a cryptographic signature over that document so a receiving agent can verify it actually came from the domain it claims to represent, rather than trusting an unsigned, self-asserted claim. The Linux Foundation announced its intent to build on top of this on June 23, 2026 with the Agent Name Service (ANS) — a DNS-based, federated identity, verification, and discovery layer meant to let agents be looked up and trust-checked across organizations the way domain names are today, without depending on any single company's proprietary registry. As of this writing, ANS is an announced intent open for industry participation, not a production service.

The Model Context Protocol tightened its own piece of this in its 2026-07-28 specification release: MCP servers are now formally defined as OAuth 2.1 resource servers, authorization servers are required to return an issuer parameter per RFC 9207 that clients must validate before redeeming a code — closing a specific authorization-server mix-up hole — and client credentials are now bound to the specific issuer that minted them rather than being portable across issuers. Our guide to AI agent sandboxing and credential scoping covers MCP's OAuth 2.1 model as it applies to a single agent calling a single tool server; this specific hardening is about which issuer a client is willing to trust in the first place, which is the identity-chaining problem this article covers, applied at the MCP layer.

A protocol built specifically to let agents discover, authenticate with, and delegate to each other across organizational boundaries is also, by construction, the protocol where an identity or delegation failure has the widest blast radius — which is exactly why it drew the first systematic security analysis of its kind.

Named examples from the research worth understanding individually: cross-client context injection through unprotected context identifiers, where one client's conversation context can bleed into another's; credential harvesting through identity loss across multi-hop delegation chains — precisely the chain-of-custody gap the delegation section above describes, now shown to be practically exploitable rather than theoretical; and data exfiltration through a rogue agent advertising capabilities in its Agent Card that it was never independently attested to actually have, which is the specific failure Signed Agent Cards are meant to close and evidence that signing alone does not close every version of the trust gap in discovery.

Two things about how this research was conducted are worth knowing before drawing conclusions from it. First, the analysis tool itself achieved 73.3% precision and an 84.6% F1 score against independent expert review — a meaningfully strong result — while a zero-shot large language model given the same protocol specification and asked to find vulnerabilities produced zero confirmed findings, a useful, concrete data point on the current limits of asking a model to red-team a protocol specification directly rather than building dedicated tooling. Second, and more important for anyone currently running A2A in production: all eleven findings were disclosed to the A2A maintainers under the Linux Foundation before publication and have been acknowledged by them, which is the responsible-disclosure process working as intended, not a sign the protocol is unmaintained or the maintainers were caught off guard.

The practical read: a protocol running in production at 150-plus organizations attracting this kind of rigorous, disclosed, acknowledged security research is a healthier sign than the alternative — a protocol nobody has bothered to break yet. Treat "we use A2A" the way you'd treat "we use OAuth": a real foundation, not a finished, hardened deployment on its own.

Two forces are converging on this space from outside pure engineering: academic governance research pointing out what the protocols still can't express, and an early legislative proposal describing, in policy language, almost exactly the same delegation and revocation problem this article covers as an infrastructure problem.

The governance-gap research covered above found that voting and dissent preservation are universally absent across the five agent interoperability protocols it examined, and deliberation support is absent or at best partial. Applied plainly: today's protocols can tell you which agent is acting and, increasingly, on whose delegated authority — but none of them have a built-in mechanism for a human or another agent to formally contest a decision after the fact, or for a record of that dissent to travel with the delegation chain the way the act claim carries identity. That is a governance layer above identity, not a replacement for it, and it is worth naming as a known, unsolved gap rather than pretending the identity work covered in this guide finishes the job.

On the regulatory side, Senator Mark Warner released a discussion draft — not an introduced bill, and not law — of the AI AGENT Act on June 29, 2026. It proposes a federally registered category of "custodial user agents": software a consumer authorizes to act on their behalf across large online platforms (defined as those with 50 million or more U.S. users or subscribers in the prior twelve months), with providers required to register with the FTC before accessing those platforms' interfaces. The draft's specific requirements read almost like a policy translation of this article's engineering recommendations: the relationship must be transparent, documented, limited in scope, and revocable, with verifiable requests, auditable records, agent identity verification, real-time revocation, and scope-limited delegation credentials. It also places privacy limits on secondary use of data an agent collects while acting for a consumer.

Retrofitting agent identity onto a fleet that already assumes every agent shares one wide-open token is materially more expensive than building it in from the first agent — the steps below are ordered because doing them out of sequence tends to produce a system that looks identity-aware and isn't.

Consider a worked, illustrative scenario — not a real client engagement, and presented explicitly as one so the arithmetic is honest about what it is: a 60-person insurance brokerage runs an orchestrator agent that reads an incoming claim, delegates document verification to a specialist sub-agent, and that sub-agent calls a third-party fraud-check API run by a different company entirely. Under the wide-open pattern — every agent inheriting the calling adjuster's full token — the fraud-check vendor sees only the adjuster's identity on every call, with no record of which of the brokerage's several concurrently running claim-processing agents actually made a specific request.

At a plausible volume of 400 claims a month, if even a modest fraction — say one claim in fifty — triggers a question during a later audit or a dispute about what data was shared with the third-party vendor and why, that is roughly eight incidents a month where the brokerage cannot answer "which agent, acting under what specific authorization, made this call" from its own logs, worked honestly from these illustrative assumptions and not a real measured client figure. Each one becomes a manual reconstruction effort — checking deployment timestamps, correlating server logs, interviewing the adjuster — that a proper delegation record would have answered in seconds.

With agent identity in place — the orchestrator and the document-verification sub-agent each holding their own identity, a token scoped to the specific claim and task rather than inherited wholesale from the adjuster, and a delegation record naming both agents and the adjuster who initiated the claim — the same audit question is answered directly from the log: this specific sub-agent instance, delegated by this orchestrator, acting under this claim's scope, made this call at this time. The engineering cost of building this correctly, per the bands below, is real and worth budgeting for deliberately — but it replaces an open-ended, compounding audit-reconstruction cost with a one-time infrastructure investment, and it is the difference between an incident that takes minutes to explain and one that takes days.

What we scored: named general-availability and early-access dates for each identity platform, the specific IETF draft or RFC status each proposal has actually reached, and named findings from the A2ABreak and governance-gap academic papers, all checked directly against the named source on September 27, 2026 and cited individually above.

What we explicitly refused to score or present as neutral fact: any vendor's own claimed adoption numbers, deployment scale, or security posture beyond what is independently named and dated; and the cluster of "non-human identities outnumber humans" ratio statistics circulating in 2026, which we address directly below rather than silently omitting, since a reader who has seen one of these figures deserves to know why it isn't repeated here as settled fact.

A reader building the credential-scoping and blast-radius-limiting layer that sits alongside agent identity — a related but distinct concern — may also find our guide to AI agent sandboxing and credential scoping useful as a companion resource.

Senior-led delivery runs $150 to $225 per hour, ongoing retainers run $2,500 to $9,500 per month, and every engagement carries a 30-day post-launch warranty. Every proposal is written and fixed-price, delivered within five business days of a discovery call, whether the engagement fits one of the bands above or falls between them.

Related engagements worth budgeting alongside agent identity rather than in isolation: the sandboxing and credential-scoping work covered in our companion guide, since a well-identified agent with an over-scoped credential still has an unbounded blast radius, and durable execution, because a delegation chain that spans a multi-day human approval wait needs the same crash-safe, resumable infrastructure as any other long-running agent workflow.

• We could not independently verify any identity vendor's own adoption, deployment-scale, or performance claims beyond what is named and dated in a public, checkable source; where a vendor's own framing is used, it is attributed to that vendor rather than presented as neutral fact.
• The IETF drafts covered in this guide — identity chaining, chain delegation, attenuating agent tokens, and cross-domain authorization information sharing — are active works in progress as of September 2026 and may change materially, be abandoned, or be superseded before reaching RFC status; treat their described mechanisms as the current direction, not a finished specification to build a hard dependency on.
• The A2ABreak and governance-gap papers cited in this guide are recent (September and June 2026 respectively); A2ABreak has been accepted at ACSAC 2026, while the governance-gap paper's peer-review status was not independently confirmed by us beyond its arXiv posting — we cite both as serious, methodologically detailed research worth reading directly, not as settled, fully peer-reviewed consensus.
• We could not verify a real, named Frenchy Digital client engagement that specifically matches this article's topic closely enough to describe honestly; the worked example above is explicitly an illustrative scenario, not a real client's numbers, and is labeled as such throughout.
• Product names, general-availability status, pricing, and feature sets for every platform named in this guide move quickly; treat the dates attached to each claim as the date it was true, not as an assurance that it remains true when you read this.