Anton Staykov

Posted on Jul 14

The industry does not have an agent identity propagation standard yet

#entraagentid #identitystandards #oauth #aiagents

Most architecture conversations about AI agents still get stuck on the wrong boundary.

Someone draws an agent in Azure, another agent in AWS, a resource behind Ping Identity or Auth0, a Microsoft Entra-protected API, an MCP server in the middle, and a user somewhere at the beginning of the chain. Then the room asks: can Microsoft Entra Agent ID work if the agent is not hosted on Microsoft infrastructure?

That is the easy question. Hosting is not the boundary.

Identity provider domain is the boundary.

An application can live in AWS, Google Cloud, a co-location rack, or a basement server room and still use Microsoft Entra ID for sign-in. The same principle applies to agents. Microsoft explicitly positions Entra Agent ID as working with Microsoft and non-Microsoft platforms, including integrations through the Microsoft Entra Auth SDK sidecar and workload identity federation (Microsoft Entra Agent ID, third-party agent integration patterns).

The hard part starts when the flow leaves one identity provider and must preserve the original user context in another identity provider's world.

That is where the industry is still awkward. Not because there are no standards. There are standards. The problem is that the standards describe token exchange mechanics better than they describe enterprise trust governance for long, agentic, multi-hop chains.

The diagram above is the mental model. A user signs in, an application invokes an agent, the agent calls a tool or MCP server, another agent appears, and eventually a REST API or database needs to decide whether to trust the original user's context. Some arrows stay inside Microsoft Entra. Some arrows cross into Ping Identity or another provider. Some resources are custom APIs. Some are Microsoft resources. Some are agentic systems calling other agentic systems.

The diagram looks like a flow. In practice, it is a chain of trust decisions.

Federation is not token exchange

One of the most useful audience questions in the discussion was simple: "We already solve multiple identity providers with federation. Why is this different for agents?"

That question matters because it separates two things teams often blend together.

Federation solves an interactive authentication problem. A user starts at one identity provider, is redirected to another identity provider, proves who they are, and returns with a token or assertion the application can use. That pattern is well understood in SAML, OpenID Connect, and enterprise SSO designs (OpenID Connect Core, Microsoft identity platform and OpenID Connect).

Token exchange solves a different problem. A component that already received one token asks an authorization server for another token intended for a different resource or context. The standard that most directly describes this is OAuth 2.0 Token Exchange, RFC 8693. RFC 8693 defines a Security Token Service style protocol for requesting and obtaining tokens from OAuth authorization servers, including delegation and impersonation semantics.

Those are not the same motion.

Federation is the front door. Token exchange is what happens in the hallway after the front door has already closed.

That distinction becomes brutally important for agents because agents create more hallways. A user does not simply sign in and call one API. The user asks an agent, the agent calls a tool, the tool calls an MCP server, the MCP server calls another agent, and that agent calls a REST API. Each hop may need a different token audience, a different scope, a different policy evaluation, and a different interpretation of who is acting.

RFC 8693 gives us language, not the whole operating model

RFC 8693 is important because it gives the industry precise words for what keeps showing up in agent conversations: subject_token, actor_token, audience, resource, scope, act, and may_act (RFC 8693).

It also draws a clean line between impersonation and delegation. In impersonation, principal A becomes indistinguishable from principal B within the token's rights context. In delegation, principal A remains visible as the actor representing principal B (RFC 8693, delegation vs. impersonation). For agents, that distinction is not academic. An enterprise should almost never want an agent to become invisible as the human. It wants the user, the agent, and the delegation relationship to remain visible.

RFC 8693 also defines the act claim as a way to represent the current actor and even nested actor chains in a JWT (RFC 8693, actor claim). That sounds like exactly what we need.

But the standard is careful about its own boundary. It defines a protocol. It does not solve every deployment trust model. It explicitly leaves token semantics, policy decisions, and many security characteristics to implementations and deployment configuration (RFC 8693 introduction, RFC 8693 security considerations).

That is the gap.

The standard can describe a token exchange. It cannot, by itself, answer the enterprise question: who configured the mapping that allows an actor from identity provider A to arrive at identity provider B and claim a privileged user context?

That question is not protocol syntax. That question is governance.

Autonomous agents are the solved part

If there is no user context to preserve, the picture is much cleaner.

An autonomous agent can authenticate as itself using client credentials, a certificate, a federated identity credential, or a managed identity, depending on the platform and operating model. Microsoft Entra Agent ID supports autonomous access and delegated access as different modes for agent identities (what agent identities enable). The Microsoft Entra Auth SDK sidecar is not the authentication method for the agent itself. It is a token-handling pattern that keeps credential exchange, OBO flows, token caching, and credential-source abstraction outside the agent code (Microsoft Entra Auth SDK sidecar).

