Multi-agent architecture in production: three authorization-error patterns observed on engagements

Transparency note. This article is written in line with IgnitionAI's editorial policy. References to the OWASP Top 10 for LLM Applications & AI Agents framework link to the official documentation with a link and date of access. The error patterns described are cases reconstructed from IgnitionAI engagements 2024-2025; no client is identifiable. Architecture recommendations are expert estimates tagged as such.

The typical scenario

An organisation deploys a multi-agent system in production to automate a composite business process. The chosen architecture follows the supervisor-worker pattern that became standard from 2024: an orchestrator agent receives the user request, breaks it into sub-tasks, and delegates each sub-task to a specialised agent. Depending on the engagement, the sub-agent pool typically includes a document-search agent, a data-analysis agent, a writing agent, an information-extraction agent on a specific business system, and sometimes an external-API-call agent.

The system was designed by a competent technical team, tested on representative use cases, deployed after validation. It works. Users are happy with the productivity gain. And it exposes to some of them information they should never have received.

The audit points to an initial architecture decision. The orchestrator was designed with global access to the organisation's data and tools. The developer reasoned that since the orchestrator was "internal", executed server-side and not directly exposed to users, it could hold a broad capability perimeter. Consequence: the sub-agents the orchestrator invokes effectively inherit this broad perimeter through the execution context.

One of the sub-agents has access to particularly sensitive data as part of its nominal work — typically, in the engagements observed, named HR data, non-public financial data, ongoing legal files, or pre-publication commercial results. When an end user phrases a request that leads the orchestrator to mobilise this sub-agent, they receive in return elements exceeding their individual access rights.

The user did nothing illegitimate. Their request is business-related, normal, consistent with their role. The response crossed an authorization boundary it should never have crossed. No application logging flags an anomaly: as far as the technical components are concerned, everything happened according to the configured rules.

This is precisely the kind of risk the OWASP framework has categorised.

OWASP has a name for this category: LLM06 Excessive Agency

The OWASP Top 10 for LLM Applications & AI Agents project has published since 2023 a framework of security risks specific to systems based on large language models. The 2025 version (OWASP Top 10 for LLM Applications 2025, accessed 24 May 2026) has ten entries, one of which is explicitly devoted to agents: LLM06:2025 Excessive Agency.

The official definition sets the frame: "An LLM-based system is often granted a degree of agency by its developer, the ability to call functions or interface with other systems via extensions" (OWASP LLM06:2025 Excessive Agency, accessed 24 May 2026). The risk arises when this agency is granted without proportionate guardrails.

The framework identifies three roots of the Excessive Agency vulnerability.

Excessive Functionality — the system has more capabilities than it needs for its task. A "read-only" extension that also includes deletion capability. A plugin inherited from the development phase that stays accessible in production.

Excessive Permissions — the system inherits broader rights than those required by its legitimate use. A database connection with INSERT/UPDATE/DELETE capabilities when only a SELECT was needed. A high-privilege service account used in place of the initial user context.

Excessive Autonomy — the system executes high-impact actions without explicit validation or approval. No human loop on critical operations.

OWASP notes that in multi-agent architectures: "The decision over which extension to invoke may also be delegated to an LLM 'agent' to dynamically determine based on input prompt or LLM output". This dynamic delegation amplifies the risk: the orchestrator doesn't know in advance which sub-agents will be invoked, and so static analysis of authorization paths becomes difficult.

The opening scenario of this article stems from all three roots at once: excessive functionality (a sub-agent in the orchestrator's pool with no functional justification), excessive permissions (the orchestrator executing actions with its own authority context rather than the initial user's), and excessive autonomy (no user validation on requests mobilising sensitive data).

Error pattern #1: Orchestrator with no complete mediation

The principle of complete mediation, one of the ten computer-security principles formalised by Saltzer and Schroeder in 1975, requires that every access request to an object be checked by an authorization mechanism at the moment access is attempted. This principle is recalled by OWASP in its LLM06 mitigation list: "Complete mediation, enforce authorization at downstream systems".

In multi-agent architecture, the typical error pattern is to concentrate all authorization logic at the orchestrator level — or worse, to omit it, assuming the sub-agents carry it. Yet two reasons make this concentration risky.

First, the orchestrator dispatches dynamically to sub-agents based on the user prompt and context. The developer cannot enumerate at design time all the possible invocation paths. Centralised authorization logic must therefore handle the whole combinatorics, which is almost always under-specified in real implementations.

Second, sub-agents are often reused across several contexts (the same document-search agent may be invoked by several different orchestrators for distinct use cases). If each orchestrator applies its own authorization logic, the sub-agents silently accumulate undocumented access paths.

