Matias Saenz · August 2026
I read the Entra Agent ID docs, Okta's AI agent material, RFC 8693, and every active IETF draft on agent delegation I could find. Here is exactly where the chain breaks when an agent crosses from one organization into another, and the layer nobody has claimed.
The intra-org story is basically solved. If your AI agent lives inside one tenant, Entra Agent ID and Okta's agent identity work will get you delegated tokens, conditional access, and a clean audit log. The vendors did their job.
The problem starts the moment the agent leaves the building. A provider's prior-auth agent calling into a payer's system. A broker's agent hitting a carrier's TMS. A procurement agent transacting against a supplier. In every one of these, the agent acts on behalf of a human in Org A against a system owned by Org B, and the identity stack that worked beautifully inside Org A has nothing to say to Org B.
I found three specific breakpoints. Each one is in the primary documents, not in anyone's marketing.
Entra's Agent ID model handles delegation with on-behalf-of token exchange. A user consents, the agent gets a token scoped to resources inside the same tenant, and every hop is verifiable because one identity provider issued and can validate every token in the chain. Inherited delegated permissions are explicitly limited to within tenant boundaries. It works because there is a single trust root.
Cross-org breaks this at the first hop. When the provider's agent calls the payer's API, the payer's IdP has never seen the provider's tenant, didn't mint the token, and has no policy object for "external org's user, delegating to an external agent." So everyone falls back to the same three workarounds, and all of them collapse the chain:
- Service accounts. The payer's audit log now reads "PriorAuthBot did it." Which provider? Which patient case? Which human authorized it? Gone.
- Static API keys. Same collapse, worse rotation story.
- OAuth client credentials between the two companies. This authenticates the vendor, not the delegated act. It proves Acme Health Inc. called the API. It proves nothing about who at which provider authorized what.
Nothing in the shipped products carries "User X at Org Y authorized Agent Z to do exactly this" across the boundary in a form the receiving side can verify.
RFC 8693 lets you nest act claims, so a token can record User → Agent 1 → Agent 2 → Tool. Looks like a delegation chain. Then Section 4.1 takes it away:
"For the purpose of applying access control policy, the consumer of a token MUST only consider the token's top-level claims and the party identified as the current actor by the act claim. Prior actors identified by any nested act claims are informational only and are not to be considered in access control decisions."
The chain is a history trail you may log, not a structure you may enforce. The final resource server can validate the last signature and the current actor. The original human and every intermediate hop are invisible to policy — by the standard's own instruction.
It gets worse. A February 2026 thread on the OAuth WG list, under the name "delegation chain splicing," walks through the consequence: RFC 8693 doesn't require cross-validation between the subject_token and actor_token presented at exchange. A compromised intermediary can present a valid subject token and a valid actor token that came from different delegation contexts, and the STS, validating each independently, issues a properly signed token asserting a chain that never happened.
The working group knows. There's a cluster of active drafts attacking the problem from different angles:
- draft-ietf-oauth-identity-chaining (WG document): token exchange → JWT authorization grant → present to the second domain's AS. A real cross-domain pattern, but it requires a pre-established trust relationship and key material between the two authorization servers. For a market like healthcare, thousands of providers, dozens of payers, mostly low-frequency pairings, that bilateral mesh never gets built. The flow degrades back to service accounts.
- draft-sharma-oauth-identity-propagation-context-01 (Ericsson): per-hop cryptographic re-signing so identity context can be used in access control, directly fixing the "informational only" problem. The draft itself scopes it to multi-hop chains within a single trust domain and states it is not suitable for cross-organization federation.
- draft-niyikiza-oauth-attenuating-agent-tokens-01 (Tenuo): offline-derivable attenuating tokens, a holder can derive a narrower token with no AS round trip, and the chain verifies offline against the root trust anchor. This is genuinely new and there's a working reference implementation. It solves attenuation. It doesn't solve who the foreign resource server trusts as the root anchor, or the audit custody problem below.
- draft-mw-oauth-actor-chain-01 (successor to draft-mw-spice-actor-chain; engineers from Oracle, JPMorgan Chase, Telefonica, Aryaka): tamper-evident actor-path records with actor-signed step proofs, so a receiver can verify the full delegation path rather than trusting the immediate sender. It claims cross-domain support, ships a reference implementation, and is seeking WG adoption, the most serious verification-side work in the cluster.
- draft-liu-oauth-chain-delegation and draft-li-oauth-delegated-authorization: per-hop constraint records and locally issued subordinate tokens, respectively.
Six drafts, each owning one piece. Which is exactly the point.
Inside one tenant, the issuing IdP logs the full exchange. The moment the call crosses an org boundary, the receiving system's audit log records whatever principal it was handed — usually a service account. The original user's consent, the agent's identity, and the intermediate hops live in the first org's logs, if they were captured at all.
There is no standard, portable, cryptographically linked audit artifact that travels with the request and that both orgs' compliance systems will accept. So every SOC 2, HIPAA, or financial-controls review of a cross-org agent action fails the same question: who authorized this, under what exact scope? The provider's logs say one thing, the payer's logs say another, and the object that would join them doesn't exist in production software.
Revocation is worse. If the user withdraws consent or the provider offboards the agent, there is no interoperable signal that cascades to the foreign org. The universal-logout work is early. Today, revocation across a boundary means a phone call.
Here's the honest summary of the landscape. A year ago I could have written "none of this is deployed." That's no longer true, Tenuo has working attenuation code, the actor-chain draft has serious names behind it, and the WG is actively arguing about splicing. The pieces are being built.
But look at who's building what. Microsoft and Okta monetize the tenant; their agent identity products stop precisely where the tenant's revenue does. The draft authors each own one hop: attenuation, or chain records, or intra-domain propagation. Nobody owns the boundary itself, the neutral position both orgs have to trust because it belongs to neither.
The missing layer is concrete:
- A verifier any resource server can run, a library or sidecar that consumes an RFC 8693 token plus an identity-chaining grant plus attenuating-token context, cryptographically checks the full chain and scope contraction at every hop, and rejects if any hop is missing or expanded. The piece that makes prior actors stop being "informational only."
- A portable, signed audit and revocation receipt, an artifact both orgs can independently verify and store, so the provider's compliance team and the payer's compliance team are for once looking at the same object.
- The smallest possible trust bootstrap, two orgs establish the key relationship once, and agents cross the boundary without collapsing to service accounts.
The intra-org problem got solved by the companies that own the tenant. The cross-org problem won't be, for the same reason. It needs a party whose entire position is the boundary.
I'm building the open-source verifier first, starting with the attenuation-chain format, targeting a working reference within three weeks. If your agents cross org boundaries today and you're answering security reviews with a service account and a Notion doc, I want to hear how that's going: matiassaenzinc@gmail.com, https://www.linkedin.com/in/matiassaenz/
Sources: RFC 8693 §4.1; Microsoft Entra Agent ID documentation; Okta AI agent identity documentation; draft-ietf-oauth-identity-chaining; draft-sharma-oauth-identity-propagation-context-01; draft-niyikiza-oauth-attenuating-agent-tokens-01; draft-mw-oauth-actor-chain-01; draft-liu-oauth-chain-delegation; draft-li-oauth-delegated-authorization; OAuth WG mailing list, "Delegation Chain Splicing in RFC 8693 Token Exchange," February 2026.