Consider what happens when a user authorizes an enterprise agent to complete a research task. The user instructs the orchestrator agent. The orchestrator decomposes the task and delegates three sub-tasks to specialist agents — one for document retrieval, one for synthesis, one for external API lookup. Each specialist invokes tools to complete its sub-task. Those tool invocations require credentials. The credentials were provisioned to the orchestrator by the enterprise’s identity infrastructure on the basis of the user’s authorization.
At every step in that chain — orchestrator to specialist, specialist to tool, tool to external API — an authorization claim is being made. The orchestrator asserts that the specialist is authorized to receive the task. The specialist asserts that it has authority to invoke the tool. The tool asserts that it is operating on behalf of a user with the relevant permissions. None of these assertions are cryptographically verifiable. They are all text. The authorization chain has no receipts.
The practical consequence is precisely the 100% inter-agent trust exploitation rate documented in Post 1. An attacker who can insert a message into the agent’s processing pipeline — through prompt injection, supply chain compromise, memory poisoning, or rogue agent impersonation — can claim any identity and authorization level, because no mechanism exists to verify the claim. The trust that flows through the delegation chain is implicit, assumption-based, and structurally forgeable.
Why OAuth Does Not Solve This
OAuth 2.1 was recently added as an authentication option to MCP. This is genuine progress — it closes the single-hop authentication gap between a client agent and an MCP server. The addition of OAuth means that an MCP server can now verify that the connecting client has been authenticated by a trusted identity provider. This matters. It is not sufficient for multi-hop delegation.
The Multi-Hop Delegation Gap
OAuth 2.1 in MCP verifies that Agent A is authenticated to connect to Server B. It does not verify that Agent A was delegated authority by User U to perform Task T with Constraints C. When Agent A connects to Server B and invokes a tool, Server B knows that Agent A holds a valid OAuth token. It does not know what authorized Agent A to make this specific invocation, whether that authorization flows from a legitimate user intent, or what the delegation chain looks like upstream.
When Agent A delegates to Agent C, and Agent C invokes Server D, Server D receives an OAuth-authenticated request from Agent C. It has no visibility into the authorization chain that led to that request. Agent C could be a legitimate specialist acting on a valid delegation from Agent A. It could be a rogue agent that captured a token. It could be an impersonator claiming Agent C’s identity. OAuth establishes that the connection is authenticated. It does not verify that the invocation is authorized within a traceable delegation chain.
The gap is not a failure of OAuth’s design. OAuth was designed for the client-server case: a client presents credentials and a server decides whether to grant access. The multi-agent delegation case is structurally different: an orchestrator grants limited authority to a specialist, who may further delegate to sub-specialists, who invoke tools, which call external APIs. Each step in the chain should be carrying forward a cryptographically verifiable record of what was originally authorized and by whom. OAuth does not carry that record — and it was not designed to.
What IBCTs Provide
Prakash’s AIP research identifies a gap in the existing identity standards landscape that is precise: in his survey of eleven categories of prior work, no existing implemented protocol jointly combines public-key verifiable delegation, holder-side attenuation, expressive chained policy, transport bindings across MCP/A2A/HTTP, and provenance-oriented completion records. IBCTs are designed to fill that gap.
Questions that every agent action should be able to answer, per the IBCT design: Who authorized this action? (verifiable identity at the origin of the delegation chain) Through which delegation chain? (the full chain from user to orchestrator to specialist, cryptographically linked) With what constraints at each hop? (attenuation — each delegation can only reduce scope, never expand it) What was the outcome? (provenance-oriented completion records for forensic auditability)
The four-question framework is the design criterion. Any token architecture for agent delegation that cannot answer all four questions for every action is incomplete. OAuth answers the first question partially for single-hop cases and provides no coverage for the others. Bearer tokens without delegation binding answer none of the four questions. IBCTs are designed to answer all four.
The two wire formats
AIP provides two token formats addressing different deployment scenarios. The choice between them is determined by the delegation depth required.
- 1 Compact mode — signed JWT with Ed25519 signatures. Designed for single-hop interactions: an agent calls a tool directly, with no intermediate delegation. A standard JWT signed with Ed25519 carries the identity, authorization scope, and provenance binding. Compact, fast, compatible with existing HTTP infrastructure. Does not support multi-hop delegation chains — the chained mode is required once any delegation occurs.
- 2 Chained mode — Biscuit token with Datalog policy evaluation. Designed for multi-hop delegation. A Biscuit token is an append-only structure: each delegation step adds a block containing the delegating agent’s identity, the scope granted to the delegate, and the constraints applying to that hop. Critically, each block is signed by the delegating agent at the time of delegation — so the token carries a cryptographically verifiable record of every delegation step, with scope constraints that can only narrow at each hop. A downstream component that receives the token can verify the entire chain.
The attenuation property of chained mode is architecturally significant. It enforces a structural principle: delegation can only reduce scope, never expand it. An orchestrator agent granted read-only access to a document corpus cannot delegate write access to a sub-agent. The sub-agent cannot re-delegate beyond the scope it received. Each hop in the chain adds a new block with equal or narrower permissions, signed by the delegating agent. A forged delegation that attempts to escalate scope produces a chain that fails verification — because the forged block cannot be signed by the legitimate delegating agent’s key.
Authorization as Assertion
When Agent A delegates to Agent B, Agent A sends a message instructing Agent B to perform a task. The message may claim that A is authorized to make this delegation. Agent B has no cryptographic mechanism to verify the claim. If Agent A’s context has been injected with a rogue instruction, Agent B cannot distinguish legitimate delegation from impersonation.
Tool invocations carry OAuth tokens establishing that the invoking agent is authenticated. They carry no record of the delegation chain that led to the invocation, what was originally authorized, or what scope constraints apply at this specific hop.
The downstream tool or external API cannot reconstruct the authorization chain. Audit logs record what was called. They cannot verify that it was legitimately authorized through a traceable chain from user intent.
Assertion-Based · Unverifiable ChainAuthorization as Cryptographic Chain
When Agent A delegates to Agent B, Agent A appends a delegation block to the IBCT — signed with A’s key, scoped to B’s identifier, with the constraints that apply to this hop. Agent B cannot forge this block. Agent B can verify that A was legitimately authorized upstream by inspecting the chain above A’s block.
Every tool invocation carries the full delegation chain from user authorization through every intermediate agent. The tool verifies the complete chain. Scope attenuation is enforced: no hop can expand beyond the authority granted in the block above it.
The maximum delegation depth is configurable (default: 3 hops). If depth is exceeded, further delegation is forbidden — a structural limit on delegation chains that prevents unbounded task graph expansion beyond authorized scope.
Chain-Verified · Scope-AttenuatedThe Adoption Gap and What It Means for Enterprise Teams
AIP is technically sound. Its adoption picture in April 2026 is less settled. The protocol exists as an arXiv preprint, an alpha-stage PyPI package (version 0.1.1, released April 2, 2026), and an IETF Internet-Draft. Neither Anthropic (which created MCP) nor Google (which created A2A) has endorsed it. The MCP Dev Summit in April 2026 dedicated multiple sessions to authentication and security — a signal that the ecosystem acknowledges the gap — but no protocol has been designated as the standard solution.
The Standards Convergence Observation
For identity protocols, technical correctness is necessary but not sufficient for adoption. A technically perfect protocol with no ecosystem adoption is an academic exercise. The patterns that lead to standards adoption — institutional backing, reference implementations, developer tooling, governance body endorsement — are present in the ecosystem’s trajectory (MCP donated to the Agentic AI Foundation under the Linux Foundation; SPIFFE/SPIRE providing workload identity infrastructure) but have not yet converged on a single delegation protocol. Enterprise teams should track AIP, WIMSE (Workload Identity in Multi-Service Environments at the IETF), and SPIFFE as the leading candidates while preparing their architecture to accommodate whichever standard achieves ecosystem convergence.
The practical enterprise implication is not to wait for standards convergence before addressing the delegation gap. The gap is present now, and its consequences are documented empirically. The near-term action set draws from the patterns that any eventual standard will incorporate: implement explicit scope constraints on every delegation step; ensure that authorization claims are attributable to a specific user authorization event with a traceable chain; design delegation architectures with configurable depth limits; and build the audit infrastructure that will be required to verify delegation chains once cryptographic standards are deployed.
OAuth tells you who made the call. IBCTs tell you who authorized the call to be made, through which chain, with what constraints, and what the outcome was. For enterprise agentic AI operating at task-graph scale, those are not the same question.
— Luminity Digital synthesis from arXiv:2603.24775, Prakash, March 2026The delegation chain is the authorization chain. When it has no receipts — no cryptographically verifiable record of who authorized what, through which agents, with what constraints — every downstream component is operating on an unverifiable trust claim. IBCTs provide the mechanism that closes this gap for both single-hop and multi-hop delegation. The adoption timeline is uncertain. The architecture requirement is not: any enterprise deployment that cannot answer the four IBCT questions for every agent action does not have a verifiable delegation architecture. Post 3 maps what it takes to build one.
