2026 Comparative Analysis: Workload Identity and Delegation Chains for AI Agents — Applied Technology Index

Executive Summary

Workload identity for AI agents establishes which deployed software instance is calling a service. Delegated identity preserves the human or service on whose behalf that workload acts. Delegated authority defines what the caller may do. These are related controls, but none can safely substitute for the others.

This distinction has become a frontier infrastructure question because the Model Context Protocol (MCP) roadmap, updated 22 August 2026, names agent identity and enterprise-ready security as a priority. It describes cloud agents that have their own identity, act for absent users, and spawn subagents that should receive narrower authority. The roadmap points to DPoP, workload identity federation, the Identity Assertion JWT Authorization Grant (ID-JAG), and OAuth 2.0 Token Exchange as the intended standards base rather than proposing an entirely agent-specific identity system.

The reviewed mechanisms occupy different layers:

SPIFFE defines a workload identity framework: a SPIFFE ID, a verifiable identity document (SVID), and a local Workload API through which software obtains credentials.
IETF WIMSE is developing architecture and practice guidance for conveying workload identity and security context across heterogeneous systems. Its current documents remain Internet-Drafts.
OAuth Token Exchange, RFC 8693 exchanges one security token for another and can represent impersonation or delegation. Its nested act claim records actor history, but the RFC does not require each hop to have less authority than its parent.
OAuth Identity and Authorization Chaining draft-17 combines token exchange and JWT authorization grants to preserve identity and authorization information when a call crosses OAuth trust domains. It is work in progress, not a ratified RFC.
DPoP, RFC 9449 sender-constrains OAuth tokens to a key and helps detect replay of stolen access or refresh tokens. It does not decide whether an agent was entitled to the token or whether a delegated action is safe.
MCP Enterprise-Managed Authorization applies ID-JAG to user-backed enterprise access. MCP’s separate workload-federation proposal targets autonomous software that already has a short-lived platform credential. The extension is stable, while the workload-federation proposal remained an open pull request with testing marked TBD when reviewed.
Verifiable Attenuated Delegation for AI Agent Chains draft-00, dated 27 August 2026, proposes cryptographically linked JWT delegation chains whose scope, magnitude, lifetime, and depth can only narrow. It is an individual Internet-Draft and should be treated as an experimental design signal, not deployed consensus.

The central finding is that production agent identity needs a dual-subject authorization record: the executing workload and the represented user or upstream service must remain distinguishable. Every token must also be bound to the intended resource, limited in time and scope, and preferably sender-constrained. When a parent agent spawns a child, the child should receive a fresh, narrower credential rather than a copy of the parent’s bearer token.

No reviewed mechanism proves that an agent’s plan is correct, that the user approved the exact action, or that a tool produced the intended business outcome. Identity answers who is calling; delegation records for whom; authorization decides what is allowed; runtime policy evaluates this action now; and receipts or reconciliation establish what happened.

Key findings

An agent name in a prompt is not workload identity. A production identity must be issued from an authenticated runtime or identity system and verifiable by the relying service.
Service identity and user identity should not be collapsed. A token that records only the user hides which agent runtime acted; a token that records only the workload loses the represented user’s authority and revocation context.
RFC 8693 records delegation but does not guarantee attenuation. The act claim can preserve current and prior actors, while authorization servers remain responsible for deciding which exchanges and scopes are acceptable.
Identity chaining is cross-domain translation, not automatic transitive trust. Each receiving authorization server must validate the incoming grant, issuer, audience, client, claims, freshness, and local policy before minting its own access token.
DPoP reduces bearer-token replay but leaves policy intact. A malicious holder of the legitimate key, an overbroad token, or an unsafe tool call can still cause harm.
SPIFFE provides workload identity, not end-user delegation. An SVID can authenticate the executing workload; a separate authorization layer must preserve the user, task, resource, scope, and approval.
MCP now has two different identity paths. Enterprise-Managed Authorization is a stable user-backed extension using ID-JAG; SEP-1933 is a proposed workload-federation path for autonomous runtimes with platform-issued JWTs.
The newest agent-chain proposal is deliberately stricter than actor history. Its core idea is monotonic attenuation, but its draft-00 status, new constraint vocabulary, offline-verification assumptions, revocation model, and lack of demonstrated interoperability are material limitations.
Token passthrough is not delegation. MCP security requirements prohibit passing the MCP client’s access token directly to an upstream API; the upstream audience requires a separately issued token.
The safest child credential is short-lived, audience-specific, holder-bound, and narrower than the parent’s current authority. It should be independently revocable where the risk warrants it.