The correct rule: authorization must be enforced at the level of each agent that accesses data or tools, not at the orchestrator level. The orchestrator keeps a functional-coordination role (which agent is best qualified for this sub-task) but does not carry responsibility for authorization (is this user allowed to trigger this agent on this data). Each sub-agent must explicitly receive the initial user's identity context and check their rights before acting.

Error pattern #2: Sensitive-data sub-agent in a generic pool

The second pattern concerns the architectural placement of agents that access sensitive data. The simple rule: an agent that handles critical data must not appear in the generic sub-agent pool that a cross-cutting orchestrator can invoke dynamically.

The reasoning is asymmetric. A document-search agent that queries the organisation's public knowledge base can legitimately be called by any orchestrator — its access perimeter is public, its behaviour non-modifying. An agent that queries the HRIS with access to individual payslips, or an agent that consults the legal committee's confidential notes, is not the same nature. Putting this kind of agent in the generic pool turns every orchestrator that discovers it into an access channel to that data.

The correct architecture decision places this kind of agent in a dedicated business service, exposed only to explicitly authorized workflows, with its own access-control mechanism enforced at the service level regardless of who calls it. The cross-cutting orchestrator doesn't even know this service exists; it cannot invoke it.

This separation comes back to the OWASP principle of minimize permissions: "Apply principle of least privilege to database/system access". Applied to multi-agent architecture: each agent only has access to the data strictly necessary for its function, and an agent is only exposed to the flows that need it. If a sub-agent asks to be added to the generic pool for a specific use case, that's a signal to question its functional perimeter, not to grant it by default.

Error pattern #3: Transitive delegation with no user context

A third pattern, less frequent but subtler, concerns the propagation of identity context through the delegation chain. The orchestrator receives the request from user Alice. It analyses it, identifies that sub-agent A must be invoked. Agent A, in the course of its own execution, determines it needs to invoke sub-agent B to obtain missing information. Sub-agent B is called with sub-agent A's execution context, not with Alice's.

If sub-agent B checks authorization based on the context that calls it (sub-agent A), it will grant rights corresponding to A and not Alice. If A holds a high-privilege service account for its functional needs, B will execute the request with those privileges, regardless of Alice's actual rights.

The correct pattern: each inter-agent call must propagate the initial user's identity context, and each agent must check authorization against that context, not against the calling agent. Technically, this is implemented via a user security token carried through the call chain, or via an on-behalf-of mechanism such as those supported by the OAuth 2.0 protocols (RFC 8693 Token Exchange).

OWASP states this rule in condensed form: "User context execution, ensure actions occur in the specific user's security scope". It's one of the most systematically omitted mitigations in the production multi-agent architectures observed on engagements.

The eight OWASP mitigations applied to multi-agents

OWASP LLM06 lists eight main mitigations. Here is their operational translation to the multi-agent context.

1. Minimize extensions. The sub-agent pool accessible to an orchestrator must be restricted to those strictly necessary for the orchestrator's functional perimeter. A generic agent exposed to all orchestrators is an anti-pattern.

2. Minimize functionality. Each sub-agent only has the capabilities required for its function. A document-reading agent has, by construction, no write or delete capability on the document source.

3. Avoid open-ended extensions. No generic agent of the "execute any SQL query on the database" type. Prefer granular agents with typed interfaces ("fetch the client file by ID", "list active contracts for an account").

4. Minimize permissions. Each agent holds the access perimeter strictly necessary for its function. No database connection with broad rights by default.

5. User context execution. Every agent action executes in the initial user's identity context, propagated through the delegation chain. No use of high-privilege service accounts to execute actions on behalf of users.

6. Require approval. High-impact actions (data modifications, sending communications, triggering critical business processes) require explicit human validation before execution. Implemented via a workflow-interruption and user-presentation mechanism.

7. Complete mediation. Authorization is enforced at the level of each agent that accesses data or tools, not centralised at the orchestrator level. Each sub-agent independently checks the authorization of the incoming request.

8. Sanitize inputs / outputs. Classic application-security practices extended to inter-agent flows: validate data received from another agent as you would validate data received from an external client.

To these eight main mitigations, add two damage reduction measures: detailed logging of inter-agent activity (after-the-fact traceability of delegation paths) and rate-limiting (capping the invocation rate to contain the impact of anomalous behaviour).

Recommendation by architecture maturity

All the recommendations that follow are IgnitionAI estimates based on the multi-agent audit engagements conducted in 2024-2025.

Multi-agent architecture in the design phase

The cost of applying the eight OWASP mitigations is negligible in the design phase. The main difficulty is holding the line against the pressure to ship fast. The operational rule: don't put a multi-agent system into production without having explicitly documented, for each sub-agent, its capability perimeter, its access perimeter, its user-context propagation mode, and its authorized autonomy level. This few-page document forms the basis of the later security audit.

