Authorization Propagation: Why Multi-Agent AI Systems Break Access Control

An enterprise can authenticate every user, configure every permission correctly, and still leak data through an agent workflow. Here is why access control has become a property of the whole chain rather than a single check.

By Tahir Mahmood, Co-founder & CTO, OpenBox  ·  Last updated 1 October 2026

The authorization failure that needs no attacker

A multi-agent system can produce an unauthorized outcome while every user is authenticated, every permission is set correctly, and no prompt injection occurs. The failure comes from the shape of the workflow, not from an adversary.

Picture an orchestrating agent that receives a request, splits it into sub-tasks, and hands them to specialised agents. One agent reads Dataset X. Another reads Dataset Y. A third combines the two and returns an answer. Each access was permitted. The combined result may still expose something neither dataset would reveal on its own, and the person who asked may never learn which sources fed the reply.

This is authorization propagation: the problem of holding access-control invariants steady as non-human principals delegate tasks, retrieve data, and synthesise results across changing boundaries. The term comes from a May 2026 arXiv paper by Krti Tallam of Kamiwaza AI, "Authorization Propagation in Multi-Agent AI Systems: Identity Governance as Infrastructure" (arXiv:2605.05440). Its argument is specific: this is a distinct problem, it is not reducible to prompt injection, and classical access-control models do not fully solve it.

OpenBox, an AI agent governance platform, sits on exactly this seam. What follows separates what the paper establishes, what follows from it for enterprise architecture, and what stays an open research problem.

Attack vectors and architectural problems are not the same thing

The paper separates two categories that the security conversation often merges. Attack vectors are ways an adversary subverts an agent’s behaviour. Architectural problems arise from how a multi-agent system is built, with no adversary required.

Prompt injection is the attack vector everyone knows. An attacker hides instructions in content the agent reads, and the agent acts on them. Content injection, semantic manipulation, cognitive-state attacks, and tool-misuse induction share one shape: malicious content enters the agent’s processing path, so defending against them is a content-integrity problem.

Authorization propagation is different in kind. A misconfigured delegation chain, a stale relationship record, or a workspace-membership change that propagates too slowly can each expose data through normal operation. No attacker is involved.

The two problems are complementary, not nested, and the paper makes the point in both directions. Solve prompt injection perfectly, and the authorization questions still stand: which data may each agent reach, what authority passes from one agent to the next, and whether the requester may see a synthesis of several sources. Solve authorization propagation perfectly, and an adversary can still manipulate an agent through injected content. Treating one as a subset of the other yields systems that are sound against attacks but structurally leaky, or clean in structure but open to adversarial content.

What changes when agents delegate, retrieve, and synthesise

In a single-agent interaction, authorization is a boundary check on one request. In a multi-agent workflow, authority crosses several boundaries before a result comes back. The paper’s conceptual path runs from a human requester to an orchestrating agent, out to specialised agents, into data and tool access, through result synthesis, and back as a final response. Along that path a single agent may act as a principal, a delegate, a requester of another agent, a consumer of data, a producer of derived information, and a link in a longer authorization chain. The system has to keep the relationship between the original authority and every downstream action intact.

Two shortcuts fail here. Give every agent broad access, and least privilege collapses, so any misdirected hop can reach far more than its task needs. Let every agent act only under its own service identity, and the workflow may lack the authority to complete legitimate delegated work. Neither shortcut preserves the tie between who asked and what was done on their behalf.

The three ways authorization breaks in an agent workflow

The paper decomposes authorization propagation into three sub-problems: transitive delegation, aggregation inference, and temporal validity. Each can fail on its own, and none is fully closed by a single existing mechanism.

Transitive delegation

When a person starts a workflow that runs through several agents, the system must decide the effective authority at each hop. Two naive answers both fail. If every downstream agent inherits the initiator’s full authority, least privilege is violated and authority accumulates down the chain. If every agent runs only under its own service identity, the workflow may not have enough authority to finish.