This is also where workload identity federation fits well. Microsoft documents workload identity federation as a way for applications to access Microsoft Entra-protected resources without managing secrets, by trusting tokens from external identity providers (workload identity federation). Entra Agent ID's third-party integration guidance describes agents on external platforms exchanging native workload identity tokens for Microsoft Entra tokens before calling APIs (integrate third-party agents).

This pattern is not limited to Microsoft. AWS, Google Cloud, Kubernetes ecosystems, and SPIFFE-based systems all lean into the same broad direction: give workloads short-lived, attestable identities instead of static secrets. SPIFFE describes itself as a set of open-source standards for identifying software systems in dynamic and heterogeneous environments, with short-lived identity documents called SVIDs delivered through a workload API (SPIFFE overview).

For fully autonomous agents, the industry has enough pieces to build sane systems today.

The agent proves what workload it is. The target resource validates the token. The authorization system checks the agent's assigned rights. No human context needs to survive the journey.

That is not trivial, but it is tractable.

User context is where the floor drops

The difficult case is the one the audience kept circling back to: an employee signs in, an agent acts on behalf of that employee, the flow crosses identity providers, and a downstream resource must still know which human user started the journey.

Microsoft Entra Agent ID supports on-behalf-of flows for agents. The documented OBO pattern uses a user token sent to the agent identity blueprint, then performs token exchanges so the resulting resource token carries the signed-in user's delegated context together with the agent identity (Agent OAuth flows: on behalf of flow). Microsoft recommends using approved SDKs such as Microsoft.Identity.Web or the Microsoft Entra Auth SDK sidecar because manual implementation is complex and error-prone (Agent OAuth flows: on behalf of flow, sidecar sample scenarios).

Inside one coherent identity domain, that is already a serious amount of machinery. Across identity providers, it becomes a trust governance problem.

The downstream system is no longer asking only, "Is this token valid?" It is asking a longer set of questions:

Who was the original user?
Which agent is acting now?
Which prior agents or services participated in the chain?
Which identity provider translated the context?
Who configured that translation?
Are we allowed to trust that mapping?
How do we monitor and revoke that trust when risk changes?

This is where the diagram matters. Six hops are not theoretical in an agentic architecture. They are what happens when a human asks one assistant to do work that uses an MCP server, which delegates to another specialized agent, which calls a vendor API, which then calls an internal API.

The standards do not stop you from creating such a chain. OAuth OBO style flows do not impose a natural business limit on how many middle tiers can appear. RFC 8693 can represent actor chains through nested act claims. In theory, the chain can keep growing (RFC 8693 actor claim).

Then the old boring transport layer walks into the room.

Bearer tokens are commonly presented to resource servers in the HTTP Authorization header field using Authorization: Bearer ... (RFC 6750, authorization request header field). HTTP deliberately does not define one universal maximum length for a field line, field value, or header section. Implementations set their own limits, and a server that receives request fields larger than it is willing to process is supposed to reject the request with an appropriate 4xx response, not ignore the fields (RFC 9110, field limits).

That means a perfectly valid access token can still be operationally too large for one proxy, gateway, service mesh sidecar, WAF, CDN edge, or application server in the path.

This is not only an availability problem. It is a security design smell. If every delegated hop adds nested actors, subjects, issuers, audiences, or other chain evidence, the token can grow until one component in the HTTP path handles it differently than the component that issued it or the API that validates it. Best case, the call fails cleanly. Worse case, a proxy truncates, drops, rewrites, retries, normalizes, caches, or falls back in a way the authorization model never expected. HTTP itself warns that ignoring oversized header fields increases exposure to request smuggling, and its security considerations explicitly call out attacks via protocol element length (RFC 9110, field limits, RFC 9110, attacks via protocol element length).

This is how a governance problem becomes an incident report. The identity system issued a token that was cryptographically valid. The architecture allowed a chain long enough to make that token huge. The application team assumed middleware would fail closed. The proxy team assumed the upstream API owned authorization. Then an agent reaches data it should not see because one hop in the path handled an oversized credential differently than another.

Who owns that failure?

The vendor that supported unbounded chaining? The architect who allowed policies with no practical chain-depth ceiling? The developer who never measured token size or actor-chain depth? The HTTP proxy that mishandled an oversized Authorization header? The operations team that changed a WAF limit two months ago and did not know it was now part of the identity control plane?

This is why "it worked two months ago" is such a dangerous sentence in agent identity. Nothing in the agent code needs to change for the chain to become too long. More tools get added. More agents call each other. More claims get preserved for audit. More tenants and issuers appear. Suddenly the same logical flow produces a larger token, crosses a different intermediary, and starts failing. Or worse, failing open.

But a representable chain is not automatically a governable chain.

That is the industry's current problem in one sentence: we can describe the chain better than we can govern the chain.

Evidence helps, but it does not create trust

Once the conversation moves from "can I get a token?" to "can the downstream system understand the context?" teams naturally reach for more data in the token.

