Authorization Propagation, Explained: Why Request-Level Access Control Is Not Enough

The security conversation around AI agents has been dominated by one attack — prompt injection — long enough that a quieter, structural problem went unnamed. It now has a name: authorization propagation, proposed in a May 2026 single-author arXiv preprint from Kamiwaza (reporting preliminary implementation evidence), "Authorization Propagation in Multi-Agent AI Systems: Identity Governance as Infrastructure" (Tallam, arXiv:2605.05440), whose thesis we can state in its own six quoted words — "We call this problem authorization propagation" — and paraphrase in one sentence: as non-human principals retrieve data, delegate tasks, and synthesize results across changing boundaries, the hard problem is maintaining authorization invariants through the chain, and it is neither reducible to prompt injection nor fully addressed by the classical access-control models — RBAC, ABAC, ReBAC — that enterprises already run. The paper decomposes the problem into three named sub-problems that every multi-agent operator will recognize the moment they are stated. Transitive delegation: agent A, authorized for a task, delegates a subtask to agent B — what may B do, on whose authority, and what stops the chain from widening at each hop? Aggregation inference: each retrieval in a workflow is individually permitted, but the synthesis assembles something no single principal was cleared to see. Temporal validity: the authorization was valid when the workflow started — is it still valid at step forty, an hour later, after the grant was revoked? These are workflow-level properties, not request-level ones, which is exactly why the request-level machinery of the last two decades doesn't close them. This guide is the enterprise reference for the term: what authorization propagation is, where it came from, how it differs from the problems it gets filed under — and the infrastructure that can support selected invariants for participating operations — while aggregation inference remains, per the paper itself, an open problem no complete current architecture solves — per the paper's own subtitle: identity governance as infrastructure. As with all our young-term references, we will keep this page updated as the research and vocabulary evolve.

What Is Authorization Propagation? A Definition

Authorization propagation is the problem of preserving authorization invariants — the assurances about who may access what, established at a workflow's start — as that workflow's work is carried out by multiple non-human principals that retrieve data, delegate tasks to one another, and synthesize results across system boundaries. The definitional move that makes the term useful is the shift in unit of analysis: classical access control evaluates a request (this principal, this resource, this moment) and is largely solved at that granularity; authorization propagation evaluates a workflow — the chain of requests, delegations, and combinations — and asks whether the authority present at the start is faithfully maintained through every hop and into the final output. The three sub-problems name the ways it fails. Transitive delegation: when agent A delegates to B and B to C, each hop is an opportunity for authority to widen — B running with A's credentials plus its own, C accumulating both — until an action deep in the chain executes with an effective permission set no human ever granted; the classical "confused deputy" is this problem's one-hop ancestor, now compounding at chain length. Aggregation inference: a research agent's five retrievals are each individually authorized, but the synthesis — salary bands joined to org charts joined to performance notes — constitutes disclosure at a sensitivity level none of the individual grants implied; request-level checks pass five times while the workflow-level invariant fails once, invisibly. Temporal validity: agent workflows run long — hours, days, standing — while grants are revoked, roles change, and tokens expire; an authorization checked only at step one is a snapshot presented as a guarantee. A disambiguation for adjacent searches: this is not authentication (proving who a principal is — the prerequisite, covered across the MCP-auth literature), not prompt injection (a manipulation attack; this problem needs no attacker), and not authorization in general — it is specifically the propagation of authorization through multi-principal, multi-step, boundary-crossing work.

A Brief History: From Confused Deputies to Non-Human Principals

The problem's ancestry is older than the term by decades, which is part of why the naming matters. The confused deputy — a privileged program tricked into misusing its authority on a caller's behalf — was described in 1988 and shaped capability-based security thinking for a generation; OAuth's delegation flows, SAML assertions, and the impersonation-versus-delegation debates of the SOA era were all partial answers for a world where the principals were applications and the chains were short. The 2010s added scale but not shape: microservices made service-to-service identity a discipline (mTLS, SPIFFE, workload identity), and the IAM industry began speaking of non-human identities outnumbering human ones. What changed in 2024–2026 is that the non-human principals became autonomous and compositional: agents that decide at runtime which tools to call, spawn sub-agents with subsets (or accidental supersets) of their authority, and synthesize across everything they touched — chains that are long, dynamic, and unplanned, in exactly the ways the classical machinery assumed away. The discourse tracked the drift piecemeal — MCP authentication and authorization guides, zero-trust-for-agents frameworks, the identity-first security wave, our own agent identity census — until May 2026, when the Kamiwaza paper drew the box around the whole thing: named the problem, separated it from injection, formalized the three sub-problems, and derived seven structural requirements for architectures that maintain the invariants. Our standing framing applies: the naming trails the practice — every enterprise running multi-agent workflows has these three problems today, named or not — and the naming is when the procurement questions start being asked in the right unit of analysis, which is the workflow, not the request.

