Multi-Agent Orchestration

the security controls you need when your agents start talking to each other, because individually they’re fine but together they’re a supply chain incident waiting to happen.

"the procurement agent saw 'low stock' and over-ordered 10,000 units. the pricing agent saw the surplus and slashed prices 40%. the finance agent saw the revenue drop and froze hiring. $2M loss. nobody told the agents about each other."
"agent A asked agent B to verify a compliance check. agent B asked agent C. agent C asked agent A. they've been going in circles for three hours and the invoice is still unpaid."
"we gave each agent its own budget limit. none of them exceeded it. but they all spent to the max at the same time. combined spend: 4x the department budget. technically nobody broke a rule."
Share this one
Canonical Definition

Security controls governing agent-to-agent communication, delegation chains, cascading autonomy, and emergent behaviour. Individual agent governance (ART-05) is necessary but insufficient when agents orchestrate other agents.

Why It Matters

Individual agent governance solves a simpler problem. When Agent A operates in isolation, its blast radius is bounded by its own tools, scope, and permissions. Multi-agent orchestration creates a fundamentally different risk profile: agents that interact, delegate, compete for resources, and produce emergent behaviours that no single agent was designed to exhibit.

The structural risk is cascading autonomy. Agent A is authorised to request data. It delegates the request to Agent B, which is authorised to access the database. Agent B returns more data than Agent A needs. Agent A passes it to Agent C, which is authorised to send emails. Agent C emails the full dataset to a customer. Each agent acted within its declared scope. The system-level outcome — sending sensitive data to a customer — was authorised by no one.

This is not a theoretical risk. It is the operational reality of every enterprise deploying more than one agent on shared workflows. The agents do not need to be malicious. They do not need to be misconfigured. They simply need to be unaware of each other’s constraints. And in most deployments, they are.

The Stress Test

Your supply chain runs four AI agents: demand forecasting, procurement, pricing, and inventory management. Each agent has its own ART-05 declaration. Each operates within its declared scope. The demand agent detects a spike and signals high demand. The procurement agent over-orders to capture bulk discounts. The inventory agent, seeing surplus, alerts the pricing agent. The pricing agent slashes prices to move stock. The demand agent, seeing increased sales velocity from the price cut, forecasts another spike. The cycle repeats.

Within 72 hours, you have warehouses full of discounted product, margins destroyed, and a procurement commitment you cannot unwind. Each agent acted rationally within its scope. The system acted irrationally because nobody governed the interactions between the agents. Your ART-05 declarations are compliant. Your supply chain is not.

In the Wild

Supply Chain — Autonomous Agent Feedback Loop, 2025
The $2M Loss Nobody Authorised

A logistics firm deployed separate AI agents for procurement, pricing, and inventory management. The procurement agent detected a low-stock signal and placed a bulk order. The pricing agent, detecting the resulting surplus, automatically reduced prices by 40%. The finance agent, observing the margin compression, flagged a revenue shortfall and froze discretionary spending. The combined effect: $2 million in losses from a feedback loop between three agents, each operating within its individual parameters.

No agent violated its ART-05 declaration. No agent exceeded its tool permissions. The failure was at the system level: no control governed the interaction between agents, and no circuit breaker detected the cascading pattern.

Each agent was right. The system was wrong. That is the multi-agent orchestration gap in one sentence.

Algorithmic Trading — Flash Crash, 2010
When Automated Agents Create Market-Wide Cascades

On May 6, 2010, the U.S. stock market experienced a sudden crash in which the Dow Jones Industrial Average dropped nearly 1,000 points — and recovered — within 36 minutes. The SEC/CFTC investigation attributed the crash to the interaction between a large algorithmic sell order and thousands of high-frequency trading algorithms that responded to each other’s actions, creating a cascading liquidity withdrawal. No single algorithm caused the crash. The crash emerged from the interactions between them.

The 2010 Flash Crash remains the definitive case study for emergent failure in multi-agent systems. The agents were not coordinated. That was the problem.

Research — OWASP Agentic Top 10, 2025
The Threat Taxonomy for Agent-to-Agent Risk

The OWASP Foundation published its Agentic AI Top 10 threat taxonomy in 2025, identifying multi-agent-specific risks including: privilege escalation through delegation chains, agent identity spoofing, cascading hallucination (one agent’s hallucinated output becomes another agent’s trusted input), and resource exhaustion from infinite delegation loops. The taxonomy treats multi-agent orchestration as a distinct attack surface, separate from individual agent vulnerabilities.

