Securing a multi-agent system is a different problem from securing a single AI agent. Once agents hand tasks to each other, the failure surface shifts to what happens between them: can Agent B trust what Agent A tells it, does a compromised agent’s error stay contained, and is the surface connecting them governed at all. OWASP’s Top 10 for Agentic Applications names Cascading Failures and Insecure Inter-Agent Communication among the top risks facing agentic systems precisely because of this compositional failure surface, and the risks compound as agent count grows.
This guide covers five compositional attack patterns with real research behind each: agent card spoofing, confused-deputy delegation, uncontained blast radius, cross-agent prompt-injection propagation, and gateway or registry sprawl. It then covers the fix, stated honestly. Cryptographic, scoped identity closes the “who is this” gap. A shared governed context layer closes the separate “is what they said current, approved, and correct” gap. Neither replaces the other.
Why does securing multi-agent systems require a different approach than securing a single agent?
Permalink to “Why does securing multi-agent systems require a different approach than securing a single agent?”Multi-agent systems introduce security risks that don’t exist in single-agent deployments, because the failure surface is what happens between agents once each individually has valid credentials, not what any one agent is authorized to do. Agent access control governs identity, authentication, and retrieval scope for one agent. This page starts one layer up: composition risk between agents that each already passed those checks.
The challenge. Agent frameworks built for A2A-style delegation assume peer agents are trustworthy by default. Research on security considerations for multi-agent systems describes this as introducing “qualitatively distinct” vulnerabilities compared to single-model systems, because that trust assumption fails the moment one agent in the chain is compromised, hallucinating, or simply wrong. A framework that never questions whether a peer’s output is trustworthy has no mechanism to catch it when one isn’t.
The opportunity. Enterprises running multi-agent workflows at scale are already distinguishing this from single-agent security in practice, not just in theory. Teams operating multiple agents handing off tasks to each other report needing controls specifically for agent-to-agent trust, separate from the access controls each individual agent already has.
Who should read this. This page is for teams that already have two or more agents handing off tasks or context to each other, not teams running a single agent. If you’re still at the single-agent stage, agent access control and the broader AI agent risk taxonomy are the right starting points; come back here once delegation is live.
Composition risk is not a bigger version of single-agent risk. It’s a different risk category, and treating it as “more of the same” is the first mistake this guide addresses.
Quick overview
| Time to complete | Difficulty level | Prerequisites | Tools needed |
|---|---|---|---|
| 6-12 weeks for a first production rollout | Intermediate to advanced | 2+ agents already handing off tasks in production | MCP gateway, A2A endpoint, credential/identity system, governed context layer |
5 compositional attack patterns at a glance
| Attack pattern | What breaks | Real-world evidence | Primary defense layer |
|---|---|---|---|
| Agent card spoofing | An agent trusts a forged identity | LevelBlue SpiderLabs research on Agent in the Middle | Cryptographic identity |
| Confused-deputy delegation | A subtask inherits full standing permissions | SANS on AI agents as confused deputies | Scoped, task-bound credentials |
| Uncontained blast radius | One compromised agent’s damage spreads | Kiteworks on AI agent blast radius | Bounded-context isolation |
| Cross-agent prompt-injection propagation | A poisoned instruction survives multiple hops | Research on prompt infection (arXiv) | Governed context + output tagging |
| Gateway or registry sprawl | No control point governs who talks to whom | Enterprise gateway-sprawl signal, multiple MCP gateways with overlapping charters | Decision traces + gateway governance |
Not sure where "identity" ends and "governed context" begins?
The AI Context Stack brief maps out why signed messages and cryptographic identity solve impersonation, but not whether what an authenticated agent says is current or approved.
Get the AI Context StackWhat do you need before you secure a multi-agent system?
Permalink to “What do you need before you secure a multi-agent system?”Before starting implementation, confirm you have the organizational ownership, technical visibility, and team capacity this work requires. Skipping this step is the most common reason multi-agent security projects stall mid-rollout.
Organizational prerequisites:
- An inventory of every agent-to-agent handoff in production. You cannot secure delegation paths you haven’t mapped.
- A named owner for cross-agent security, not just per-agent owners. Composition risk falls through the cracks between individually owned agents.
- Executive sponsorship for a governed context and identity investment. This is infrastructure work, not a configuration change.
Technical prerequisites:
- Visibility into every MCP gateway and A2A endpoint in use. Gateway sprawl (Step 6) can’t be fixed on infrastructure you can’t see.
- A way to issue per-agent, scoped credentials. Most delegation frameworks ship with no built-in agent-to-agent authentication.
- A queryable source of truth agents can check independently. The governed-context fix in Step 5 depends on this existing.
Team and resources: security or platform engineering (20-40% FTE) implements identity and scoping; the AI platform team owns the governed context layer and decision-trace instrumentation.
Time commitment: six to twelve weeks for a first production-scale rollout. See the step-by-step breakdown below.
The 6 steps at a glance
| Step | Focus | Defense layer | Time required |
|---|---|---|---|
| 1. Map your attack surface | Agent, handoff, gateway, and registry inventory | Inventory and named ownership | 1-2 weeks |
| 2. Establish verifiable identity | Agent impersonation / card spoofing | Cryptographic identity | 3-4 weeks (overlaps Step 3) |
| 3. Replace inherited permissions | Confused-deputy delegation | Scoped, task-bound credentials | 2-3 weeks (alongside Step 2) |
| 4. Contain blast radius | Cascading failure | Bounded-context isolation | 2-3 weeks |
| 5. Anchor trust in governed context | Cross-agent prompt-injection propagation | Governed context + output tagging | 4-8 weeks (often underway if a context layer exists) |
| 6. Instrument decision traces | Gateway and registry sprawl | Decision traces + gateway governance | 2-4 weeks (alongside Step 5) |
Step 1: Map your multi-agent attack surface
Permalink to “Step 1: Map your multi-agent attack surface”What you’ll accomplish: a named inventory of every agent, handoff, gateway, and registry, with an owner assigned to each.
Time required: one to two weeks.
You cannot govern a surface you haven’t mapped. Start by listing every agent and the agents it hands tasks to or receives tasks from. Then identify every MCP gateway and A2A endpoint in the environment, and flag any that overlap in charter, a pattern enterprises running multiple multi-agent workflows report as their most pressing structural risk. Finally, flag any handoff with no named owner; those are the ones most likely to be ungoverned by default.
Validation checklist:
- [ ] Every agent has a named owner.
- [ ] Every handoff has a documented sender and recipient.
- [ ] Every gateway and registry is inventoried, not just the ones security already knew about.
Common mistakes: teams inventory agents but skip the gateways and registries between them. Treat gateway sprawl as its own line item, not an afterthought.
Step 2: Establish verifiable identity for every agent
Permalink to “Step 2: Establish verifiable identity for every agent”What you’ll accomplish: every agent has a cryptographic identity that’s verified independently, not assumed from context.
Time required: three to four weeks, overlapping with Step 3.
Agent impersonation happens because agents trust each other by proximity: a message arrived through the expected channel, from something that looked like a peer, so the receiving agent proceeded. Noma Security’s research on inter-agent trust names this as the root failure, not independently verified identity.
The specific mechanic is agent card spoofing. In the A2A protocol, an agent’s identity is published as a discoverable “agent card,” a manifest describing its capabilities and endpoint. An attacker publishes a forged card at a malicious domain, and a legitimate agent performing discovery can trust the fake card and route sensitive tasks to a rogue server, according to LevelBlue SpiderLabs’ research on Agent in the Middle. The result is task hijacking and outright impersonation of a trusted peer.
The fix, per Security Boulevard’s zero-trust framework for agent-to-agent authorization, is cryptographic identity issued per agent plus dynamic trust scoring, so a receiving agent verifies it is talking to a legitimate, uncompromised peer instead of assuming it based on how the message arrived.
Validation checklist:
- [ ] Every agent has a cryptographic identity, not just a network address.
- [ ] Agent cards are signed and verified before a discovered agent is trusted.
- [ ] Trust scores are dynamic, not a one-time check at first contact.
Common mistakes: trusting an agent because it arrived through the “right” channel. Verify identity independently every time, not just at first contact.
Step 3: Replace inherited permissions with scoped, task-bound credentials
Permalink to “Step 3: Replace inherited permissions with scoped, task-bound credentials”What you’ll accomplish: no handoff carries more authority than the specific subtask requires.
Time required: two to three weeks, alongside Step 2.
The confused-deputy problem is a decades-old access-control vulnerability re-emerging in agent delegation. When Agent A hands a subtask to Agent B, B frequently inherits A’s full permission set, including scopes the subtask never needed. Because an agent’s effective authority is shaped by natural-language instructions that prompt injection can manipulate, the deputy becomes confused not from a misconfiguration but from how delegation itself works absent scoped credentials, a pattern the SANS Institute documents in its research on AI agents as confused deputies.
The fix is issuing one-time, task-scoped credentials for each handoff instead of letting the receiving agent inherit the sender’s standing permissions. This is role-based access control applied at the handoff level, not just the agent level, and it works the same way it does for sensitive financial data access: scope to the task, never the role.
Validation checklist:
- [ ] No agent inherits a full permission set from another agent by default.
- [ ] Every delegated task carries its own scoped credential.
- [ ] Credential scope is auditable per handoff, not just per agent.
Common mistakes: granting Agent B the same access as Agent A “to keep things simple.” Scope every handoff to exactly what the subtask requires, nothing more.
Step 4: Contain blast radius before an agent is compromised, not after
Permalink to “Step 4: Contain blast radius before an agent is compromised, not after”What you’ll accomplish: a compromised agent’s damage stays inside its own domain instead of spreading.
Time required: two to three weeks.
An agent’s blast radius, the data it can reach and the actions it can take once compromised, is compounded by autonomy and by persistent memory: a poisoned entry written to a shared memory layer doesn’t disappear when the task completes; it resurfaces in every future session that reads it. Errors don’t stay contained in multi-agent systems, they multiply, because architectures routinely assume peer agents are correct, an assumption that fails the moment any agent in the chain is compromised, hallucinating, or wrong, a pattern Adversa AI’s guide to OWASP’s Cascading Failures category documents in detail. This is one of the reasons AI agents fail in production in ways that are hard to root-cause after the fact.
The fix is bounded-context isolation per agent, so an agent for one domain cannot see another domain’s data by default, plus circuit breakers that halt propagation once monitoring detects anomalous behavior. Kiteworks’ analysis of AI agent blast radius frames this as an architectural decision, not a policy statement layered on after deployment. A related and distinct risk is AI agent hallucination feeding a confidently wrong output into the next agent in the chain; bounded contexts limit how far that error can travel even before anyone catches it.
A governed context checkpoint between agents limits how far a compromised agent’s bad instruction can travel. Source: Atlan
Validation checklist:
- [ ] Each agent’s data access is scoped to its own domain by default.
- [ ] A circuit breaker exists that can halt a compromised agent’s downstream calls.
- [ ] Blast radius has been estimated per agent, not assumed to be zero.
Common mistakes: treating “least privilege” as a bullet point instead of an architecture. Design bounded-context isolation as a first-class pattern per agent, not paper policy.
Do you know your multi-agent context readiness score?
Run a self-assessment against the identity, scoping, and governed-context controls this guide covers, and see where your stack is exposed before an incident finds it for you.
Take the Readiness CheckStep 5: Anchor trust in a shared governed context layer, not just signed messages
Permalink to “Step 5: Anchor trust in a shared governed context layer, not just signed messages”What you’ll accomplish: agents can independently verify whether what a peer claims is current, approved, and correct, not just who sent it.
Time required: four to eight weeks, often already underway if a context layer exists elsewhere in the stack.
Cryptographic identity and signed handoffs solve who’s talking. They don’t solve whether what an authenticated agent is saying is current, approved, or correct, and that gap is exactly how cross-agent prompt injection propagates even between two properly identified agents.
An honest steel-man, worth stating directly. The security research community’s current fixes, cryptographic per-agent identity, signed messages, one-time task-scoped credentials, sandboxing, are mostly transport and identity-layer solutions. A skeptical reader could correctly argue these solve impersonation and confused-deputy risk without needing anything called “governed context” at all. That argument is true as far as it goes. Identity confirms who is talking. It does not confirm whether what they’re saying is current, approved, or correct. An authenticated Agent A can still hand off a stale or wrong fact to an authenticated Agent B, and identity alone does not catch that.
What breaks even with identity fully solved: self-replicating “prompt infection” propagates from one LLM instance to the next without further attacker involvement after the initial injection, distinct from single-agent context poisoning because the corrupted claim travels between agents that each individually authenticated correctly. The fix this step adds is a shared, governed context layer both agents can independently query, so Agent B can check the freshness and approval status of what Agent A claims rather than trusting it by proximity. A related defense is output tagging: marking AI-generated content so a downstream agent distinguishes instructions from its orchestrator from retrieved content it should treat as data, not act on directly. Managing context across multiple agents and detecting context drift before it compounds both depend on this same shared substrate existing in the first place.
What identity fixes vs. what governed context fixes
| Question it answers | Identity/transport layer | Governed context layer |
|---|---|---|
| Is this really who it claims to be? | Yes, cryptographic identity and signed messages | Out of scope |
| Is what they said current, approved, and correct? | No, an authenticated agent can still be wrong | Yes, verifiable against a shared governed source |
| Can a downstream agent independently check, not just trust? | No, trust is proximity-based once identity passes | Yes, the receiving agent queries the same context graph |
Validation checklist:
- [ ] Agents can query a shared governed context source independently, not just receive claims from peers.
- [ ] Output from upstream agents is tagged and distinguishable from retrieved data.
- [ ] Your architecture treats identity and governed context as complementary, not either-or.
This is not a case for skipping identity infrastructure. It’s a case for pairing it with a layer that answers the question identity was never designed to answer.
Step 6: Instrument decision traces and govern the gateway layer
Permalink to “Step 6: Instrument decision traces and govern the gateway layer”What you’ll accomplish: every cross-agent handoff is reconstructable after the fact, and gateway ownership overlaps are visible before an incident forces the question.
Time required: two to four weeks, alongside Step 5.
Gateway and registry sprawl, multiple MCP gateways with overlapping charters and skill registries growing faster than any team can review, is a structural risk even without an adversary. Securing individual agent-to-agent messages is necessary but not sufficient if the surface of who’s talking to whom is itself ungoverned, a pattern that maps to research on authorization propagation across multi-agent systems.
The fix is making every handoff reconstructable from a single task ID: sender identity, recipient identity, task ID, delegation depth, and validation result. Decision traces are the mechanism, and they’re also what AI agent observability tooling should be capturing by default rather than bolting on after an incident. Gateway ownership should be consolidated where possible, or at minimum charter-mapped so overlaps are visible, the same discipline organizations already apply when they document data access controls for an audit.
Validation checklist:
- [ ] Every cross-agent handoff produces a decision trace an auditor can reconstruct.
- [ ] Gateway and registry ownership is mapped, with overlaps flagged, not discovered during an incident.
Common mistakes: logging prompts and responses but not the decision rationale behind a handoff. Capture the full trace: who, to whom, on what authority, with what result.
What do teams get wrong when securing multi-agent systems?
Permalink to “What do teams get wrong when securing multi-agent systems?”Most failures in this space trace back to one of five habits, each mapped to the mechanic it leaves unaddressed.
Treating agent-to-agent trust as solved by network-level access controls. Teams assume a firewall or VPC boundary is enough because that’s how service-to-service trust worked before agents. Verify identity at the agent layer, not just the network layer; add cryptographic per-agent identity before the next incident, not after.
Letting delegated agents inherit full permission sets “to keep things simple.” Scoped credentials are more setup work than a shared service account, so teams skip them. Scope every handoff to the subtask, nothing more, and audit current delegation paths for over-permissioned inheritance now, not after an audit finds it.
Assuming identity verification solves the trust problem completely. It’s the fix the security research community is actively building, so it reads as complete. It isn’t. Pair identity with a governed context layer that verifies freshness and correctness, not just origin, per the steel-man in Step 5.
Treating blast radius as a “least privilege” bullet instead of an architecture. Least privilege is familiar; bounded-context isolation per agent is new infrastructure work, so teams default to the familiar option. Design domain isolation and circuit breakers before scaling agent count, starting with your highest-blast-radius agent.
Discovering gateway or registry sprawl during an incident, not before one. Gateways get added team by team with no central inventory until something breaks. Inventory every MCP gateway and skill registry as Step 1, before anything else, and consolidate or charter-map overlapping gateways immediately once found.
What are the best practices for securing multi-agent AI systems at scale?
Permalink to “What are the best practices for securing multi-agent AI systems at scale?”These five practices turn the mechanics above into a standing operating discipline, not a one-time rollout.
Verify identity independent of the message itself. Never trust an agent because it arrived through the “right” channel. WorkOS’ guidance on securing agent delegation frames this as the direct counter to agent card spoofing.
Scope every credential to a single task, never a standing permission. Okta’s guidance on agent-to-agent connections notes this eliminates the confused-deputy failure mode structurally, not by policy alone.
Design for containment before you need it. Bounded-context isolation and circuit breakers should exist before agent count scales, not after an incident forces the question.
Treat governed context as complementary to identity, not a replacement for it. Both layers are required; neither alone is sufficient, and pages that claim otherwise are overselling one half of the fix.
Make every handoff reconstructable. A decision trace per handoff, sender, recipient, task ID, delegation depth, validation result, turns incident response from guesswork into a lookup.
The teams that get this right stop treating multi-agent security as a longer version of the same access-control checklist they already ran for a single agent. It’s a different problem, with its own five named failure modes, and it needs its own architecture.
How Atlan secures multi-agent context handoffs
Permalink to “How Atlan secures multi-agent context handoffs”Manually, teams bolt identity and logging onto each agent pair individually, so coverage is uneven and no one can answer “what did Agent A actually know when it made this handoff” after the fact. That gap is exactly where the composition risks in this guide live.
Atlan’s Context Governance & Observability enforces policy at the context layer, not just the message layer. The Enterprise Data Graph is the shared substrate both agents can query independently to check freshness and approval status, the same role Atlan’s MCP server plays when serving context with provenance attached, so a receiving agent can check a claim rather than trust it by proximity. Decision traces reconstruct what context an agent had and what it decided, per handoff, giving auditors the reconstructable record Step 6 requires. Policy Center issues scoped, task-bound authorization instead of inherited standing permissions, the direct architectural counter to confused-deputy exploitation described in Step 3. Teams building this from scratch often start with how to build an AI agent harness and the broader discipline of context engineering before layering multi-agent-specific controls on top.
No named case study is public yet for multi-agent composition security specifically. Enterprise signal on gateway sprawl and bounded-context isolation requests is real and directional, not a published result, and it’s stated honestly here rather than implied as a customer outcome that hasn’t shipped yet.
Real stories from real customers: Governed context at scale
Permalink to “Real stories from real customers: Governed context at scale”"We're excited to build the future of AI governance with Atlan. All of the work that we did to get to a shared language at Workday can be leveraged by AI via Atlan's MCP server, as part of Atlan's AI Labs, we're co-building the semantic layer that AI needs with new constructs, like context products."
— Joe DosSantos, VP of Enterprise Data & Analytics, Workday
"Atlan is much more than a catalog of catalogs. It's more of a context operating system. Atlan enabled us to easily activate metadata for everything from discovery in the marketplace to AI governance to data quality to an MCP server delivering context to AI models."
— Sridher Arumugham, Chief Data & Analytics Officer, DigiKey
Ready to see governed context stop a real handoff failure?
Watch the Context Layer verify an agent-to-agent handoff live, the same identity and governed-context patterns this guide covers, applied to a real multi-agent stack.
Watch the Context SeriesMulti-agent security needs governed context alongside identity, not instead of it
Permalink to “Multi-agent security needs governed context alongside identity, not instead of it”Once identity, scoping, and containment are live, measure success by handoffs with a complete decision trace, not by control-checklist completion. A checklist item marked done tells you a control exists. A decision trace tells you the control fired correctly on a real handoff, which is the evidence an auditor actually needs.
The next stage is evolving toward consolidated gateway and registry ownership as agent count grows. That’s a governance maturity step, not a one-time fix, and it’s the same shift this cohort’s broader argument makes about AI risk management: governance that lives in a document or a quarterly review cycle cannot keep pace with agents that act continuously. It has to live in the same governed context layer every agent already depends on to work at all, sitting alongside the identity layer, not replacing it.
Protocols move context between agents. They don’t decide whether it’s correct. Identity confirms who’s talking, and it genuinely resolves impersonation and confused-deputy risk when it’s implemented well. What it doesn’t resolve is whether an authenticated agent’s claim is current, approved, or true, and that’s the separate gap a shared governed context layer closes. Neither layer substitutes for the other. A stack with only one of them is half-built, and this guide treats both as infrastructure for exactly that reason.
FAQs about securing multi-agent systems
Permalink to “FAQs about securing multi-agent systems”1. How is securing a multi-agent system different from securing a single AI agent?
Permalink to “1. How is securing a multi-agent system different from securing a single AI agent?”Single-agent security controls what one agent is authorized to retrieve when it is invoked. Multi-agent security controls what happens between agents once each individually holds valid credentials: whether Agent B should trust what Agent A hands it, whether a compromised agent’s errors spread downstream, and whether the gateways routing those handoffs are governed at all. Both layers are required; multi-agent security assumes single-agent access control is already in place.
2. How long does it take to secure an existing multi-agent AI deployment?
Permalink to “2. How long does it take to secure an existing multi-agent AI deployment?”A first production-scale rollout typically takes six to twelve weeks. Planning and inventory take one to two weeks. Identity and credential scoping take three to six weeks. Governed context and decision-trace instrumentation take four to eight weeks, often faster if a context layer already exists. Teams that skip the inventory step routinely underestimate the timeline, because gateway and registry sprawl surfaces mid-implementation.
3. Do you need a dedicated security team to implement these controls?
Permalink to “3. Do you need a dedicated security team to implement these controls?”Not a dedicated team, but you need named ownership split two ways. Security or platform engineering, at roughly 20 to 40% FTE, implements identity and credential scoping. The AI platform team owns the governed context layer and decision-trace instrumentation, since that infrastructure typically already exists for other reasons. What fails is leaving cross-agent security to individual agent owners with no one accountable for the composition risk between them.
4. What is the confused deputy problem in multi-agent AI systems?
Permalink to “4. What is the confused deputy problem in multi-agent AI systems?”The confused deputy problem occurs when Agent A hands a subtask to Agent B, and B inherits A’s full permission set instead of only the scope the subtask needs. Because an agent’s effective authority is shaped by natural-language instructions that prompt injection can manipulate, the deputy becomes confused not from misconfiguration but from how delegation itself works without scoped, task-bound credentials. The fix is issuing one-time credentials scoped to each handoff.
5. What’s the difference between prompt injection and prompt infection?
Permalink to “5. What’s the difference between prompt injection and prompt infection?”Prompt injection is a malicious instruction inserted into a single agent’s input, typically through retrieved content. Prompt infection is what happens next in a multi-agent system: a successfully injected agent crafts a message to a downstream peer containing hidden instructions, and research documents self-replicating variants that propagate from one LLM instance to the next without further attacker involvement. Injection is the entry point; infection is the propagation mechanism.
6. Does the A2A or MCP protocol make multi-agent systems secure by default?
Permalink to “6. Does the A2A or MCP protocol make multi-agent systems secure by default?”No. A2A and MCP move context and tasks between agents; they do not decide whether what moved is current, approved, or from a legitimate source. An agent-to-agent connection can be perfectly protocol-compliant and still carry a forged agent card, an over-scoped inherited credential, or a poisoned instruction. Protocol adoption solves plumbing, not trust. Both a verified-identity layer and a governed context layer sit on top of the protocol, not inside it.
7. What is a secure agent handoff or delegation protocol?
Permalink to “7. What is a secure agent handoff or delegation protocol?”A secure handoff verifies the receiving agent’s identity independent of the message itself, issues that agent a credential scoped only to the delegated subtask, and logs the handoff as a reconstructable decision trace: sender, recipient, task ID, delegation depth, and validation result. A handoff missing any of these three properties, verified identity, scoped credential, or a logged trace, is not secure regardless of which transport protocol carries it.
8. Can a prompt injection in one agent spread to other agents in the pipeline?
Permalink to “8. Can a prompt injection in one agent spread to other agents in the pipeline?”Yes. When agents treat output from an upstream peer as trusted input by default, an injected agent can pass hidden instructions to the next agent in the chain, and the next agent to the one after that. Academic research on prompt infection documents this as a self-replicating attack, not a one-time event. Output tagging, marking AI-generated content so a downstream agent can distinguish instructions from retrieved data, is one defense against the spread.
9. How do you contain a compromised agent so it doesn’t take down the rest of the pipeline?
Permalink to “9. How do you contain a compromised agent so it doesn’t take down the rest of the pipeline?”Contain it architecturally, before the incident, not after. Bounded-context isolation limits each agent’s data access to its own domain by default, so a compromised agent cannot reach data outside its scope regardless of what it is instructed to do. Circuit breakers halt downstream calls once anomalous behavior is detected. Treating this as a one-time least-privilege checklist item, instead of a standing architectural pattern, is the most common reason blast radius goes uncontained.
10. What is gateway or registry sprawl in multi-agent enterprise deployments?
Permalink to “10. What is gateway or registry sprawl in multi-agent enterprise deployments?”Gateway or registry sprawl is when multiple MCP gateways or agent-to-agent channels exist with overlapping charters, and skill or tool registries grow faster than any team reviews them. No single control point can then enforce who is allowed to hand what to whom. It is a structural risk that exists even without an adversary, and enterprises running multi-agent workflows at scale report it as their most pressing operational exposure, ahead of any single named attack.
Sources
Permalink to “Sources”- Teleport, “OWASP Top 10 for Agentic Applications 2026: Key Takeaways & How to Take Action.” https://goteleport.com/blog/owasp-top-10-agentic-applications/
- arXiv, “Security Considerations for Multi-agent Systems.” https://arxiv.org/pdf/2603.09002
- Noma Security, “Your Agents Are Trusting Each Other, Should They?” https://noma.security/blog/your-agents-are-trusting-each-other-should-they/
- LevelBlue SpiderLabs, “Agent In the Middle, Abusing Agent Cards in the Agent-2-Agent Protocol.” https://www.levelblue.com/blogs/spiderlabs-blog/agent-in-the-middle-abusing-agent-cards-in-the-agent-2-agent-protocol-to-win-all-the-tasks
- Security Boulevard, “Zero Trust Authorization for Multi-Agent Systems: When AI Agents Call Other AI Agents.” https://securityboulevard.com/2026/03/zero-trust-authorization-for-multi-agent-systems-when-ai-agents-call-other-ai-agents/
- SANS Institute, “Your AI Agent Is an Easily Confused Deputy: Why Cloud Security Needs a Credential Broker.” https://www.sans.org/blog/your-ai-agent-easily-confused-deputy-why-cloud-security-needs-credential-broker
- Kiteworks, “AI Agent Blast Radius: Risks of Ungoverned Failures at Scale.” https://www.kiteworks.com/cybersecurity-risk-management/ai-blast-radius-governance-failure/
- Adversa AI, “Cascading Failures in Agentic AI: OWASP ASI08 Security Guide 2026.” https://adversa.ai/blog/cascading-failures-in-agentic-ai-complete-owasp-asi08-security-guide-2026/
- arXiv, “What If Prompt Injection Never Left? Exploring Cross-Session Stored Prompt Injection in Agentic Systems.” https://arxiv.org/html/2606.04425
- arXiv, “Authorization Propagation in Multi-Agent AI Systems: Identity Governance as Infrastructure.” https://arxiv.org/pdf/2605.05440
- WorkOS, “How to Secure AI Agent Delegation and Multi-Agent Communication.” https://workos.com/blog/ai-agent-delegation-multi-agent-security
- Okta, “Securing Your Multi-Agent Workflows with Agent-to-Agent Connections.” https://www.okta.com/blog/product-innovation/securing-agent-to-agent-connections/
