Multi-Agent System Security: Govern Agent-to-Agent Delegation in Multi-Agent AI
Securing each agent separately does not secure the system they form. The risk lives in the handoff: one agent delegating to another, passing context, and inheriting privilege it was never meant to hold.
Direct answer
Multi-agent system security is the practice of controlling what happens between AI agents, not just inside each one: which agent may delegate to which, what authority travels with a delegated task, what context is allowed to cross a trust boundary, and what stops one compromised agent from cascading through the rest. It matters because a collection of individually safe agents is not a safe collection of agents. Interaction creates failure modes, including prompt-injection propagation down a delegation chain, privilege escalation through implicit peer trust, agent impersonation, and cascading errors, that single-agent testing never surfaces. Agentshield enforces those boundaries at runtime: every agent gets its own identity and least-privilege tool and data scope, every cross-agent call and tool call is checked against policy before it runs, irreversible actions are held for a human, and every hop is recorded in an immutable trail you can replay.
Try it live
Watch Agentshield block an attack in real time.
Pick a scenario and drive the inspection lane yourself. No signup needed.
Run a request
Inspection lane
INSPECTINGPolicy trace
High-risk action held for approval
Audit trail
- § · → → →
The risk
A planner agent hands a task to a research agent, which reads a poisoned web page and hands a summary to an executor agent that holds a payments tool. Each agent behaved exactly as designed. The system just wired an attacker straight to a transfer, and no log tells you which hop went wrong.
How Agentshield handles it
Agentshield sits on the action path of every agent in the fleet, so a handoff is a policy decision instead of an assumption. Each agent authenticates as itself and carries its own permission scope, so a delegated task cannot execute with more authority than the delegating agent legitimately held. Untrusted text is inspected for injection before any agent acts on it, which stops an injected instruction from propagating downstream. Out-of-scope tool calls are blocked, irreversible actions are held for human approval, and every hop, verdict, and payload boundary is written to an immutable audit trail so you can replay the exact chain that produced an outcome.
The controls
The controls that secure the handoffs between your agents, not just each agent on its own.
What is multi-agent system security?
Multi-agent system security is the control of interactions between AI agents: delegation, message passing, shared memory, and the authority that moves with a handed-off task. A single-agent security program asks whether this agent can be tricked into misusing its own tools. A multi-agent program asks a harder question: when agent A asks agent B to do something, on whose authority does B act, with what data, and who is accountable for the result.
Research on agentic systems keeps landing on the same conclusion: a collection of safe agents does not imply a safe collection of agents. The emergent behavior is the point. Each agent passes its own evaluation, and the composition still fails, because the failure lives in the wiring rather than in any single component.
This has stopped being theoretical. Gartner projects that 40 percent of enterprise applications will include task-specific AI agents in 2026, up from under 5 percent in 2025. Fleets are the default architecture now: a planner, a set of specialists, and an executor with real credentials. The security boundary that used to sit around one agent now has to sit between every pair of them.
What are the security risks of multi-agent AI systems?
Multi-agent risks are the hazards that only appear when agents interact. They are invisible to a per-agent test because no single agent is misbehaving. Here are the ones that produce real incidents, and what actually stops each.
| Risk | What it looks like | Control that stops it |
|---|---|---|
| Injection propagation | A research agent reads a poisoned page; the instruction travels down the chain and the executor acts on it | Inspect untrusted text at every boundary, not just the first one |
| Privilege escalation through peer trust | A low-privilege agent gets a high-privilege agent to run the call it could not make itself | Per-agent identity plus a permission scope that does not widen on delegation |
| Confused deputy on delegation | A delegated task executes with the executor authority instead of the requester authority | Bind authority to the originating principal and check it at the tool call |
| Agent impersonation | A rogue service advertises itself as a trusted agent and receives sensitive tasks | Cryptographic workload identity and verified endpoints, not self-declared metadata |
| Cross-boundary data leakage | Shared context or memory carries regulated data into an agent that should never see it | Data scoping per agent plus egress inspection on every hop |
| Cascading failure | One agent error is amplified by four downstream agents acting on it as fact | Approval gates on irreversible actions and per-hop monitoring |
| Recursive delegation loops | Agents delegate back and forth until budget, rate limits, or the system exhausts | Depth and budget limits enforced outside the agents themselves |
| Attribution gaps | Something wrong happened and no record shows which hop caused it | An immutable trail keyed to agent identity across the whole chain |
Two of these deserve emphasis because teams consistently underrate them. Injection propagation defeats the common assumption that you only need to sanitize the user-facing entry point; in a fleet, the dangerous input usually arrives mid-chain, from a tool result or a peer agent, long after your one inspection point. And the confused deputy problem is not a bug in anyone code. It is the natural consequence of an executor agent holding broad credentials and doing what it is asked. We cover the mechanics of that in AI agent privilege escalation.
How do you secure a multi-agent system?
You secure a multi-agent system by making every handoff an enforced decision instead of an implicit trust relationship. The pattern below works regardless of whether you orchestrate with A2A, MCP, a framework like LangGraph or CrewAI, or your own message bus.
- Give every agent its own identity. Not a shared service account. Each agent authenticates as a distinct workload so you can scope it, revoke it, and attribute its actions. See AI agent identity and how AI agents authenticate.
- Scope each agent to its own job, then never widen on delegation. The executor should not be the one agent with every credential. If a task is delegated, the authority that travels with it is the intersection of what the requester held and what the task needs, never the union. This is least-privilege access control applied to a graph rather than a single node.
- Inspect untrusted text at every boundary. Tool results, retrieved documents, and messages from peer agents are all attacker-influenced. Run prompt-injection detection on each hop, because the poisoned input rarely enters through the front door.
- Verify who you are talking to. Treat capability metadata as a claim, not a credential. An agent that says it is the finance agent should have to prove it with a verifiable identity and a known endpoint before it receives a task or a token.
- Bound the graph. Set maximum delegation depth, per-chain budgets, and timeouts outside the agents. Agents that can recurse will eventually recurse, and no prompt reliably prevents it.
- Gate the irreversible actions once, at the end. Payments, deletes, external sends, and production writes get a human approval regardless of how many agents agreed on the way there. Consensus among agents is not evidence.
- Record the whole chain. Log every hop with the acting agent identity, the requesting agent, the policy verdict, and the data that crossed. Without that, a multi-agent incident is unreconstructable. See audit trail.
Notice that none of these controls live inside an agent prompt. That is deliberate. Anything you enforce with instructions can be argued away by the next model update or the next injected paragraph, and in a fleet you would have to get it right in every agent simultaneously. Enforcement belongs at the boundary, in one place, where it applies to every agent by default. For the broader architecture, see agentic AI security and enterprise AI agent security.
A2A and MCP: what the protocols secure and what they leave to you
Two protocols now carry most multi-agent traffic. Google published Agent2Agent (A2A) in 2025 and donated it to the Linux Foundation, and it standardizes how agents discover each other and delegate tasks. Anthropic Model Context Protocol (MCP) standardizes how an agent connects to tools and data. Both are genuinely useful, and neither is a security layer. It is worth being precise about the line, because plenty of teams assume the protocol handled it.
| Question | A2A or MCP answer | Who has to answer it |
|---|---|---|
| How do agents describe capabilities? | Agent Cards and tool manifests | Protocol |
| How does a task get delegated? | Standard task and message flow | Protocol |
| Which auth schemes are supported? | Declared in the Agent Card | Protocol |
| Is this Agent Card authentic? | Not mandated by the spec | You |
| Should this agent be allowed to call that tool right now? | Out of scope | You |
| Is the incoming message a prompt injection? | Out of scope | You |
| Does this delegated task exceed the requester authority? | Out of scope | You |
| What is the immutable record of the chain? | Out of scope | You |
The Agent Card row is the sharp one. A2A lets an agent advertise its capabilities, skills, endpoint, and supported authentication schemes, but the spec does not mandate how a consumer verifies that the card is authentic. Without an added verification step, fake agent advertisement, card tampering, and replay are all straightforwardly available to an attacker who can reach your registry or your network path. MCP has a parallel gap on the tool side, which we cover in MCP server security and MCP tool poisoning.
The practical takeaway: adopt the protocols, then put an enforcement layer in front of them. Agentshield does not replace A2A or MCP. It is the place where the questions in the right-hand column get answered consistently, for every agent in the fleet, without each team reimplementing them.
Framework guardrails stop at the first handoff
This is the most concrete and most overlooked fact in multi-agent security, and it comes from a vendor's own documentation rather than from anyone selling against them. In the OpenAI Agents SDK, input guardrails "only run if the agent is the first agent." OpenAI states the rule directly: input guardrails run only for the first agent in the chain, and output guardrails run only for the agent that produces the final output.
Read that against how these systems actually grow. Version one is a single agent with an input guardrail, and it passes review. Version two adds a triage agent that hands off to a specialist. Version three adds a billing agent with a payments tool. The guardrail is still in the codebase, still passing its tests, and it has not inspected a single token since the first handoff. Nobody removed a control. The workflow grew past where the control applies, and no test fails when that happens.
The same SDK documents a second boundary in the same direction: tool guardrails apply only to tools built with the function_tool decorator, and explicitly do not cover handoffs or hosted tools such as WebSearchTool and CodeInterpreterTool. Those are precisely the tools that pull untrusted content into context and execute code, so the widest blast radius sits outside the wrapping mechanism.
| Framework | Coverage across a multi-agent workflow | What you have to build |
|---|---|---|
| OpenAI Agents SDK | Documented gap. Input guardrails scope to the first agent, output guardrails to the final one | Per-hop inspection, and coverage for hosted tools the decorator does not wrap |
| LangGraph | Whatever you wrote, per node. No built-in notion of a workflow-wide policy | Essentially all of it, consistently, in every node any engineer adds later |
| Claude Code and Claude agents | Controls apply per session rather than per workflow hop. Strong defaults, single-actor scope | Cross-agent policy, and coverage when one agent invokes another |
| CrewAI and similar orchestrators | Delegation is the core abstraction. Security of the delegation is left to the application | Authority propagation rules and an independent record of who asked for what |
| A2A protocol | Standardizes discovery and delegation. Does not mandate how a consumer verifies an Agent Card | Card verification, plus every authorization decision in the chain |
The pattern across every row is that in-process controls are written per agent by the developer building that agent, while the risk is a property of the chain. An enforcement point outside the processes is the only place a policy can apply to hop three when hop one was written by a different team last quarter. The framework-specific detail is on OpenAI agent security, Claude agent security and LangChain security.
How do you secure AI agent orchestration?
Securing orchestration means putting the authorization decision somewhere other than inside the agent doing the work. Four controls carry most of the weight, and they are worth implementing in this order.
- Give every agent its own identity. Orchestrated systems that share one service account cannot answer the only question that matters during an incident, which is which agent asked. Identity is the prerequisite for the other three controls, not an optional refinement. See AI agent identity.
- Propagate the requester authority, not the executor authority. When a low-privilege agent delegates to a high-privilege one, the task must run with the narrower of the two, otherwise delegation becomes a privilege escalation primitive. This is the confused deputy problem and it is the single most common orchestration flaw.
- Inspect content at every hop. An instruction embedded in a document that entered at hop one is still an instruction at hop four, and by then it is arriving from a trusted internal peer rather than an external source. Trust between your own agents is exactly what an attacker is aiming for.
- Record the chain, not the calls. A log of individual tool calls does not reconstruct an incident in an orchestrated system. You need the delegation graph: which agent asked, on whose behalf, under what authority, and what was denied. See agent audit trail.
Teams often ask which of these the orchestration framework handles. In practice none of them, because a framework is built to make delegation easy rather than to constrain it, and constraining it is a policy question that belongs to you.
FAQ
Common questions about multi-agent system security.
Do OpenAI guardrails work across multi-agent handoffs?
No, and OpenAI documents this itself. Input guardrails run only for the first agent in the chain and output guardrails only for the agent producing the final output. In a handoff workflow, every agent after the first receives input that no input guardrail inspected. Tool guardrails also exclude handoffs and hosted tools such as WebSearchTool.
How do you secure AI agent orchestration?
Move the authorization decision outside the agent doing the work. Give each agent its own identity, propagate the requester authority rather than the executor authority so delegation cannot escalate privilege, inspect untrusted content at every hop rather than only at entry, and record the delegation graph so an incident can be reconstructed later.
What is the biggest security risk in a multi-agent system?
Implicit peer trust. Agents treat requests from other agents as trusted because they are internal, so an instruction injected at the edge travels inward and gains authority with every hop. Combined with a shared service account, it means a single compromised agent can act with the combined privilege of the whole fleet and leave no attributable trace.
What is multi-agent security?
Multi-agent security is the control of what happens between AI agents rather than inside a single one: which agent may delegate to which, what authority travels with a delegated task, what data crosses a trust boundary, and what prevents one compromised agent from cascading through the rest. It exists because individually safe agents can still form an unsafe system once they interact.
What are the security risks of multi-agent AI systems?
The distinctive risks are injection propagation down a delegation chain, privilege escalation through implicit peer trust, the confused deputy problem when a task runs with the executor authority instead of the requester authority, agent impersonation via unverified capability metadata, cross-boundary data leakage through shared context, cascading failures, recursive delegation loops, and attribution gaps that make incidents unreconstructable.
How is multi-agent security different from single-agent security?
Single-agent security asks whether one agent can be tricked into misusing its own tools. Multi-agent security asks what an agent inherits, passes on, and triggers in its peers. The failure modes are emergent, so per-agent testing misses them entirely: every agent can pass its own evaluation while the composition still routes an attacker to a privileged action.
Does the A2A protocol make multi-agent systems secure?
No. A2A standardizes discovery and delegation, and Agent Cards declare which authentication schemes an agent supports, but the spec does not mandate how a consumer verifies that a card is authentic. That leaves agent impersonation, card tampering, and replay to you, along with authorization, injection inspection, and audit. Treat A2A as plumbing and add an enforcement layer on top.
What is the confused deputy problem in multi-agent AI?
It happens when an agent with broad credentials performs an action on behalf of a caller that lacked the authority to request it. The executor is not compromised; it is simply doing what it was asked with the privileges it holds. The fix is to bind authority to the originating principal and re-check it at the tool call, so delegation can narrow permissions but never widen them.
How do you monitor a multi-agent system?
Log every hop keyed to the acting agent identity, the requesting agent, the policy verdict, and what data crossed the boundary, then alert on the multi-agent signals specifically: delegation depth spikes, an agent calling tools outside its normal set, and authority widening across a chain. Per-agent logs alone cannot reconstruct which hop caused an outcome.
More use cases