Multi-agent architecture already in production with no prior audit

Run an OWASP LLM06 audit on the existing architecture. Identify as a priority: the sub-agents that expose sensitive data; the absence or presence of user-context propagation; the transitive delegation paths (an agent calling another agent). The typical output is a per-sub-agent risk matrix classified by the three roots (functionality, permissions, autonomy). Remediation is planned over three to six months depending on complexity, starting with the most exposed sub-agents.

Multi-agent architecture with an incident already reported

Suspend the orchestrator during the investigation, or temporarily restrict its sub-agent pool to non-sensitive services. Run the forensic investigation: which users received data beyond their rights, over what period, via which delegation paths. Notify stakeholders under Article 33 of the GDPR if personal data is involved. Launch the architectural remediation in parallel.

Conclusion

Multi-agent architectures rarely fail at the level of the individual agent. Taken in isolation, each agent may be well designed, properly tested, secured according to application best practices. The defect appears in the composition: orchestration between agents, propagation of identity context, the architectural placement of sensitive-data agents. It's a kind of risk no unit code review detects, because it lives in the interactions and not in the components.

The OWASP LLM06 Excessive Agency framework provides a risk reference directly applicable to these architectures. Its eight mitigations are operational, verifiable, and compatible with the main multi-agent frameworks (LangGraph, CrewAI, AutoGen, in-house frameworks). The discipline of applying them remains the architecture team's responsibility.

Three questions to ask systematically in a multi-agent architecture review: "Does each sub-agent independently check authorization, or does it rely on the orchestrator?", "Is the initial user's identity context propagated through the delegation chain, or lost on the way?", "Is there a sub-agent in the generic pool that accesses data whose exposure would be unacceptable?". If any of these three questions has no documented and tested answer, the architecture is exposed to the kind of defect described in this article.

Methodology and sources

Technical sources (accessed 24 May 2026)

OWASP, Top 10 for LLM Applications 2025
OWASP, LLM06:2025 Excessive Agency
OWASP, LLM01:2025 Prompt Injection (reference for the inter-agent attack context)

Security principles referenced

Saltzer, J. H., and Schroeder, M. D. (1975), The Protection of Information in Computer Systems, Proceedings of the IEEE 63(9). The canonical source for the principles of complete mediation, least privilege, fail-safe defaults, still referenced in modern security frameworks (MIT, online version).
IETF RFC 8693, OAuth 2.0 Token Exchange, for controlled propagation of identity context between services.

Regulatory sources (accessed 24 May 2026)

Regulation (EU) 2024/1689 of 13 June 2024 (AI Act, amended by the Digital Omnibus of 7 May 2026), official EUR-Lex version. Multi-agent architectures typically fall within the scope of high-risk systems under Annex III depending on their use (worker management, access to essential services, etc.); Articles 9 (risk management), 12 (logging) and 14 (human oversight) apply.
Regulation (EU) 2016/679 of 27 April 2016 (GDPR), official EUR-Lex version. Article 33 cited (personal-data breach notification).

Multi-agent frameworks mentioned

The main open-source multi-agent orchestration frameworks in production in 2026: LangGraph, CrewAI, AutoGen. These frameworks provide the technical primitives to implement the supervisor-worker pattern. The security mitigations described in this article must be implemented by the architecture team — these frameworks do not impose them by default.

IgnitionAI estimates

The error patterns described are aggregated, reconstructed cases from IgnitionAI engagements 2024-2025 on the audit of multi-agent architectures in production. No client is identifiable. The architecture recommendations (placing sensitive-data agents in a dedicated service, propagating user context via OAuth Token Exchange, etc.) are expert best practices applicable to most contexts, to be adapted to the client's precise technical stack.

Limitations and invitations to verify

The OWASP Top 10 for LLM Applications framework is evolving rapidly. The 2025 version referenced here may have been superseded by a later version by the date you read this. Check the official page for the current version.
This article does not constitute a security audit directly applicable to a specific architecture. Every multi-agent architecture has its specifics that require a case-by-case analysis.

Correction policy

If you identify a factual error, a source that has become outdated or an inaccurate reference, report it via the dedicated form on our editorial policy. The correction procedure applies within 5 business days.

Last source review

24 May 2026. This article is part of our January annual review.

This article is part of our approach to AI governance at IgnitionAI. For an OWASP LLM06 audit of your multi-agent architecture, a compliance scoping or the design of a new architecture, tell us about your project. Our page dedicated to AI governance details our full approach. See also our article on access control in an enterprise RAG which covers the access-control dimension at the retrieval level, and our Microsoft 365 Copilot article which addresses Microsoft agentic architectures.