A workable delegation model, the paper argues, needs bounded authority at each hop, explicit and auditable transfer, no privilege accumulation across the chain, revocation at any point, and a preserved link between the original requester and downstream actions. This is the classical confused-deputy problem in a new setting, where an agent is induced to use its authority for a principal that should not have it. The paper states plainly that no widely deployed system offers a complete solution for autonomous agent-to-agent delegation, though token-level mechanisms for bounded, attenuated delegation are emerging.

Aggregation inference

This is the sharpest of the three. Authorization can fail even when every individual retrieval is permitted. Access to Dataset X is authorized. Access to Dataset Y is authorized. The synthesis that combines them may still reveal something neither was cleared to expose.

The distinction that matters is between authorization to access data and authorization to derive or disclose information from combining it. The paper ties this to the established mosaic effect from statistical-database and classified-information security, then names what makes the agentic version harder: the synthesis function is a neural network whose behaviour is not formally specified, the accessed resources may not be known in advance because agents can discover them at run time, and the requester may not know which sources contributed to the answer.

The paper is careful about the limit. Aggregation inference is unsolved in the general case. What an architecture can do is make the contributing resources inspectable after the fact, set policy boundaries on which combinations are permitted, and track causal dependencies through the synthesis graph. It cannot determine every possible inference in advance.

Temporal validity

A workflow that starts at one moment may finish much later, and authorization state can change in between. A relationship can be revoked, a role can change, a resource can be reclassified, a workspace membership can change, or a session can lose its intended scope.

The paper sets out three timing models for when authorization is evaluated. Initiation-time checks once at the start and assumes validity throughout, which is simple but can permit access to data later restricted. Access-time checks at each retrieval, which holds up better when authorization changes during execution but can fail a workflow midway and force partial rollback. Completion-time checks before results are delivered, which blocks unauthorized delivery but can waste compute on work that cannot be disclosed. Each carries different consequences, so the choice is a policy decision, not something an implementation default should settle by accident. The paper argues that machine-speed execution makes initiation-time assumptions increasingly unsafe, because an autonomous agent can perform many operations inside a window a human-speed model would have treated as a single instant.

A worked example: the due-diligence workflow

A single request can raise a different authorization question at every stage, and the paper’s due-diligence scenario makes the abstraction concrete.

A human analyst asks an agent to summarise liabilities that could materially change a valuation. An orchestrator decomposes the request into financial retrieval, legal-annex retrieval, and review-committee memo retrieval. A retrieval agent can reach the deal room but not the restricted review-committee workspace that holds a contingent-liability memo. A synthesis agent then combines what was retrieved and returns a valuation-risk summary.

Each stage asks something different. The orchestrator may be allowed to delegate the legal-annex retrieval but not the restricted memo. The retrieval agent may read each visible corpus on its own yet still lack authority to build a cross-boundary synthesis context. The synthesis agent may combine both outputs only if the delegated scope is intact and no boundary was crossed under stale authority. And the analyst may be entitled to a partial result, but not to a summary presented as complete when a material source was excluded.

That last point is why authorization propagation is not reducible to per-request authentication. The object that has to be governed is the chain itself: who started it, what authority was delegated, which data crossed which boundaries, what was combined, and under what validity rule the combination stayed authorized.

Why RBAC, ABAC, and ReBAC do not fully solve it

Role-, attribute-, and relationship-based access control each solve real problems, and none was designed for the workflow-level question a multi-agent system asks. The paper treats them as insufficient here, not obsolete.

One point sharpens the table. ReBAC, the relationship-based paradigm that Google’s Zanzibar system implemented at scale, is the closest fit precisely because it models relationships, and the paper presents it as a foundation to extend for non-human principals and workflow-scoped delegation, not as a failed technology.

The distinction to hold onto is this. "Is this individual access permitted?" is not the same question as "is this entire chain of delegated actions and data combinations permitted?"