That instinct is reasonable, but it is also incomplete. A downstream resource may need to know whether the caller is an agent, which agent is acting, which human user is present, which tenant owns the agent, whether the human is external to the resource tenant, or whether the agent is multi-tenant. That context can make downstream decisions smarter.

But more evidence in a token is not the same as trust.

Adding agent context, actor context, tenant context, or multi-tenant application context can make a downstream authorization decision more informed. It does not answer who approved the mapping, whether the source domain is trusted, whether the chain is still valid, or how the receiving domain should react when a risk signal changes.

That is the mistake to avoid. Token evidence can describe what arrived. Governance decides whether what arrived should be trusted.

The difference matters. Carrying context is easier than proving that the context should be trusted across organizational, identity provider, and agent boundaries.

The emerging standards conversation is really about trust evidence

When people ask for "the standard," they often mean one protocol that makes the whole diagram safe. That is not how this will land.

The industry is moving along several tracks at once.

OAuth token exchange gives us the exchange grammar (RFC 8693). Workload identity federation gives us a workable model for autonomous workload trust without secrets (workload identity federation). SPIFFE gives us an identity framework for workloads in heterogeneous environments, including JWT and X.509 identity documents (SPIFFE overview). Shared Signals and CAEP give the ecosystem a way to communicate security events and state changes continuously, rather than treating access decisions as one-time snapshots (OpenID Shared Signals Working Group). Agent protocols such as MCP and A2A are pushing tool and agent communication into more formal shapes, and Microsoft explicitly lists OAuth 2.0, MCP, and A2A among the protocols supported by the Entra Agent identity platform (Microsoft Entra Agent ID).

The center of gravity is shifting from "can I exchange a token?" to "what evidence travels with the token, and who is accountable for trusting it?"

That is the right shift.

The next generation of standards work has to answer questions the current protocol layer only exposes:

How does a receiving domain know the original user is still the same user after multiple agent and tool hops?
How does the chain preserve both the human subject and the current agent actor without collapsing into impersonation?
How are identity provider mappings approved, reviewed, expired, and revoked?
How does a downstream resource distinguish a first-party enterprise agent from a multi-tenant external agent acting for an enterprise user?
How do risk signals travel fast enough that a compromised account or agent does not keep operating on stale trust?

None of those questions are solved by adding one more token parameter.

They require standards that combine identity evidence, delegation semantics, risk signaling, authorization policy, and observability.

What architects should do now

The correct response is not to wait for the perfect standard. It is to design with the current product and trust boundary in mind.

First, separate platform location from identity provider domain. An agent running in AWS can still use Microsoft Entra Agent ID. An agent running in Azure can still call a Ping-protected resource. The host is an implementation detail. The issuer, audience, subject, actor, and trust mapping are the security model (third-party agent integration patterns).

Second, split autonomous agent flows from user-delegated flows before you draw the final architecture. Autonomous flows can be built today with client credentials, certificates, federated identity credentials, managed identities, workload identity federation, and standard token validation. A sidecar can help keep token acquisition and credential handling out of the agent code, but it is not itself the agent authentication method.

The delegated case is different. With Entra Agent ID today, do not design for an OBO flow that carries Microsoft Entra user context across an identity provider boundary and expects the other domain to preserve that context as part of the same delegation chain. Entra Agent ID supports OBO patterns for agents, but cross-IDP user-context propagation is not the supported operating model (Agent OAuth OBO flow). If the downstream system is governed by another identity provider, treat that as a separate trust domain. Either keep the delegated path inside one identity provider boundary, use autonomous workload-to-workload trust where user context is not required, or design an explicit application-level handoff with its own audit and policy model.

Third, avoid cross-domain impersonation unless the business process genuinely requires it and the audit model can survive scrutiny. Delegation should preserve the actor. Impersonation hides the actor from the resource's practical decision point. For agents, hiding the actor is usually the wrong instinct (RFC 8693 delegation vs. impersonation).

The real standard we are missing

The industry does not lack token standards. It lacks a complete, interoperable agent identity propagation governance model.

That model must preserve the original user where appropriate, preserve the current agent actor always, make cross-IDP mappings explicit, carry enough evidence for downstream decisions, propagate risk and revocation signals, and give enterprises a way to audit who allowed which transition.

OAuth token exchange is part of that answer. Workload identity federation is part of that answer. SPIFFE is part of that answer. Shared Signals and CAEP are part of that answer. Agent-specific identity platforms such as Microsoft Entra Agent ID are part of that answer.

But no single one of them is the whole answer yet.

That is the uncomfortable but useful conclusion from the diagram. We can build useful agent identity systems today. We can secure autonomous agents today. We can do delegated agent flows inside well-understood trust boundaries today. We can even cross platforms without much drama when the flow is autonomous or the trust boundary is explicit.

The thing we cannot hand-wave is multi-hop, user-bound, cross-IDP identity propagation.

That is the work ahead. Not just for Microsoft. For the industry.

DEV Community