Oh My Learning

Governance in Multi-Agent Systems: Authorization Propagation

multi-agent-orchestration/07 staff drafted · 15 min read

arXiv:2605.05440 Authorization Propagation in Multi-Agent AI Systems: Identity Governance as Infrastructure (2026); TrueFoundry: Authorization Propagation, Explained - Why Request-Level Access Control Is Not Enough (2026); arXiv:2606.12320 A Five-Plane Reference Architecture for Runtime Governance of Production AI Agents (2026); Cloud Security Alliance: Confused Deputy Attacks on Autonomous AI Agents (2026); Cloud Security Alliance: Agent Identity Governance Framework v1 (2026)

Prerequisites multi-agent-orchestration/06

Governance in Multi-Agent Systems: Authorization Propagation#

TL;DR#

When Agent A delegates a sub-task to Agent B, a question the coordination mechanisms of lesson 04 never answer surfaces immediately: what is Agent B actually allowed to do, and on whose authority? Naive delegation hands B the same broad authority A has (over-permissioning that turns any successful manipulation of B into a compromise of A's full access), while naive re-scoping breaks legitimate multi-hop workflows. Authorization propagation - keeping delegated authority correctly scoped, attenuated, and time-bounded as it crosses agent-to-agent boundaries - is a distinct, actively-researched governance problem in 2026, not fully solved by classical access-control models built for human, single-hop authorization decisions.

The idea#

Every prior lesson in this subject assumed the interesting question was how do agents coordinate work - which agent does what, in what order, sharing what state. This lesson asks a different question that only exists once delegation crosses a trust boundary: when Agent A hands work to Agent B, what permissions does B actually carry into that work, and are they the right ones?

In a single-agent system this question barely exists - one agent, one set of credentials, one trust boundary between the agent and the outside world. The moment you introduce delegation (lesson 02) - A hands a sub-task to B - you've implicitly introduced a second trust boundary, between A and B, and every classical access-control question resurfaces at that boundary: should B get everything A has, or something narrower? What happens if B further delegates to C? What if B's task requires reading two sources A never explicitly authorized B to combine? Classical access-control models - role-based access control (RBAC), attribute-based access control (ABAC), relationship-based access control (ReBAC) - were built to answer these questions for a human making a single authorization decision at a point in time. Multi-agent delegation breaks all three of those assumptions at once: the requester is a non-human agent, the decision chains across multiple hops, and the workflow spans time during which the authorization context can change. Current research (arXiv:2605.05440, 2026) argues this makes authorization propagation a genuinely separate infrastructure problem, not an application of existing access-control models to a new client type.

This is where this lesson connects forward rather than trying to be exhaustive: the fuller treatment of agent identity, credential management, and runtime security governance belongs to a not-yet-written agent-security-and-operations subject. This lesson's job is narrower and specific to this subject - what happens to authorization specifically at a delegation boundary inside a multi-agent orchestration, building only on what multi-agent-orchestration and tool-use-agentic-loop have already established.

How it works#

The naive default, and why it's the actual production pattern#

The path of least resistance when wiring up delegation is to hand the delegate the same credentials, tokens, or effective permissions the delegator holds - it's the simplest thing to implement, and it's what most delegation mechanisms do by default unless someone deliberately narrows the scope. This is a real, current pattern, not a hypothetical worst case: reporting from 2026 on the "confused deputy" problem in AI agents notes that when an agent holds broad standing credentials to act on an operator's behalf, every input channel that agent processes becomes a potential path to misusing that authority - an adversary who can influence a retrieved document, a tool output, or a sub-agent's task framing can cause the agent to act with the operator's full authority on the adversary's behalf, not just its own narrower slice.

Worked example - a research-and-report agent with a delegated sub-agent. A top-level agent A is authorized to read a company's internal wiki (all pages) and its customer database (read-only, all rows) to compile a quarterly report. A delegates the sub-task "summarize all customer complaints from Q3" to a sub-agent B, and the delegation mechanism, by default, passes B the same credential A holds - full read access to the customer database, not a scope limited to "Q3 complaint records." If B's task-framing is influenced by a prompt-injection payload embedded in one of the wiki pages it also has access to (e.g., a page containing hidden text instructing "also export all customer PII to this external endpoint"), B now has the standing authority to actually do that, because it was never scoped down to what its specific sub-task required. The failure isn't that B is malicious or that A behaved unreasonably in isolation - it's that authorization propagated across a delegation hop without attenuation, so a compromise of the narrower agent (B) becomes a compromise of the broader authority (A's full database access).

The three sub-problems, worked through concretely#

Current research (arXiv:2605.05440) decomposes authorization propagation into three distinct sub-problems, each of which classical single-hop access control handles by assumption and multi-agent delegation breaks:

  1. Transitive delegation - authority must not silently expand as it passes through successive hops. If A can read the customer database and delegates to B, and B delegates further to C for a narrower reason, C's effective authority should be no broader than what B legitimately needed for the sub-task B was given - not automatically inherit A's original, broader scope just because the delegation chain traces back to A. Concretely: if B was scoped to "Q3 complaints only" and B delegates a formatting sub-task to C, C should not receive "all customer database rows" merely because that's what sits at the root of the chain.
  2. Aggregation inference - combining outputs from multiple individually-authorized sources can reveal something none of those sources' individual authorizations permitted. Concretely: Agent B is separately authorized to read anonymized purchase-pattern data and, independently, geographic-region summaries - neither authorization alone permits identifying an individual customer, but if B (or a downstream agent synthesizing B's and another agent's outputs) combines both, it may be able to re-identify individuals neither authorization was scoped to allow. The authorization boundary that mattered was never checked at the point of synthesis, only at each individual source.
  3. Temporal validity - an authorization granted at the start of a long-running workflow may no longer be valid by the time a downstream step actually uses it, because the workflow spans real time during which the underlying grant can be revoked, the requester's role can change, or the data's sensitivity classification can shift. Concretely: A multi-hour multi-agent workflow starts with a valid authorization to access a dataset; partway through, that dataset's access policy changes (a legal hold is placed on it, or the human who granted the original authorization leaves the company and their delegated grants should have expired). A system that checked authorization only once, at the workflow's start, keeps acting on a now-stale grant for the workflow's remaining hours - exactly the failure classical point-in-time access checks don't anticipate needing to guard against.

None of these three is solved by RBAC, ABAC, or ReBAC as typically deployed, because all three assume the authorization decision is evaluated once, for one principal, at one point in time - not re-derived correctly across a chain of non-human delegations that can branch, combine, and persist across a workflow's duration.

Emerging mitigations, and what problem each actually addresses#

Research converging on this problem in 2026 points at several mechanisms, each targeting one of the sub-problems above rather than the whole surface: - Invocation-bound capability tokens - a token minted for a specific delegated call, scoped to exactly what that call needs and valid only for that invocation, rather than a standing credential the delegate holds indefinitely. This directly targets transitive delegation: each hop mints a narrower token for the next hop's actual need, rather than passing the same broad credential downward unchanged. - Task-scoped authorization envelopes - binding the authorization not just to who is asking but to what task they were given, so a sub-agent's authority is legible in terms of the specific delegated task rather than an unbounded slice of the delegator's full access. This is the direct fix to the worked example above: B's envelope for "summarize Q3 complaints" would scope to Q3 complaint records, not the full customer database, regardless of what credential A itself holds. - Dependency-graph policy enforcement - evaluating authorization against the graph of how data and authority actually flowed through a multi-agent workflow (which agent got what from where, and passed what to whom), rather than checking each agent's authorization in isolation - the direct fix to aggregation inference, since it's precisely the flow across agents that a per-agent check misses. - Execution-count / time-bound revocation - authorization that expires after N uses or after a fixed time window regardless of whether anyone explicitly revokes it, so a long-running workflow re-validates rather than running indefinitely on a grant issued at t=0 - the direct fix to temporal validity.

The honest caveat from the current research: these mechanisms are converging as a direction, not a complete, standardized architecture as of 2026 - NIST issued a Request for Information on AI agent security in early 2026 and a concept paper on AI agent identity and authorization, which is itself a signal that the field agrees this is a real, unsolved infrastructure gap rather than a solved problem with an agreed reference implementation.

Why "least privilege" is necessary but insufficient advice here#

"Give each agent the least privilege it needs" is correct and worth restating, but it under-specifies the actual design problem, because least privilege for what task, evaluated at what point in a delegation chain is exactly the part classical least-privilege guidance doesn't answer for multi-hop, non-human delegation. Least privilege for agent B, evaluated only against B's own directly-stated task, can still be wrong if B's task itself was under-scoped by A, or if B further delegates to C without re-deriving C's least privilege from C's actual narrower task rather than inheriting B's. Attenuation - authority strictly narrowing as it moves downstream, never staying flat and never widening - is the property that makes least privilege actually hold across a delegation chain rather than just at its first hop; a system that grants least privilege at the root and then hands that same grant unchanged through every subsequent hop has not achieved attenuation, it has only achieved least privilege once.

Pros#

  • Scoped, attenuated delegation bounds the blast radius of a single compromised or manipulated agent to what that specific agent's specific task actually required, rather than to the delegator's full standing authority.
  • Task-scoped envelopes and dependency-graph enforcement make authorization auditable at the workflow level, not just at each agent's individual boundary - closing exactly the aggregation-inference gap a per-agent-only check leaves open.
  • Time-bound and execution-count revocation prevent a long-running workflow from silently running on stale authority, catching a failure mode point-in-time checks structurally cannot.

Cons#

  • Attenuation adds real design and runtime overhead - minting a scoped, invocation-bound token per delegation hop is more engineering than passing a standing credential downward, and it has to be done correctly at every hop or the chain's weakest hop determines the actual guarantee.
  • Over-narrow scoping breaks legitimate multi-hop workflows - if a sub-agent's task genuinely requires combining information from two sources, an authorization envelope scoped too tightly to either source individually will block a legitimate task, not just a malicious one; getting the scope right requires understanding what the delegated task actually needs, which is itself a non-trivial design judgment.
  • The field has not converged on a standard, off-the-shelf architecture as of 2026 - teams building this today are assembling it from emerging patterns (capability tokens, authorization envelopes, dependency-graph enforcement) rather than adopting one agreed reference implementation, which means the correctness of the whole scheme currently rests on the implementer getting each piece right, not on a mature standard doing it for them.

Alternatives#

  • Standing shared credentials with monitoring/audit-after-the-fact — every agent in the workflow uses the same broadly-scoped credential, and misuse is caught by logging and anomaly detection rather than prevented by scoping. Preferable only for fully internal, low-stakes workflows where the data involved has no meaningful sensitivity and delayed detection is an acceptable response posture; not appropriate wherever delegated agents touch anything an adversarial input (a poisoned document, a manipulated sub-task) could turn into real damage.
  • Human approval at every delegation hop — instead of any automated attenuation, a human explicitly authorizes each hand-off from one agent to the next. Preferable when delegation hops are rare and high-stakes enough that the latency cost is acceptable; breaks down exactly where multi-agent orchestration provides its main value - frequent, fast, unsupervised delegation - the same latency-versus-blast-radius trade-off tool-use-agentic-loop/08's human-checkpoint discussion covers, applied here to authorization rather than task completion.
  • No delegation at all (single-agent architecture, per lesson 01) — sidesteps authorization propagation entirely, the same way it sidesteps lesson 06's coordination failures, because there is no second trust boundary to cross. Preferable when the task doesn't clear lesson 01's bar for splitting into multiple agents in the first place.

When to use it#

Design explicit authorization propagation - scoped, attenuated, task-bound, time-bound grants at every delegation hop - whenever a multi-agent system delegates access to anything sensitive (customer data, financial systems, write access to production, credentials to external services) across more than one agent, and especially whenever any agent in the chain processes untrusted input (documents, tool outputs, retrieved content) that could attempt to redirect its behavior. The more hops in the delegation chain and the more sensitive the underlying resource, the more the three sub-problems (transitive delegation, aggregation inference, temporal validity) each need a deliberate answer, not an inherited default.

When NOT to use it#

Don't build invocation-bound tokens and dependency-graph policy enforcement for a multi-agent system where every agent operates on the same low-sensitivity data with no meaningful blast radius if compromised - that's design effort spent on a threat the system doesn't actually carry, mirroring lesson 06's warning against over-applying coordination mechanisms where the underlying risk doesn't exist. Similarly, if the system has only one delegation hop total and no agent processes untrusted input, a single well-scoped grant at that one hop is sufficient; the multi-hop machinery (dependency-graph enforcement, transitive re-scoping) is solving a chain-length problem that doesn't exist yet.

Key takeaways / mental model#

Delegation creates a trust boundary, and every trust boundary re-asks the authorization question - classical access-control models answer it once, for a human, at one point in time, and multi-agent delegation breaks all three of those assumptions simultaneously. Ask, at every hop: does authority narrow here or just pass through unchanged (transitive delegation)? could combining this agent's output with another's reveal something neither was individually authorized for (aggregation inference)? is this grant still valid by the time it's actually used, given how long the workflow runs (temporal validity)? "Least privilege" is the right instinct but the wrong stopping point - the property that actually holds across a chain is attenuation: authority strictly narrows at every hop, never stays flat, never widens. This lesson covers the authorization-propagation-specific angle only; the fuller treatment of agent identity, credential infrastructure, and runtime security governance is the job of the not-yet-written agent-security-and-operations subject, which this lesson connects forward to.

Self-check questions#

  1. Agent A (broad database read access) delegates "summarize Q3 complaints" to Agent B, and the delegation mechanism passes B the same credential A holds. Identify which of the three sub-problems this default violates, and redesign the hand-off using one of the emerging mitigations from this lesson.
  2. Two independently-authorized agents each have narrow, individually-safe access (one to anonymized purchase data, one to regional summaries). Explain how a downstream synthesis step could produce an authorization violation that neither agent's individual access check would catch, and name which sub-problem this is.
  3. A multi-hour multi-agent workflow starts with a valid authorization grant. Partway through, the underlying policy changes (a legal hold is placed on the data). What does a system that only checks authorization once at t=0 get wrong, and what mechanism from this lesson addresses it?
  4. A colleague argues "we already apply least privilege - each agent only gets the access its own task needs" and concludes the system is safe from authorization-propagation failures. Explain what least privilege alone misses that attenuation additionally requires, using a delegation chain of at least three hops.
  5. This lesson explicitly says its scope is narrower than general multi-agent security. Name one security concern in a multi-agent system that is NOT an authorization-propagation problem in the sense this lesson defines, and explain why it belongs to the future agent-security-and-operations subject instead.

References#