From boundary check to workflow property

The paper’s central conceptual move is to treat authorization as a property of a workflow rather than a check on a single request. The governed object is the whole chain: initiating principal, delegation, agent execution, resource access, downstream delegation, data combination, synthesis, and final disclosure. Reasoning about that chain needs visibility into the causal relationships between its events, not just a log of individual API calls: which authority was delegated to whom, which data crossed which boundary, and which sources fed a given synthesis. In a single-agent system authorization is a boundary check; in a multi-agent system it is a flow property that must hold at every point in a directed graph of delegations, accesses, and syntheses.

Seven requirements for a workflow-level authorization architecture

The paper does not propose a finished architecture. It derives seven structural requirements that any sufficient one must meet, and they translate directly into enterprise architecture terms.

These map onto four governance constraints the paper carries from its companion work. Traceability reconstructs the initiating identity, the delegation chain, the data-access chain, and the synthesis chain. Auditability lets an independent reviewer decide whether each access was authorized, whether delegation stayed valid, whether privilege escalated, whether aggregation stayed within policy, and whether final delivery was authorized. Controllability lets the system deny a downstream hop even when the upstream one was authorized, pause or terminate a workflow at a crossed boundary, and degrade to authorized partial results rather than failing whole or over-sharing. Recovery identifies every tainted downstream output, flags delivered results for review, corrects the authorization state, and prevents recurrence.

Ordinary operation already produces these failures

The paper reports three failures observed in a production enterprise AI platform during a stabilisation cycle. None came from an attacker; each came from ordinary configuration, integration, and error-handling decisions, and each was fixed through standard development. Three cases from one system do not prove the formal model, but they show the requirements match real failure modes.

Silent scope widening. A reverse-proxy gateway delegated authentication to an external service. When session binding to a specific workspace failed, the middleware quietly fell back from workspace-scoped authentication to a global context. The user stayed authenticated but was no longer scoped, and later requests reached resources outside the intended boundary. The fix was fail-closed behaviour: if workspace binding fails, the request fails rather than continuing under a wider scope. This is how graceful degradation can turn into authorization escalation.

Delegation reported as successful when it was not. A workspace-entry API returned HTTP 200 even though the session binding that establishes workspace-scoped authorization had failed. The user and the system then behaved as though delegation had succeeded, carrying authority that was never actually established. The fix treated session binding as a precondition rather than an optimisation: if the binding fails, entry fails. Authorization establishment should not be reported as done when the underlying mechanism did not complete.

Infrastructure identity gap. The application layer could confirm that a request came from a legitimate extension, but the container image running it had not been attested through a trusted build pipeline. That left a gap between "this request claims to be Extension X" and "the infrastructure running it is demonstrably Extension X." The fix was an attested dual-build pattern using trusted base images, closing the identity chain from the application layer down into the infrastructure.

The three fixes converge on one pattern: fail closed at the authorization boundary, treat authorization preconditions as preconditions rather than optimisations, and close identity gaps across the application and infrastructure layers. The lesson is that "keep running if the authorization layer fails" is not neutral behaviour. In an agentic system a permissive fallback can move the security boundary itself.

What this means for enterprises running multi-agent AI

The enterprise question shifts from "was this request authenticated?" or "was this user allowed to access this dataset?" to a harder one: can the organisation prove that authority stayed valid from the original requester through every agent, delegation, data access, synthesis step, and final output?

That question gets harder the more boundaries a workflow crosses, and agents increasingly reach sensitive information, internal systems, external tools, private knowledge bases, systems of record, and actions with real-world consequences. The paper’s conclusion is that identity governance has to be treated as infrastructure: evaluated continuously and enforced at every interaction boundary, not checked once at the start or bolted on as a middleware layer. Its analogy is encryption in transit, which moved from an optional choice on "sensitive" endpoints to something always on. In the paper’s reasoning, the cost of deciding per request came to exceed the cost of applying it everywhere, and the cost of deciding wrong was unacceptable.

