RFC 8693 is one of the cleaner solutions in the OAuth ecosystem. One token in, one token out. The subclaim carries the original subject — the user who authorized the action. The actclaim carries the actor — the service actually performing it. A downstream resource server receives a token and can answer two questions simultaneously: who ultimately authorized this?and who is actually doing it?That's delegation with accountability, and it's how Okta handles impersonation and on-behalf-of flows today.
For a single-hop workflow, this is genuinely elegant. A user authorizes a scheduling assistant to access their calendar. The assistant calls the calendar API with an exchanged token. The API sees the user as subject, the assistant as actor, validates the scope, and proceeds. The audit log is clean. Revocation is straightforward — invalidate the user's authorization and the assistant's derived token stops working. The model holds.
Now add a hop.
The Architecture That Breaks the Map
In a multi-agent workflow, the scheduling assistant doesn't just call a calendar API. It calls a travel-booking agent, which calls a payment processing agent, which calls a vendor API. Each agent in that chain needs to act on behalf of the original user. Each hop needs to carry identity context forward. The map you're holding stops describing real territory somewhere around hop two.
RFC 8693 does have a mechanism for this. Section 4.1 describes the act claim as a JSON object that can itself contain an act claim — nested delegation, chains represented as nested structures. So technically, a token could carry: "Agent C is acting on behalf of Agent B, which is acting on behalf of Agent A, which is acting on behalf of User Y." The data structure exists. Read the RFC carefully enough and you'll find it.
The representation is the easy part. Validation is where the standard goes quiet.
The RFC provides no normative guidance on how a resource server should validate a nested chain. Should it verify each actor in the chain independently? Against what trust anchor? If Agent B's client credentials have been compromised since the chain was established, does the resource server at hop three have any standard mechanism to detect that? The answer is no. Chain validation at that level requires infrastructure that didn't exist when 8693 was written and doesn't fully exist now. The RFC authors saw the topology coming; they couldn't build the ecosystem agreement it requires.
Scope semantics across hops are similarly undefined. If Agent A holds a token with scope calendar:read and calls Agent B, which needs payments:write to complete the user's request — what happens? Agent B can request a new token with the expanded scope. The authorization server may grant it. The original user, who authorized calendar:read for a scheduling assistant, has now implicitly enabled a payment transaction through a chain they cannot see. The structural cause is scope being evaluated at each hop independently, with no reference back to what the user originally authorized.
And then there's revocation. If the user revokes their authorization midway through a multi-hop workflow, the token at hop one becomes invalid. But Agent B's token — exchanged from Agent A's token before revocation — may still be valid. Standard OAuth revocation propagates to derived tokens in some implementations and not others. In a chain of three or four hops, with tokens exchanged at each step, "revoke the user's authorization" becomes a question without a standard answer.
What the Community Is Actually Saying
The MCP specification — Anthropic's protocol for how AI agents interact with tools and other agents — has been working through exactly this problem in its GitHub discussions. The threads are worth reading, with appropriate calibration: this is a working group in motion, not settled guidance. The proposals cluster around two approaches. One camp argues for passing the original token through the chain unchanged, preserving the user's original authorization context at every hop. The other camp argues for per-hop exchange, which preserves least privilege at each step but loses chain visibility at downstream services.
Pass-through preserves the user's original authorization context at every hop but breaks least privilege: Agent C gets a token scoped for Agent A's original task, which may be far broader than what Agent C needs. Per-hop exchange preserves least privilege but loses chain visibility: the resource server at hop three sees Agent B acting on behalf of the user, with no visibility into Agent A's role in the chain or whether Agent A's authorization is still valid. Each approach trades one guarantee for another, and neither trade is obviously correct.
The OAuth working group has been aware of this tension. There are draft proposals circulating for a chain claim that would carry the full delegation sequence in a verifiable structure, with each link signed by the issuing authorization server. As of this writing, none of these proposals have advanced to RFC status. The people writing them are credible — this isn't Reddit speculation — but the timeline for standardization is measured in years, not quarters.
Okta's publicly announced capabilities in the agentic space — agent discovery, short-lived credentials, and the Cross-App Authentication (XAA) framework — address parts of this problem. Short-lived credentials reduce the revocation window at each hop. Agent discovery creates a registry of known agents with verified identities, which is a prerequisite for chain validation. XAA provides a structured way for agents to authenticate to each other across application boundaries. What these capabilities don't yet provide, at least in any publicly documented form, is a normative chain validation model: a standard by which a resource server at hop N can verify the integrity of the full delegation chain from the user through every intermediate agent. That gap is real, and it's not unique to Okta; no major identity provider has closed it, because the standards layer isn't there yet.
What "Agent Identity Governance" Actually Means
When that phrase appears in an RFI — and it is appearing, in SAM.gov solicitations, in agency AI strategy documents, in CAIO public statements — it is procurement officers translating policy requirements into technical language. The policy source is usually OMB M-24-10 or the NIST AI Risk Management Framework, both of which emphasize accountability and auditability for AI-driven actions. The technical question underneath the procurement language is the one this article just traced: For any action taken by any agent in your system, can you tell me who originally authorized it, through what chain of delegation, with what scope at each step, and whether that authorization is still valid?
That's an audit requirement and a revocation requirement, and in the current state of the standards landscape, no vendor can answer it with a fully standardized implementation. Every answer you'll see in a proposal response is a proprietary implementation of something the standards community is still designing.
This matters for how you position in a discovery call. When a CAIO or their technical staff asks about agent identity governance, they are not asking whether you support RFC 8693. They almost certainly know you do. They are asking whether your implementation can answer the audit question — and whether it will still answer that question when their agency is running a mixed-vendor environment with agents from three different platforms calling each other across trust boundaries.
The honest and technically fluent answer is that the standards layer for multi-hop chain governance is forming but not formed, that your implementation addresses specific parts of the problem (name them precisely: short-lived credentials, agent registration, per-hop exchange), and that the interoperability question across vendor boundaries is the open one. Buyers who are sophisticated enough to put "agent identity governance" in solicitation language are sophisticated enough to respect that answer. They have read the same OMB guidance. They know the field is moving. What they cannot afford is a vendor who papers over the gap with confident claims that collapse under technical scrutiny.
Skip "do you need agent identity governance?" They've already told you they do. Ask instead what the audit team needs to see when an agent takes an action that turns out to be wrong. That question surfaces the actual requirement: is it a log? A real-time alert? A chain-of-custody record that survives litigation? The answer shapes what implementation actually matters, and it moves the conversation from standards compliance theater to genuine architecture discussion.
The Map and the Territory
RFC 8693 is not broken. It solved the problem it was designed to solve, and it solved it well. The nested act claim is a thoughtful provision for a future the authors could see coming. What they couldn't build into the RFC was the validation infrastructure, the scope inheritance semantics, and the chain revocation model, because those require ecosystem-level agreement that the ecosystem hadn't reached.
Agentic workflows have arrived faster than that agreement. The gap between the representation RFC 8693 provides and the governance layer it doesn't is exactly the gap your buyers are trying to close when they write "agent identity governance" into solicitation language. They're not asking for something exotic. They're asking for the thing that makes OAuth delegation trustworthy (accountability, auditability, revocability) extended to a topology that the original delegation model wasn't designed to govern.
Knowing that the gap is structural rather than implementational is the difference between a conversation that builds credibility and one that loses it. The buyer will find the gap eventually. Better that they find it with you than after you've left the room.