Methodology

This analysis reviewed primary technical materials available on 2 September 2026. The live Applied Technology Index research index and local public research collection were checked before topic selection. Existing articles covered agent authorization, credential brokering, semantic delegation and handoffs, runtime policy, and runtime attestation, but not the identity-preservation and authority-attenuation mechanisms used when an agent workload acts for a user or delegates across trust domains.

Current X and developer discussion were used only to identify agent identity as a frontier signal. Claims were grounded in the MCP roadmap and specifications, MCP’s workload-federation pull request, IETF RFCs and Internet-Drafts, and the SPIFFE specification. Draft status and proposal maturity are reported explicitly.

The mechanisms were assessed on eleven criteria:

Identity subject: human, OAuth client, deployed workload, parent agent, child agent, or prior actor.
Credential source: enterprise IdP, platform attestation, workload API, authorization server, or delegating agent.
Trust-domain boundary: one issuer, federated workload domains, or chained OAuth authorization servers.
Delegation semantics: impersonation, actor history, user representation, workload federation, or monotonic attenuation.
Authority representation: scopes, resource indicators, audience, rich authorization details, or deployment-specific policy.
Holder binding: bearer, mTLS, SPIFFE X.509 identity, JWT proof, or DPoP key confirmation.
Freshness: access-token lifetime, grant lifetime, nonce, proof timestamp, or child expiry bounded by parent expiry.
Revocation: issuer lookup, token status, short lifetime, IdP policy, or parent/child invalidation behavior.
Verification location: online authorization server, local workload API, resource server, or offline chain verifier.
Agent-protocol fit: generic service identity, MCP user authorization, MCP workload access, or multi-agent delegation.
Maturity: stable specification, ratified RFC, IETF Working Group draft, MCP proposal, or individual Internet-Draft.

This is a documented-capability analysis. No SPIRE deployment, cross-cloud federation, ID-JAG exchange, MCP workload-federation implementation, DPoP client, identity-chaining flow, or attenuated delegation chain was executed. The analysis therefore does not measure issuance latency, revocation propagation, interoperability, maximum chain depth, token size, key custody, implementation correctness, or compromise recovery.

Comparative Analysis Table

