---
source_block: agent-rbac-authorization.md
canonical_url: https://api.theorydelta.com/published/agent-multi-hop-delegation-no-enforcement
published: 2026-06-15
last_verified: 2026-05-31
confidence: medium
evidence_type: independently-confirmed
staleness_risk: high
rubric:
  total_claims: 10
  tested_count: 0
  independently_confirmed: true
  unlinked_count: 0
  scope_matches: true
  falsification_stated: true
  content_type: landscape
environments_tested:
  - tool: "OAuth RFC 8693 (IETF)"
    version: "RFC 8693 (Token Exchange, Feb 2020)"
    evidence_type: docs-reviewed
    result: "Section 4.4.2 marks 'act' claim as informational-only; 'MUST NOT be used to make authorization decisions' — delegation chain is unaudited by design"
  - tool: "LangGraph (LangChain AI)"
    version: "reviewed 2026-05-15"
    evidence_type: source-reviewed
    result: "Three-level authorization (global, resource, action) — no per-tool authorization within a single agent; per-agent granularity is the floor"
  - tool: "CrewAI"
    version: "reviewed 2026-05-15"
    evidence_type: source-reviewed
    result: "No native authorization — relies on Python process permissions; all external tooling required for per-agent access control"
  - tool: "A2A Protocol (Google)"
    version: "spec published 2026"
    evidence_type: source-reviewed
    result: "Equal-or-lesser permissions per hop enforced via new restricted token; no major framework (LangGraph, CrewAI, LlamaIndex) ships A2A natively"
  - tool: "MCP OAuth 2.1 (Anthropic / IETF draft)"
    version: "draft reviewed 2026-05-15"
    evidence_type: source-reviewed
    result: "OAuth scopes bind to MCP server, not to individual tools — no standard mechanism for granting read_file without also granting execute_code on the same server"
  - tool: "Multi-agent authorization failure modes (arXiv 2605.05440)"
    version: "May 2026"
    evidence_type: independently-confirmed
    result: "Three structural failure modes confirmed with production case evidence: transitive delegation, aggregation inference (71% success rate), temporal validity decay"
# theory_delta renders as a visible \"The delta\" TL;DR block on the finding page.
# Voice matches docs-reviewed (RFC 8693 spec text is primary evidence): \"The spec is explicit\"
theory_delta: "The spec is explicit: RFC 8693 'act' claims are informational-only and cannot be used for access control, meaning every multi-agent delegation chain is effectively unaudited — no production framework enforces permission attenuation across hops."
a2a_card:
  type: finding
  topic: multi-agent authorization and delegation
  claim: OAuth RFC 8693 'act' claims are informational-only by spec and cannot enforce permission attenuation across agent delegation hops — no production multi-agent framework closes this gap
  confidence: medium
  action: avoid
  contribute: /api/signals
---

# Multi-Agent OAuth Delegation Has No Enforcement Layer — RFC 8693 'act' Claims Are Advisory Only

## What you expect

OAuth handles authorization in modern distributed systems. When building multi-agent architectures — Agent A spawns Agent B which calls a downstream service — the standard expectation is that OAuth's token exchange mechanism (RFC 8693) provides an auditable delegation chain. You can see who delegated what to whom and verify that each hop operated within its authorized scope.

RFC 8693 includes explicit "act" claims that identify the actor chain (the entities that acted on behalf of the subject). The reasonable inference: these claims are the mechanism for multi-hop access control.

## What actually happens