Authorization Propagation vs Prompt Injection, RBAC, and Authentication

Three contrasts locate the term, and each is a common filing error corrected. Versus prompt injection: injection is an attack — an adversary manipulating an agent into misusing authority it legitimately holds; propagation failures need no adversary — ordinary delegation, helpful synthesis, and long-running workflows produce them by default, which means an estate can be injection-hardened and still leak through its own permission plumbing. They intersect (an injected agent with a widened effective permission set is a worse incident), but solving one does not touch the other, and the paper's central complaint is that the security conversation's injection focus left the structural problem unnamed. Versus RBAC/ABAC/ReBAC: the classical models are request-time policy languages — powerful, necessary inputs that do not by themselves prove workflow-level invariants, because a role check cannot see that authority accumulated across hops, a per-resource rule cannot see what the synthesis assembled, and a policy evaluated at request time cannot see that the workflow it belongs to started under grants since revoked. The models are inputs to a solution, not the solution: the invariants live at a layer those models don't evaluate. Versus authentication: knowing who each principal is — the OAuth flows, the token exchange, the workload identity — is the prerequisite this problem builds on; propagation is what must hold after everyone is correctly identified, which is why "we have SSO for our agents" answers a different question than the one this term asks. The one-line summary of all three contrasts: the industry has spent two years securing the request and the prompt; authorization propagation is the security of the chain.

Authorization Propagation in the Enterprise: Identity Governance as Infrastructure

Here is where TrueFoundry enters, and the paper's subtitle has already made the argument's shape: the invariants cannot be maintained by asking every agent team to implement them — they must be properties of the layer every agent call already crosses. Walk the three sub-problems against documented mechanism. Transitive delegation is governed where the delegation happens: agent tool reach flows through the MCP Gateway, where per-user delegation means a downstream call carries the originating principal's authority into each system — the CRM sees the user's permissions, not the agent's ambient ones — and task-based scoping means what a spawned agent receives is a narrowed lease derived from its parent's, never an accumulated superset; the invariant "authority may narrow, never widen" becomes a structural property of how credentials are issued rather than a convention teams remember, the discipline our TBAC analysis and OAuth-at-the-MCP-layer work develop in depth. Temporal validity becomes the token's property instead of the workflow's promise: short-lived, auto-refreshed, centrally revocable credentials mean a grant revoked at step twelve fails the tool call at step thirteen — the check re-runs at every hop because every hop crosses the plane, which is the single place "still valid now" can be answered continuously for a workflow that outlives its starting conditions. Aggregation inference is the candid hard case — no gateway computes the sensitivity of a synthesis in general — and the infrastructure contribution is to make it governable: chain-level request traces record mediated retrievals and calls with their resolved identities — evidence for audit review of participating operations, not an automatic authorization verdict on what the workflow assembled; guardrails on tool outputs and model responses enforce the expressible boundaries (PII classes, restricted sources crossing into unrestricted outputs); and the multi-agent coordination layer our A2A governance work covers keeps the inter-agent hops on the same audited plane as the tool hops, so the chain has no dark segments. The paper asks for architectures with structural requirements; the plane is where those requirements stop being per-team engineering and start being configuration.

Enterprise Authorization-Propagation Checklist

Six questions for any multi-agent estate: Does every agent-to-tool and agent-to-agent hop cross a governed layer, or are there direct integrations where the chain goes dark? Is delegation implemented as credential derivation — child scopes strictly within parent scopes — rather than credential sharing? Do downstream systems see the originating principal's authority (per-user delegation) rather than a service account's ambient one? Are credentials short-lived and centrally revocable, so temporal validity is re-established at every hop instead of assumed from step one? Can an auditor reconstruct any workflow's full retrieval-and-synthesis footprint from traces? And is someone accountable for the aggregation question — reviewing what high-privilege workflows assemble, not just what they access? Six yeses is identity governance as infrastructure; the noes are where the chain's compliance is a coincidence.

The Future of Authorization Propagation: What We'll Be Watching