This is the seam OpenBox, the AI agent governance platform, is built for. It is worth being precise about what maps to the paper’s requirements and what does not; for the wider control set, see the OpenBox enterprise AI agent governance guide.

Start with identity. In OpenBox, every agent has a cryptographic identity, a Decentralized Identifier and an Ed25519 signing key held separately from its API key, so the platform can verify which agent produced a signed request rather than trusting the transport alone (docs.openbox.ai). That speaks to R1, and to the infrastructure identity gap above. When an operation is evaluated, OpenBox returns one of five governance decisions, ALLOW, CONSTRAIN, REQUIRE_APPROVAL, BLOCK, and HALT, with precedence HALT > BLOCK > REQUIRE_APPROVAL > CONSTRAIN > ALLOW, which supports the controllability the paper describes: denying an operation, routing it to a human, or terminating a session at the point a boundary is crossed.

Permissions are expressed as Policies, evaluated as stateless OPA/Rego checks, while Behavioral Rules detect stateful multi-step patterns across a session. That sequence detection is pattern matching over a trajectory, not a general solution to aggregation inference, which the paper leaves open. For the trace requirements, OpenBox Agent Lineage correlates code, runtime identity, sessions, and governance state into one provenance view, and records governance snapshots of the policy, guardrail, and behavioural-rule versions active at a point in time (docs.openbox.ai). Multi-Agent Sessions reconstruct a single multi-agent run as one timeline, showing each agent, each handoff between agents, and the governance verdict recorded at each step.

Session Replay supports post-hoc inspection under the Verify stage. Attestation produces a per-session proof, a Merkle tree of the session’s governance events signed through AWS KMS or an external attestation service, that the recorded events were not altered after the session. Stated precisely, that is tamper-evidence over the record, not proof that the recorded facts are true or complete. Together these constructs map onto R5, R7, traceability, and auditability. What the paper leaves open, no vendor’s current documentation closes.

What remains unsolved

The paper is deliberate about its limits, and an honest account has to keep them. It names the problem and the requirements; it does not claim to solve them.

Aggregation inference is unsolved in the general case, a problem with roots in statistical disclosure control that predates AI. Temporal validity has no single correct policy; the right evaluation point depends on an organisation’s risk tolerance, operational needs, and regulatory context. The paper proposes architectural requirements, not a complete authorization policy language. And it does not assume agents are stable units: as agents become stateful, updatable, dynamically rebound, or self-modifying, deciding whether a changing agent is still the same authorization principal becomes materially harder, a complication the paper acknowledges rather than resolves.

The emerging research reflects this. The paper surveys approaches that each address a fragment, among them invocation-bound capability tokens, task-scoped authorization envelopes, dependency-graph policy enforcement, execution-count-based revocation, and formally verified delegation protocols. The unresolved challenge, in the paper’s framing, is integration: composing bounded and attenuated delegation, task-scoped authorization, causal dependency tracking, temporal-validity mechanisms, and workflow-level traces into one architecture without introducing new failures. No single mechanism does all of it.

The move the paper asks for is smaller and firmer than a solution. Name authorization propagation, keep it distinct from prompt injection, and address it inside the execution architecture rather than assuming it away.

Frequently asked questions

Does solving prompt injection solve authorization propagation?

No. Even with perfect defence against injected content, the system still has to decide which data each agent may reach, what authority passes between agents, and whether the requester may see a synthesis of several sources. The paper shows the two problems are complementary; solving either one leaves the other standing.

Does treating identity governance as infrastructure mean waiting for an agent-identity standard?

No. The paper frames identity governance as something to design into the execution architecture from the start, evaluated continuously and enforced at every boundary. It notes that agent-identity standards are still emerging, but the seven structural requirements can be implemented now rather than waiting for a finished specification.