Individual agent security is necessary. Multi-agent security is a different discipline entirely. OWASP documented why.

How to Govern It

ART-05 per agent is necessary. It is not sufficient. The system needs its own governance layer.

Within the AI Enterprise Control Index, multi-agent orchestration governance spans multiple layers and shields:

  • Security (S2) — Default-deny delegation policies. Agent A cannot invoke Agent B unless explicitly authorised. Inter-agent authentication: agents verify identity before accepting delegated tasks. Blast radius containment: cascading failures are bounded by circuit breakers at the orchestration layer.
  • AI Engineering (L5) — System-level testing for emergent behaviour. Not just “does each agent work?” but “what happens when they interact?” Adversarial testing of delegation chains, feedback loops, and resource competition.
  • Observability (S4) — Cross-agent trace logging. The trace must follow a task from the initial request through every agent handoff, delegation, and tool call. If you cannot reconstruct the full chain, you cannot govern it.
  • Applications & Agents (L4) — Each agent maintains its own ART-05 declaration, but the orchestration layer has its own governance artifact declaring: which agents can communicate, which delegation paths are permitted, what aggregate resource limits apply, and what circuit breakers exist at the system level.
  • GRC (S1) — Evidence Factory captures system-level test results, delegation chain audits, and inter-agent incident records. The auditor asks not just “show me Agent A’s controls” but “show me the controls on the interaction between Agent A and Agent B.”

When It’s Relevant

Every deployment with more than one AI agent operating on shared data, shared workflows, or shared outcomes. If Agent A’s output can affect Agent B’s input, you have a multi-agent orchestration problem — whether you designed it that way or not.

Multi-agent orchestration risk is highest when:

  • Agents can delegate tasks to other agents without human approval
  • Agent outputs serve as inputs to other agents (cascading data dependency)
  • Agents share access to the same resources (budgets, databases, APIs)
  • No system-level circuit breaker exists for cascading failures
  • The combined autonomy of the agent system exceeds any individual agent’s declared scope

See this control in the framework. Multi-agent orchestration governance is operationalised across S2, L5, S4, and L4 in the AI Enterprise Control Index v6.0.

Open Framework →

Related Terms

Agent Autonomous AI system component Orchestrator Coordinates multiple agents Blast Radius Scope of potential damage Default-Deny No access unless explicitly granted OWASP Agentic Top 10 Agentic AI threat taxonomy Circuit Breaker Auto-stop on failure conditions Runtime Governance Pillar: governing AI at runtime

References

  1. [1] OWASP Foundation (2025) OWASP Top 10 for Agentic AI Applications. Available at: owasp.org/www-project-top-10-for-large-language-model-applications.
  2. [2] SEC and CFTC (2010) Findings Regarding the Market Events of May 6, 2010. Report of the Staffs of the CFTC and SEC to the Joint Advisory Committee on Emerging Regulatory Issues.
  3. [3] Wu, Q., Bansal, G., Zhang, J. et al. (2024) ‘AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation’, arXiv preprint, arXiv:2308.08155v2. Available at: arxiv.org/abs/2308.08155.
  4. [4] Shavit, Y., Amodei, D., Clark, J. et al. (2025) ‘Practices for Governing Agentic AI Systems’, OpenAI white paper. Available at: openai.com/index/practices-for-governing-agentic-ai-systems.
  5. [5] Chan, A., Salganik, R., Markelius, A. et al. (2023) ‘Harms from Increasingly Agentic Algorithmic Systems’, Proceedings of the 2023 ACM Conference on Fairness, Accountability, and Transparency (FAccT), pp. 651–666.
  6. [6] European Parliament and Council (2024) Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (AI Act), Official Journal of the European Union.
  7. [7] Talebirad, Y. and Nadiri, A. (2023) ‘Multi-Agent Collaboration: Harnessing the Power of Intelligent LLM Agents’, arXiv preprint, arXiv:2306.03314. Available at: arxiv.org/abs/2306.03314.

AI Enterprise Control Index v6.0 · Glossary · June 2026 · i-DEPOT 158508 (BOIP) · CC BY-NC-ND 4.0

By Jeroen Janssen, Apparens