RFC 8693 Section 4.4.2 [states this directly](https://www.rfc-editor.org/rfc/rfc8693#section-4.4.2): the "act" claim is "informational only and MUST NOT be used to make authorization decisions." The spec's authors knew multi-hop delegation was being deployed but explicitly declined to make these claims enforceable.

The consequence: every multi-agent system that passes bearer tokens between agent hops is operating without an audit trail for whether delegated permissions stayed within the original scope. An agent can spawn a more powerful subagent, grant it capabilities it does not possess, or silently acquire permissions via result aggregation — and OAuth will not catch any of it.

Three structural failure modes are confirmed in production multi-agent systems ([arXiv 2605.05440](https://arxiv.org/html/2605.05440), May 2026):

### Failure Mode 1: Transitive Delegation (Undetected Privilege Escalation)

When Agent A → Agent B → Agent C → Service D, each token handoff is invisible to OAuth's audit log. Three categories of production failure confirmed from ordinary operation (not attacks):

- **Silent scope widening**: session binding failure causes a delegated token to inherit broader permissions than intended
- **Incomplete delegation reported as successful**: an agent acting on behalf of another reports success while failing to carry the correct authorization context
- **Infrastructure attestation chain breakage**: integrity of the delegation path breaks at an infrastructure hop, but the request succeeds with degraded authorization context

Standard access logs capture token exchanges, not whether delegated permissions stayed within original scope across hops.

### Failure Mode 2: Aggregation Inference (71% Success Rate)

Individual data accesses are independently authorized, but synthesis of results can expose information no single access would reveal. The Semantic Intent Fragmentation attack decomposes a sensitive request into individually benign subtasks, each independently authorized, then synthesizes the results. [Formal research](https://arxiv.org/html/2605.05440) confirms a **71% success rate** against systems with per-request authorization.

No production framework models synthesis constraints as an authorization primitive. Authorization in current frameworks answers "can this agent access this resource?" — not "what does combining the outputs of these three authorized accesses reveal?"

### Failure Mode 3: Temporal Validity Decay

OAuth TTL is calibrated for human sessions (minutes to hours). Agent tool calls execute at sub-second rates across multi-hour workflows. Authorization state changes during execution — permissions are revoked, scopes narrowed — but the agent continues with a cached token that is technically valid but no longer reflects the intended policy.

[The same research](https://arxiv.org/html/2605.05440) demonstrates that execution-count TTL achieves **120× fewer unauthorized operations** than time-based TTL in equivalent multi-step workflows. This approach exists in published research but is standardized in no deployed protocol.

### Framework Authorization Gap

| Framework | Native Authorization | Per-Tool Scoping Within Agent | Gap |
|---|---|---|---|
| [LangGraph](https://langchain-ai.github.io/langgraph/concepts/auth/) | Yes — global, resource, action | No | Tool A can read but Tool B cannot write — this scoping does not exist |
| [CrewAI](https://docs.crewai.com/) | None | None | External tooling required for all per-agent access control |

No current framework supports per-tool authorization within a single agent. All frameworks stop at per-agent granularity. A builder who wants to restrict an agent's memory retrieval tool without restricting its code execution tool has no standard primitive for this scoping.

### MCP OAuth 2.1: Comprehensive Spec, Per-Tool Scoping Still a Builder Responsibility

The [MCP OAuth 2.1 draft spec](https://modelcontextprotocol.io/specification/draft/basic/authorization) requires mandatory PKCE, resource indicators ([RFC 8707](https://www.rfc-editor.org/rfc/rfc8707)), and step-up authorization. Its scope architecture binds OAuth tokens to the MCP server as a whole — not to individual tools within that server. An OAuth token granting access to an MCP server grants access to every tool it exposes.

Fine-grained tool-level authorization (grant `read_file` without granting `execute_code` on the same server) remains a builder responsibility requiring custom scope namespacing or a middleware validation layer.

### A2A Protocol: Spec Solves It, Framework Adoption Has Not Begun

The [Agent2Agent (A2A) protocol](https://google-a2a.github.io/A2A/) (Google, 2026) directly addresses the multi-hop enforcement gap. Its enforcement model: each delegation hop receives a new restricted token with audience restrictions and short expiration. Equal-or-lesser permissions per hop — no agent can delegate capabilities it does not possess.

Current status: specification published. No major framework — LangGraph, CrewAI, LlamaIndex — ships A2A natively. It is an integration target, not a drop-in solution. [Four active IETF draft proposals](https://workos.com/blog/oauth-multi-hop-delegation-ai-agents) (permission attenuation, cryptographic actor chains, cross-domain chaining, token binding) address multi-hop delegation from different angles — none are finalized or widely deployed as of May 2026.

## What this means for you

**If you are running multi-agent workflows in production:** every hop in your delegation chain that relies on OAuth bearer token passthrough is operating on the honor system. OAuth will not detect if a subagent acquired broader permissions than it was granted. Your access logs will show token exchanges, not whether the authorization model held.

**If you are using MCP servers:** OAuth scopes in your MCP config grant access to the entire server — not to individual tools. An OAuth token that authorizes an MCP server connection authorizes every tool that server exposes. Per-tool authorization requires a custom middleware layer.

**The aggregation inference attack (71% success rate)** is the most practically significant failure mode — it does not require compromising any individual authorized access. A correctly configured, fully-authorized multi-agent system can still leak unauthorized information by decomposing a single sensitive request into authorized subtasks and synthesizing the results.

**The adoption gap compounds the risk.** A [2026 survey](https://pointguardai.com/blog/top-10-predictions-for-ai-security-in-2026) found 88% of organizations confirmed or suspected AI agent security incidents in the past year, and only 21.9% treat agents as independent identity-bearing entities. The arithmetic: 66% of organizations with agents are operating them on shared credentials with no agent-specific identity governance.

## What to do

1. **Do not rely on OAuth 'act' claims for access control.** They are advisory only by spec. Any multi-hop access control mechanism that depends on RFC 8693 'act' claims cannot be enforced at the protocol layer.

2. **Adopt the A2A enforcement model at trust boundaries.** Issue a new restricted token at each delegation hop, with audience restrictions and short expiration. This is the A2A enforcement mechanism — implementable without a framework by issuing scoped tokens at each hop boundary, preventing scope widening even when the framework provides no enforcement.

3. **Add human approval gates at trust boundaries.** Until A2A adoption reaches production frameworks, the most reliable enforcement for sensitive delegation chains is a human approval checkpoint at each hop that crosses a trust boundary.

4. **Switch from time-based TTL to execution-count TTL.** For token expiration in multi-step agent workflows, calibrate token lifetime to execution steps, not wall-clock time. Token validity measured in "N tool calls" rather than "N minutes" catches mid-workflow authorization state changes before they compound.

5. **Model aggregation as a distinct authorization concern.** Per-request authorization is not sufficient. For workflows that aggregate results from multiple data sources, apply a synthesis policy layer — does combining these authorized outputs reveal information that none of them individually authorized? This constraint has no standard implementation today; it requires custom orchestration.

6. **Audit your agents' credential posture.** Non-human identity governance requires: one credential per agent instance (not per agent type), temporal scope in hours (not months), every issuance and revocation logged. The [NHI model](https://pointguardai.com/blog/top-10-predictions-for-ai-security-in-2026) treats agents as independent identity-bearing entities — 78% of organizations have not made this shift.

**Falsification criterion:** This finding would be disproved by a production multi-agent framework shipping a built-in enforcement layer that validates permission attenuation at each delegation hop — not just logging 'act' claims — combined with A2A or an equivalent protocol achieving broad adoption (LangGraph, CrewAI, LlamaIndex), together demonstrating that the structural gap documented here is closed in production deployments.

## Evidence

| Tool | Version | Evidence | Result |
|------|---------|----------|--------|
| [OAuth RFC 8693 (IETF)](https://www.rfc-editor.org/rfc/rfc8693) | RFC 8693, Feb 2020 | docs-reviewed | Section 4.4.2: 'act' claim "MUST NOT be used to make authorization decisions" — delegation chain audit is informational only by spec |
| [LangGraph](https://langchain-ai.github.io/langgraph/concepts/auth/) | reviewed 2026-05-15 | source-reviewed | Three-level auth (global, resource, action); per-tool scoping within a single agent does not exist in any current release |
| [CrewAI](https://docs.crewai.com/) | reviewed 2026-05-15 | source-reviewed | No native authorization; Python process permissions only; per-agent access control is entirely external |
| [A2A Protocol (Google)](https://google-a2a.github.io/A2A/) | spec published 2026 | source-reviewed | Enforcement model: new restricted token per hop, equal-or-lesser permissions enforced; no major framework ships A2A natively |
| [MCP OAuth 2.1 draft](https://modelcontextprotocol.io/specification/draft/basic/authorization) | draft reviewed 2026-05-15 | source-reviewed | OAuth scopes bind to MCP server (not individual tools); per-tool authorization is a custom builder responsibility |
| [arXiv 2605.05440](https://arxiv.org/html/2605.05440) | May 2026 | independently-confirmed | Three structural failure modes with production case evidence; aggregation inference achieves 71% success rate; execution-count TTL achieves 120× improvement over time-based TTL |
| [PointGuard AI NHI survey](https://pointguardai.com/blog/top-10-predictions-for-ai-security-in-2026) | 2026 | source-reviewed | 88% of organizations confirmed/suspected AI agent security incidents; only 21.9% treat agents as independent identity-bearing entities |
| [WorkOS OAuth Multi-Hop Analysis](https://workos.com/blog/oauth-multi-hop-delegation-ai-agents) | reviewed 2026-05-15 | source-reviewed | RFC 8693 limitation analysis; four IETF draft proposals for multi-hop delegation — none finalized or widely deployed as of May 2026 |

**Confidence:** medium — 6 source-reviewed entries, 1 independently-confirmed academic paper (arXiv 2605.05440), 1 survey. The RFC 8693 'act' claim being informational-only is directly confirmed from the spec text (Section 4.4.2). Framework gaps (LangGraph, CrewAI) are source-reviewed against current documentation. The 71% aggregation inference success rate comes from a formal research setting, not a production measurement.

**Strongest case against:** The three failure modes in arXiv 2605.05440 are formal analysis, not production telemetry — the 71% aggregation inference success rate is a research-setting result, not a measured attack rate on deployed systems. Most organizations building multi-agent systems are not yet at the scale where multi-hop delegation chains reach the complexity required for aggregation inference attacks to be viable. The A2A protocol (published 2026) may achieve framework adoption faster than expected; MCP's step-up authorization flow provides a partial mitigation for the scope widening failure mode by enabling agents to re-request narrower permissions at runtime.

**Open questions:** Has any major multi-agent framework shipped an A2A integration since the spec was published? What is the aggregation inference attack success rate in production deployments vs. the 71% research figure? Has the execution-count TTL approach been standardized in any IETF draft or deployed in any production gateway?

Seen different? [Contribute your evidence](https://theorydelta.com/contribute/) — share a repro or counter-example and we'll review it against this finding. Reader evidence is what keeps these findings accurate.