Authorization propagation: the agent security gap prompt-injection fixes won't close

What is this?

On May 6, 2026, Krti Tallam published Authorization Propagation in Multi-Agent AI Systems: Identity Governance as Infrastructure (arXiv:2605.05440, cs.AI). Its argument is a useful corrective to a field that has spent two years treating agent security as almost synonymous with prompt injection.

The paper names a separate failure mode: authorization propagation — the problem of maintaining authorization invariants as non-human principals retrieve data, delegate sub-tasks, and synthesize results across changing trust boundaries. The headline claim is that this problem “is not reducible to prompt injection and is not fully addressed by classical access-control models such as RBAC, ABAC, or ReBAC.” In other words: you could solve prompt injection completely tomorrow and still have this bug.

What makes the framing land is the empirical aside. The paper reports preliminary evidence from a production enterprise AI platform showing that ordinary system behavior — not only adversarial action — already produces the failures the model predicts. This is a design defect, not just an attack surface.

How it works

The mechanics are about identity, not payloads, so there is no exploit to redact here. A multi-agent workflow looks like this: a user asks a planner agent for something, the planner spins up sub-agents, each sub-agent calls tools or retrieves documents, and the results flow back up and get merged. The question the paper forces is simple — whose authority is each of those actions running under, and is it still valid by the time the action fires?

Tallam decomposes authorization propagation into three sub-problems:

Sub-problem            What breaks
---------------------  --------------------------------------------------------
Transitive delegation  Agent A is allowed to act for the user. A delegates to B.
                       Does B inherit A's scope, the user's scope, or something
                       narrower? Naive systems pass the full token downward, so
                       a tightly-scoped request fans out into broad access.
Aggregation inference  Each retrieval is individually authorized, but combining
                       the results discloses something no single source was
                       cleared to reveal. Per-call checks pass; the synthesis
                       leaks.
Temporal validity      Authorization is checked at planning time, but the action
                       executes later — after a role change, a revoked grant, or
                       an expired session. The check was true once; it isn't now.

None of these is a prompt being injected. They are properties of how authority moves through a workflow. Classical access control assumes a relatively stable principal making a bounded request; an agent graph violates both assumptions, delegating dynamically and acting asynchronously.

The paper then derives seven structural requirements for authorization architectures in this setting and surveys the building blocks the field is converging on — invocation-bound capability tokens (authority tied to a specific call rather than a long-lived bearer secret), task-scoped authorization envelopes (a request carries the narrowest scope that satisfies it), dependency-graph policy enforcement (decisions evaluated against the actual data-flow graph), and execution-count revocation (authority that expires after N uses rather than on a wall-clock timer). The honest conclusion is that these are converging signals, “but not yet on a complete architecture.”

Why it matters

The agent-security discourse has a blind spot shaped exactly like this. Most of the 2025–2026 literature — and most of June 2026’s disclosure wave — is about stopping hostile input from reaching a tool. Authorization propagation is orthogonal: it is about whether a legitimate, uninjected instruction is allowed to do what it ends up doing once it has passed through three layers of delegation.

That orthogonality is the operational point. Teams that have invested heavily in input filtering, guard models, and output scanning can still ship a system where a low-privilege user’s question, routed through a planner with broad service credentials, returns data they were never cleared to see — with every individual access logged as authorized. The companion literature on agent identity (Identity Management for Agentic AI, arXiv:2510.25819) reaches the same place from the standards side: non-human principals are multiplying faster than the authorization plumbing built to govern them.

The dates matter for framing. This is a position-and-architecture paper from early May 2026, not a vulnerability disclosure. There is no CVE, no affected vendor, no patch. The takeaway is that the next class of agent incidents may not look like an attack at all — they will look like the system doing exactly what it was wired to do, against the wrong authority.

Defenses

The paper is itself a defensive contribution; the practical translation for teams building multi-agent systems:

1. Make authority explicit at every hop. Treat each delegation as a fresh authorization decision, not an inherited one. A sub-agent should receive the narrowest scope that satisfies its task, derived from the originating user’s authority — never a copy of the planner’s service credentials.

2. Bind authority to the invocation, not the session. Prefer invocation-bound capability tokens and task-scoped envelopes over long-lived bearer tokens that a downstream agent can replay. Authority that names the specific call it permits cannot fan out.

3. Re-check at execution time. Authorization validated at planning time is stale by the time an async action fires. Evaluate temporal validity at the moment of execution so role changes, revocations, and expirations actually take effect.

4. Govern aggregation, not just retrieval. Per-source access checks miss the inference that emerges from combining results. Apply policy to the synthesis step and the data-flow graph, not only to individual tool calls.

5. Use execution-count and graph-aware revocation. Authority that expires after a bounded number of uses, and policy evaluated against the actual dependency graph, contains the blast radius when a single grant is over-broad.

6. Audit for non-adversarial failures. The paper’s most actionable finding is that ordinary behavior already triggers these failures. Red-team your agent graph for over-broad delegation and aggregation leaks without assuming an attacker — replay normal workflows and check whether the effective authority at each leaf matches the user’s actual entitlements.

7. Treat identity governance as infrastructure. Evaluate it continuously and enforce it at every interaction boundary, before orchestration logic scales. Bolting access control on after the agent graph works is how the failures the paper predicts ship to production.

Status

Item	Reference	Date	Notes
Authorization Propagation paper	arXiv:2605.05440	2026-05-06	Position + architecture, 20 pages, cs.AI
Three sub-problems	Paper §formalization	2026-05-06	Transitive delegation, aggregation inference, temporal validity
Convergent mechanisms	Paper survey	2026-05-06	Invocation-bound tokens, task-scoped envelopes, dependency-graph policy, execution-count revocation
Identity Management for Agentic AI	arXiv:2510.25819	2025-10	Standards-side view of the same gap
June 2026 agent-security roundup	Adversa AI	2026-06-01	Flags authorization propagation as a distinct research thread

The right way to read this: prompt injection is the threat everyone is funding a defense for, and authorization propagation is the one that will still be standing once that defense works. If your multi-agent system has a strong input filter and no answer to “whose authority is this leaf action running under, and is it still valid?”, you have built half a security model.