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.

‍