Predictions, lightly held. Expect the term to travel the research-to-practitioner path fast, because — like governance decay, its sibling coinage of the season — it names failures operators already have: the over-permissioned sub-agent found in an audit, the synthesis that made legal wince, the workflow that kept running on a revoked grant; vocabulary that explains existing incidents gets adopted in the postmortems. Expect the standards bodies to metabolize it: the MCP and A2A ecosystems are already converging on delegation semantics, and "how does your protocol maintain authorization invariants across hops" is the precise question the paper equips reviewers to ask — we would bet on propagation language appearing in agent-protocol security reviews within the year. Expect aggregation inference to be the stubborn frontier: delegation and temporal validity have clean structural answers; what-did-the-synthesis-reveal is a semantics problem that will pull data-classification, DLP, and output-guardrail vendors into the agent conversation, with chain-level traces as the substrate all of them will need. Expect the IAM industry's non-human-identity wave to collide productively with this framing — NHI governance gives the principals names; propagation is what the named principals must preserve — and expect procurement to compress all of it into one question that this page exists to help answer: not "do your agents have identities" but "do your chains keep their invariants." We will keep this guide updated as the research and vocabulary evolve; the durable claim is the reframing the paper earned: the last two years secured the request and the prompt — the next two are about securing the chain.

Authorization Propagation FAQ

What is authorization propagation in AI systems?

Authorization propagation is the problem of maintaining authorization invariants as multiple AI agents retrieve data, delegate tasks, and synthesize results across system boundaries — ensuring the authority a workflow started with is faithfully preserved through every hop. The term was proposed in a May 2026 single-author preprint (arXiv:2605.05440), which decomposes it into transitive delegation, aggregation inference, and temporal validity.

How is authorization propagation different from prompt injection?

Prompt injection is an attack in which an adversary manipulates an agent into misusing authority it legitimately holds. Authorization propagation failures need no attacker: ordinary delegation chains widen authority, individually-permitted retrievals synthesize into unpermitted disclosures, and long workflows outlive their grants. An injection-hardened estate can still leak through its own permission plumbing.

Why don't RBAC or ABAC solve authorization propagation?

Because they are request-time models: a role or attribute check evaluates one principal, one resource, one moment. The propagation failures are workflow-level — authority accumulating across hops, syntheses exceeding any single grant, validity expiring mid-chain — which request-level checks structurally cannot see. The classical models remain necessary inputs; the invariants must be enforced at the layer the whole chain crosses.

How do enterprises maintain authorization invariants across agent delegation chains?

By making the invariants properties of infrastructure: route every agent-to-tool and agent-to-agent hop through a governed gateway; implement delegation as scoped credential derivation (for registered agent-to-agent calls routed through the Agent Gateway, scoped token exchange can help preserve subject, actor, audience, and authorized scope — while Harness subagents currently share the root run's tools and sandbox rather than receiving independently narrowed permission envelopes); use configured per-user delegation where supported, so downstream systems can see the originating principal's authority; keep credentials short-lived and centrally revocable so temporal validity can re-establish at mediated hops, subject to token lifetime and downstream validation semantics; and record traces of mediated operations so a workflow's retrieval-and-synthesis footprint is reviewable for the participating plane.

References

• Anchor — Tallam, "Authorization Propagation in Multi-Agent AI Systems: Identity Governance as Infrastructure" (Kamiwaza AI, arXiv:2605.05440, May 2026: the coinage; the not-reducible-to-injection and beyond-RBAC/ABAC/ReBAC arguments; the three sub-problems; the seven structural requirements).
• TrueFoundry documentation — MCP Gateway (per-user delegation; official architecture diagram); MCP authentication & security; request traces and analytics (official image); guardrails.
• This blog — TBAC: task-based access control; OAuth and token management at the MCP layer; multi-agent A2A governance; the agent identity census; MCP gateway vs proxy vs router.

One direct quotation under fifteen words is used, from the cited paper, attributed inline; the paper's arguments, sub-problems, and requirements are otherwise paraphrased, and readers should consult the original for the formal treatment. The mapping from the paper's requirements to TrueFoundry mechanisms is our editorial framing; the paper's author and Kamiwaza AI neither mention nor endorse TrueFoundry. Product capabilities are paraphrased from public documentation current at the time of writing; the product images are TrueFoundry's own documentation assets, reproduced with attribution. This is a living reference and will be revised as the research and vocabulary evolve.

‍