Mechanism	Identity or delegation function	Trust and token model	Best fit for agents	Main limitation
SPIFFE	Assigns a structured SPIFFE ID to a workload and delivers an SVID through the Workload API	X.509, JWT, or WIT SVID issued under a SPIFFE trust domain; federation distributes trust bundles	Authenticating the actual agent runtime, gateway, worker, or tool service without embedding a long-lived secret	Does not by itself preserve a represented user, authorize a business action, or attenuate authority across agent children
IETF WIMSE architecture and practices	Defines architecture and documents industry patterns for workload identifiers, credentials, delivery, context, and cross-domain operation	Technology-neutral architecture plus practices across Kubernetes, SPIFFE, cloud providers, CI/CD, and service meshes	Designing portable workload identity across heterogeneous agent runtimes and clouds	Current documents are Internet-Drafts; architecture does not supply one ready-to-deploy agent delegation token
OAuth Token Exchange, RFC 8693	Exchanges a subject token and optional actor token for a new token; can express impersonation or delegation	Authorization server validates inputs and issues a token for requested resource, audience, scope, and token type; nested `act` can retain actor history	Minting audience-specific credentials for an agent acting for a user or another service	Actor history is informational; the RFC does not require monotonic scope, amount, time, or depth attenuation
OAuth Identity and Authorization Chaining draft-17	Preserves identity and authorization information across multiple OAuth trust domains	Domain A issues a JWT authorization grant; Domain B validates it and issues its own access token using RFC 7523	Multi-cloud or partner agents that must cross authorization domains without losing user and call-chain context	Work in progress; claim transcription, privacy, trust establishment, client authentication, and replay controls require careful deployment
DPoP, RFC 9449	Binds OAuth tokens to a public key and presents signed proofs at token and resource endpoints	Application-layer proof-of-possession JWT includes method, URI, time, unique ID, token hash, and optional server nonce	Reducing replay risk when agents store or transmit OAuth access and refresh tokens	Does not establish workload provenance, user intent, least privilege, or action safety; key theft defeats holder binding
MCP Enterprise-Managed Authorization	Uses an enterprise IdP and ID-JAG to obtain user-backed MCP access without per-server interactive consent	IdP evaluates policy, issues short-lived ID-JAG for an MCP authorization server and resource, then MCP authorization server issues access token	Enterprise assistants acting for authenticated employees under centralized access policy	Depends on client, IdP, and server support; stable extension still requires local claim mapping, scope design, and client authentication
MCP SEP-1933 workload identity federation	Proposes exchanging platform-issued workload JWTs for MCP access without static OAuth client secrets	Kubernetes, SPIFFE/SPIRE, or cloud runtime credential would be validated and exchanged by authorization infrastructure	Headless agents, scheduled workers, CI/CD agents, and autonomous cloud workloads	Open proposal when reviewed; not merged, implementation testing marked `TBD`, and final normative details may change
Verifiable Attenuated Delegation for AI Agent Chains draft-00	Proposes linked child tokens that can only narrow authority, expiry, and depth	JWT access-token profile with rich authorization details, parent byte commitment, DPoP holder binding, status machinery, and offline verification	Experimental parent-to-child agent delegation where resource servers need to verify the full chain without contacting every issuer	Individual draft-00 with no standards consensus or reported interoperability; policy vocabulary and revocation/completeness assumptions need validation

Observed Profiles

SPIFFE: runtime identity before agent identity branding

SPIFFE defines three central components: a URI-form SPIFFE ID, a SPIFFE Verifiable Identity Document, and a Workload API. The SVID carries the identity and cryptographic properties needed to establish authenticity and possession. The local Workload API supplies credentials and trust bundles after identifying the calling process through out-of-band platform information.

This is a stronger foundation than an API key copied into every agent container. A SPIRE deployment can attest nodes and workloads, issue short-lived identities, and separate workloads sharing the same host. The resulting identity can name an agent runtime, tool gateway, background worker, or model-serving component.

The boundary is equally important: SPIFFE does not say that spiffe://example.org/agent/payments may refund a specific customer. It authenticates the workload. The resource server still needs a user or service delegation context, resource and audience binding, amount or action constraints, and current policy.

An agent platform should therefore record at least two identifiers on consequential calls:

workload subject: the attested process or service presenting the credential;
represented subject: the user or upstream service whose authority is being exercised.

WIMSE: a standards architecture for heterogeneous workload systems

The IETF WIMSE architecture draft describes protocols and payloads for workload identity and security context across multi-system environments. Its model includes trust domains, workload identifiers, credentials, context, cross-domain communication, and policy enforcement. The practices draft surveys how Kubernetes, SPIFFE, cloud platforms, CI/CD systems, and service meshes deliver workload credentials without requiring software to manage long-lived secrets directly.

For agent infrastructure, WIMSE matters because autonomous agents look operationally like workloads even when their application semantics are unusual. They run in pods, virtual machines, serverless functions, sandboxes, CI jobs, or managed agent runtimes. Those environments already have identity signals that can be exchanged instead of inventing an agent_id string inside a prompt.

WIMSE is not yet a single agent identity protocol. The architecture and practices documents are informative Internet-Drafts, and associated credential and workload-to-workload work is still evolving. Adopters should use the vocabulary and threat model while pinning exact draft versions rather than claiming standards conformance broadly.

RFC 8693: token exchange and actor history

OAuth Token Exchange lets a client present a subject_token and, optionally, an actor_token to obtain another security token. It distinguishes impersonation, where one party acts as the subject, from delegation, where an actor acts on behalf of a subject. The issued JWT can use an act claim to identify the current actor and nested act claims to retain prior actors.

