Delegation Without Trust: An Empirical Gap Analysis of Identity, Authorization, and Runtime Governance in Multi-Agent LLM Systems

What it is

An arXiv paper (2609.00267, Dantuluri & Sundi, VotalAI, Aug 2026) that treats the LLM in an agent as an untrusted component and asks whether a fully prompt-injected agent can still be confined to its delegated authority. The summary gives the headline numbers; what it omits is the eight-requirement checklist, the tested framework versions, and the broker's actual construction — the parts an engineer needs to judge applicability.

The eight requirements (R1–R8)

The paper's reusable contribution is a requirement set to grade any agent authz design against:

• R1 delegation-chain provenance (on-behalf-of, traceable to a human grant)
• R2 least-privilege attenuation (each hop can only narrow)
• R3 sender-constrained credentials (token bound to workload identity)
• R4 short-lived issuance
• R5 key/secret rotation
• R6 revocation propagation to PEPs
• R7 tamper-evident audit
• R8 model-independent enforcement — decisions made by infrastructure PEPs, never the model

R8 is called out as load-bearing: if the model gates access, a hijacked model grants access. This is the concrete lens to apply to your own stack.

Framework findings (versions matter)

Tested defaults, per the paper's tables:

• LangGraph 1.2.10, CrewAI 1.15.13, AutoGen 0.7.5 — vulnerable to all four threats, provide none of R1–R8. Confinement is left entirely to the developer.
• MCP authorization (rev. 2026-07-28) — the only partial one. Its OAuth 2.1 resource-server model validates tokens outside the model (R8), Resource Indicators (RFC 8707) audience-restrict tokens to a server (partial R3/T2), plus short-lived tokens (R4) and revocation (R6). But no per-hop attenuation (R2) and no cross-agent delegation provenance (R1) for agent-to-agent chains.

Methodology differs by row and is stated: LangGraph was executed via a compiled StateGraph with a scripted node; CrewAI/AutoGen were code-inspected; MCP was spec-analyzed. Treat the non-executed rows accordingly.

The systematization table adds that no single existing standard covers the set: provenance/attenuation live in Token Exchange (RFC 8693) and capability tokens (Macaroons, Biscuit); sender-constraining/rotation in SPIFFE/mTLS/DPoP; R8 is a deployment property none mandates.

The broker

~160 lines of Python, standard library only. Composition: SPIFFE-style SVID per agent (R3/R5); OIDC-rooted capability token (R1); at each hop an issuer-mediated token exchange mints an attenuated, SVID-bound, short-lived token (R2/R3/R4), and only the workload a token is bound to may delegate it onward; every tool call routed through the broker for signature + revocation + sender-constraint + caveat checks with no model call (R8/R7). Tokens are HMAC-signed macaroon-style, so forgery, caveat-stripping, and subject re-binding all fail verification; caveats are append-only.

Caveats

• The paper is explicit that one boundary attack succeeds by design: if an attacker can present the victim's SVID, a stolen token works. Sender-constraining reduces to the strength of workload-identity attestation (mTLS/SPIFFE) — that assumption is load-bearing, not a solved problem.
• All broker numbers (0/200,000 forged, 1.5 vs 8,100 reach over 2,000 scenarios, ~2.6µs) are from the authors' own reference implementation against a synthetic 8,100-action environment. The 8,100→1.5 reduction is framed less as a metric than as an invariant: defended reach is bounded by the task and independent of environment size.
• Authors are VotalAI; the design is stated to be productized in their LLM Shield — vendor interest is disclosed.