This mechanism is useful when an agent gateway needs a token for a specific downstream API rather than forwarding the user’s original token. The authorization server can validate the incoming subject and actor, apply local policy, and issue a token with a new audience, resource, scope, and lifetime.

However, the act chain is not a capability attenuation proof. RFC 8693 says prior-actor claims carry delegation history; it does not define a universal ordering over scopes, payment amounts, data sets, side effects, expiry, or chain depth. A downstream service cannot infer that the current actor has less authority merely because more act claims are nested.

OAuth identity chaining: preserving context across authorization domains

OAuth Identity and Authorization Chaining draft-17 addresses requests that cross multiple OAuth trust domains. A client in Domain A obtains a JWT authorization grant through token exchange, then presents that grant to Domain B’s authorization server using the RFC 7523 JWT authorization-grant flow. Domain B issues its own access token after validation.

This is relevant to agents operating across enterprises, clouds, or SaaS providers. The mechanism avoids treating the first domain’s access token as valid everywhere and gives each domain an authorization decision. It can preserve the original subject, current client, authorization details, and optional call-chain information as the request advances.

The risk is transitive overtrust. A valid grant from Domain A is not a command to Domain B. Domain B must trust the issuer for the relevant purpose, authenticate the requesting client, verify audience and expiry, constrain claims it transcribes, apply its own policy, prevent replay, and minimize identity information disclosed across the boundary.

DPoP: proof of possession without proof of permission

DPoP uses signed JWT proofs to bind an OAuth token to a public key. A proof identifies the HTTP method and URI, carries a time and unique identifier, and can include an access-token hash and server-provided nonce. An authorization or resource server validates the proof and confirms that the token is bound to the same key.

For agents, DPoP reduces the value of an access token stolen from logs, caches, traces, or another endpoint. The thief also needs the private key. A server nonce can strengthen freshness and make pre-generated proof attacks harder.

DPoP should not be marketed as agent attestation. A key may live in the same compromised process as the model runtime. The legitimate holder can still replay within accepted windows, request an unsafe operation, or use an overbroad token. DPoP sender-constrains authority; it does not determine the right authority.

MCP: user-backed ID-JAG and proposed workload federation

MCP Enterprise-Managed Authorization is a stable extension for environments where an employee signs into an MCP client through an enterprise IdP. The client exchanges the resulting identity assertion for an ID-JAG targeted to the MCP authorization server and optional MCP resource. The MCP authorization server validates the grant and issues its own access token.

The flow preserves a user-backed enterprise policy decision while avoiding a separate browser consent ceremony for every approved MCP server. Its specification still requires careful audience, resource, scope, subject, client, expiry, signature, account-linking, and multi-tenant handling. A stable extension label does not imply that every MCP client or IdP implements it.

SEP-1933 addresses a different caller: an autonomous workload that already receives a short-lived JWT from Kubernetes, SPIFFE/SPIRE, or a cloud platform. The proposal argues that forcing such software to register an OAuth client and keep a long-lived secret duplicates identity lifecycle and weakens posture. Workload federation would validate and exchange the platform credential for MCP access.

The maturity difference is material. The MCP roadmap prioritizes workload federation, but the reviewed pull request remained open, its testing section said TBD, and it was not part of the stable extension. Operators can build equivalent federation with current cloud and OAuth systems, but should not claim MCP SEP-1933 compliance until a final specification and tests exist.

Experimental attenuated chains: making narrowing verifiable

Verifiable Attenuated Delegation for AI Agent Chains draft-00 proposes a response to a specific gap: a parent agent should be able to delegate to a child while any enforcement point verifies offline that every hop narrowed authority. The draft represents authority using Rich Authorization Request-style details, links each child to the exact parent token with a byte commitment, constrains lifetime and depth, and uses proof-of-possession and status mechanisms.

The idea differs from RFC 8693 actor history. Instead of merely saying which actors appeared, a verifier applies deterministic subsumption rules to check that the child cannot exceed the parent in scope, magnitude, time, or chain depth.

That design is promising for payment, deployment, data-release, and infrastructure agents, but draft-00 is evidence of a problem and proposed architecture—not market-ready interoperability. Operators would need shared semantics for comparing permissions, canonical token bytes, protected parent-key custody, status freshness, chain-size limits, algorithm policy, and behavior when a parent remains valid after issuing a narrower child.

A resource server also needs application state. A cryptographically valid limit of $500 is unsafe if the user has already approved and spent $500 through a sibling chain. Global budgets, separation of duties, duplicate prevention, and business reconciliation cannot be proven from one delegation token alone.

A production identity and delegation pipeline

A production agent platform can apply the layers in this order:

Attest the runtime. Establish which workload is executing through SPIFFE, a cloud workload identity, Kubernetes identity, or another platform authority.
Identify the represented subject. Preserve the user or upstream service separately from the workload.
Exchange, do not pass through. Ask the target authorization domain for a token intended for the exact resource and audience.
Narrow authority. Reduce scopes, resources, action classes, amounts, regions, task phase, lifetime, and delegation depth for each child.
Bind the holder. Use mTLS, DPoP, or another proof-of-possession mechanism where token replay is a relevant threat.
Authorize the concrete action. Evaluate current arguments, target state, tenant, user policy, risk, and required approval at the enforcement point.
Record the chain. Log the workload subject, represented subject, issuer, audience, resource, scopes or authorization details, parent-child correlation, proof key, policy version, and approval.
Reconcile the outcome. Obtain an authoritative receipt or read final state from the business system.
Revoke and expire. Design what happens when the user leaves, the workload is replaced, a parent is compromised, a child is cancelled, or status infrastructure is unreachable.

This pipeline prevents four common substitutions: workload identity for user permission, actor history for attenuation, proof of possession for safety, and a successful API response for confirmed business outcome.

Evaluation checklist

Ask an agent identity or delegation provider:

What exact identifier names the running workload, and how is it attested?
How is the represented user or upstream service preserved separately?
Which RFC, MCP extension, WIMSE draft, or SPIFFE specification version is implemented?
Is the credential a bearer token, DPoP-bound token, mTLS certificate, SVID, ID-JAG, or vendor wrapper?
Are issuer, subject, client_id, actor, audience, resource, scope, and authorization details independently available to policy?
Does each delegation mint a new token, or does the system copy a parent credential?
Can a child expand any permission, amount, data class, geography, lifetime, or delegation depth?
How are sibling-chain budgets and previously consumed authority reconciled?
How quickly do user, workload, parent, and child revocations propagate?
What happens if JWKS, token status, IdP, or authorization-server infrastructure is unavailable?
Can the resource server verify the relevant chain offline, and what freshness does that sacrifice?
Is token passthrough technically blocked at MCP and upstream API boundaries?
Which interoperability and negative tests prove audience, replay, chain-splicing, tenant, and expiry enforcement?
Can audit records connect the identity chain to human approval and authoritative outcome receipts?

Limitations

This analysis relies on public specifications, RFCs, Internet-Drafts, repository materials, and an open MCP proposal. It does not include private product architecture, enterprise contract terms, production incident data, formal cryptographic review, implementation source review, or cross-provider interoperability testing.

Internet-Drafts can change, expire, be replaced, or fail to become RFCs. In particular, OAuth Identity and Authorization Chaining draft-17, the WIMSE architecture and practices drafts, and Verifiable Attenuated Delegation for AI Agent Chains draft-00 must be treated as work in progress. MCP SEP-1933 was an open proposal with incomplete test evidence when reviewed.

The analysis compares architectural functions rather than equivalent products. SPIFFE, WIMSE, OAuth Token Exchange, DPoP, ID-JAG, and an attenuated-chain profile solve different parts of identity and authorization. The table should not be interpreted as a feature ranking.

No mechanism was tested under workload compromise, IdP compromise, authorization-server compromise, signing-key theft, malicious child agents, stale status data, cross-tenant subject collisions, or partial network failure. Token-size growth and verification cost may become material in deep delegation chains but were not benchmarked.