Splitting an AI agent into several agents can contain a compromise or multiply it, and the difference comes down to whether each new agent gets its own identity, its own narrower permissions and a validated channel, or simply shares the original agent's credentials and context. Architecture guidance from the major agent platform providers converges on the same starting point: build one agent with tools first, and add agents only when one agent cannot reliably do the job. That advice is about reliability and cost; this guide adds the security view. It compares single-agent and multi-agent designs on threat model, blast radius, auditability and controls, gives decision criteria for when a split is justified on security grounds, and works through a scenario. It is for architects, AppSec and IAM teams reviewing agent designs; the protocol and delegation detail lives in the Multi-Agent and A2A Security Guide, which this page links rather than repeats.
Key takeaways
- A single agent is one blast radius. Every tool, credential and piece of untrusted content meets in one context window, so one successful prompt injection can use everything the agent holds.
- Multiple agents only reduce blast radius when privileges actually differ. Five agents sharing one service account and one memory store are one agent with more attack surface and worse logs.
- Splitting adds new attack paths. Cross-agent prompt injection, delegation chain abuse and spoofed inter-agent messages do not exist in a single-agent design; each hop needs authentication, validation and attenuated credentials.
- The strongest security reason to split is separating untrusted input from privileged action. An agent that reads outsider content should not also hold write or send permissions on sensitive systems.
- Auditability usually gets harder, not easier. A multi-agent trace must reconstruct who asked whom to do what on whose behalf; without propagated identity and trace context, accountability is lost at the first hop.
The short answer
Default to a single agent with tools, least-privilege tool scopes and deterministic authorisation at the tool boundary. Split into multiple agents when at least one of these is true: the task mixes untrusted input with privileged actions that cannot be gated another way; different steps need permissions that should never coexist in one identity (segregation of duties); different steps fall under different data classifications, tenants or organisations; or one agent's tool set has grown so large and overlapping that it selects the wrong tool. When you split, give each agent its own workload identity, the minimum tools for its role, a narrowed token for each delegated task and a typed, validated message contract. If you cannot fund those controls, a single, well-constrained agent is the safer design.
Side by side
| Dimension | Single agent with tools | Multi-agent system |
|---|---|---|
| Trust boundaries | One: between the agent and its tools | One per agent plus one per inter-agent channel |
| Identity | One agent identity (often acting for a user) | One identity per agent, plus the user's delegated authority carried across hops |
| Blast radius of a hijacked context | Every tool and credential the agent holds | That agent's tools, plus whatever it can induce other agents to do |
| Privilege separation | Only through tool scoping and per-call policy | Structural, if agents really hold different permissions |
| New attack classes | None beyond tool misuse and injection | Cross-agent injection, delegation abuse, message spoofing and replay, cascading failure |
| Auditability | One linear trace | Distributed trace; needs propagated trace and identity context |
| Cost and latency | Lower and more predictable | Higher; one provider reports multi-agent research runs using about 15 times the tokens of a chat |
| Typical failure | One poisoned input steers a powerful agent | Errors and injected instructions propagate and amplify between agents |
What the platform guidance says
Providers are listed alphabetically; the guidance agrees more than it differs.
- Anthropic reports that its multi-agent research system outperformed a single agent by 90.2 percent on an internal research evaluation, at roughly 15 times the token use of a chat, and describes multi-agent designs as a poor fit for tasks that need shared context or have many dependencies between agents, such as most coding tasks. Early versions spawned 50 subagents for simple queries and duplicated work when instructions were vague.
- Google Agent Development Kit documentation describes a coordinator agent working with specified sub-agents and notes that a multi-agent structure helps by limiting data contexts for given tasks.
- Microsoft Azure Architecture Center guidance says to use the lowest level of complexity that reliably meets requirements, calls a single agent with tools "often the right default for enterprise use cases", and lists security requirements among the valid reasons to split. It asks that agents be as isolated as practical, that security trimming happen in every agent, and that guardrails apply to tool calls, tool responses and intermediate agent output, not only to user input.
- OpenAI recommends maximising a single agent's capabilities first and splitting only for complex conditional logic or tool overload, noting the problem is tool similarity and overlap more than raw tool count. It describes a manager pattern (agents as tools) and a decentralised hand-off pattern.
Academic work supports the caution. The MAST study of multi-agent LLM systems analysed traces from seven frameworks, catalogued 14 failure modes across system design, inter-agent misalignment and task verification, and found that multi-agent systems often yield only minimal gains on popular benchmarks.
Single agent in depth
Threat model
A single agent is a confused deputy waiting for instructions. OWASP's LLM06:2025 Excessive Agency names three root causes, excessive functionality, excessive permissions and excessive autonomy, and all three concentrate in one place when one agent does everything. The dangerous combination is an agent that reads content an outsider controls, has access to private data, and can write or send somewhere the outsider can see. The Gemini AI Calendar Prompt Injection shows the pattern: instructions hidden in a calendar invite were followed when the user asked a routine question, and the assistant used its delegated read access and its event-creation tool to summarise private meetings into a new event. Read, untrusted input and write all lived in one agent. See the Confused Deputy in AI Agents Guide.
Architecture in words
One model loop holds the system prompt, the user's request, tool definitions and every tool result. It calls tools through a gateway or SDK using either its own workload identity or a token delegated by the user. Authorisation, if it exists outside the model, sits at the tool boundary.
Failure modes
- Tool sprawl: tools added for convenience and never removed, so the agent can delete when it only needs to read.
- Standing broad token: the agent holds one long-lived credential covering every tool, so any steered call succeeds.
- Policy in the prompt: "never send email to external domains" written as an instruction rather than enforced at the tool.
- Context overload: a long, branching system prompt that the model follows inconsistently, which is a reliability problem that becomes a security problem when rules are skipped.
Controls
- Least functionality: only the tools the role needs, read-only variants by default.
- Per-call authorisation: a deterministic policy decision on every tool call using the final argument values, outside the model.
- Short-lived, task-scoped tokens: issued per session or per task rather than a standing secret.
- Control-flow constraints: fixing the plan before untrusted data is read, as described in Plan-Then-Execute vs ReAct.
- Approval for irreversible actions and iteration limits to stop tool-call loops.
Multi-agent in depth
Threat model
| Threat | How it happens | Primary control |
|---|---|---|
| Cross-agent prompt injection | A worker that read poisoned content returns output containing instructions, which the orchestrator or next agent obeys | Treat every agent's output as untrusted data; typed schemas; no free-text instructions across trust levels |
| Delegation chain abuse | A low-privilege agent asks a higher-privilege agent to act for it, or a token is passed unchanged down several hops | Attenuate authority at each hop; the callee authorises the original principal, not just the caller |
| Shared credentials | All agents run under one service account or API key, so compromise of any one equals compromise of all | Distinct workload identity per agent; no shared secrets |
| Message spoofing or replay | An attacker or rogue agent forges or replays inter-agent messages | Mutual authentication, signed or sender-constrained messages, nonces and expiry |
| Shared memory poisoning | One agent writes poisoned content to a memory or vector store other agents read | Per-agent write scopes; provenance on memory entries |
| Cascading failure | One bad output is amplified through pipelines, loops or fan-out | Validation between stages, iteration caps, circuit breakers, per-agent kill switch |
These map to the OWASP Top 10 for Agentic Applications: ASI03 Identity and Privilege Abuse, ASI07 Insecure Inter-Agent Communication and ASI08 Cascading Failures. OWASP's LLM06 entry also lists "a malicious/compromised peer agent" in multi-agent systems as a trigger for excessive agency.
Architecture in words
A secure split has a coordinator (orchestrator or manager agent) that holds no write permissions of its own and plans the task; workers that each hold one narrow capability under their own identity; a broker that exchanges the user's token for a narrower token per worker per task; and a message contract with fixed fields so a worker's result can carry data but not new instructions. Workers that touch untrusted content return structured results and hold no privileged tools. How the agents coordinate (central orchestrator or event-driven choreography) is a second decision covered in Agent Orchestration vs Choreography.
Failure modes
- Cosmetic split: separate prompts, same process, same credentials, same memory. No security gain, more surface.
- Privileged orchestrator: the coordinator holds every worker's permissions "for convenience", recreating the single-agent blast radius at the most exposed point.
- Free-text hand-offs: agents pass natural-language summaries, so injected instructions survive the hop.
- Token pass-through: the user's full token reaches every worker; see Delegation Chains and Attenuated Authority for AI Agents.
- Runaway fan-out: no cap on sub-agents, retries or loops, causing cost blow-outs and unpredictable behaviour.
Controls
- Per-agent identity: each agent is a registered non-human identity with an owner, authenticated with workload credentials. See the Agent-to-Agent Authentication Guide.
- Scoped tokens per hop: OAuth 2.0 Token Exchange (RFC 8693) or an equivalent broker issues audience-restricted, short-lived tokens carrying the original user as subject and the calling agent as actor. See the OAuth Token Exchange and Delegation Guide.
- Message validation: schema validation and policy checks on every inter-agent message; see Structured Outputs vs Free Text for Agent Actions.
- Isolation: separate runtimes, memory namespaces and network egress rules per agent.
- Containment: iteration and fan-out caps, circuit breakers and a kill switch per agent; see the AI Agent Kill Switch and Containment Guide.
Decision criteria: when to split
| Question | If yes | If no |
|---|---|---|
| Does the task read outsider-controlled content and also need write, send or pay actions on sensitive systems? | Split: a reader with no privileged tools, an actor that never sees raw untrusted text | A single agent with read-only tools may be enough |
| Would one identity need permissions that segregation of duties forbids together (request and approve, create and pay)? | Split, with distinct identities and an independent approval step | No SoD driver |
| Do steps cross data classifications, tenants or organisations? | Split along the boundary, with a contract at the crossing | Keep one agent |
| Is the agent choosing the wrong tool among many overlapping tools after tool descriptions were improved? | Split by domain | Keep one agent |
| Can you give every agent its own identity, scoped tokens and validated messages? | Splitting can deliver its security value | Do not split yet; a constrained single agent is safer than an unconstrained multi-agent system |
| Do you need one accountable, replayable record of every decision? | Favour one agent, or a coordinator that records the plan centrally | Either |
Small teams: one agent, tight tool scopes and an approval gate usually beat a multi-agent design they cannot instrument. Large organisations: split along existing trust boundaries (business units, data classes, partners) and reuse the identity, token exchange and policy platforms already run for microservices. The segregation of duties angle is developed in Segregation of Duties vs Least Privilege.
Worked scenario
A finance team wants an agent that reads supplier emails, matches invoices to purchase orders and schedules payments.
- Single-agent draft: one agent with mailbox read, ERP read and write, and payment scheduling. A crafted supplier email could instruct it to change bank details and schedule payment: untrusted input and the most sensitive action meet in one context.
- Split on the trust boundary: an intake agent reads email and attachments and outputs a fixed schema (supplier ID, invoice number, amount, currency, bank details as data). It has no ERP write or payment tools.
- Matching agent: reads the schema and ERP records, flags mismatches, and has read-only ERP access under its own identity.
- Payment agent: receives only matched records, can schedule but not approve, and treats any bank detail change as a hold requiring a human call-back.
- Tokens: each agent gets a short-lived token from the broker scoped to its task; the user's authority appears as subject, the agent as actor.
- Evidence: a shared trace ID and per-agent identity on every log line let auditors reconstruct each payment from email to schedule.
The same injected email now produces, at worst, a wrong field in a schema that the matching agent flags, and a bank change that stops at a human.
How to implement
- Threat model the single-agent version first. List tools, credentials and untrusted inputs; mark where they meet. Use the AI Agent Threat Modelling Guide.
- Constrain before splitting. Remove unneeded tools, move policy to the tool boundary, add approvals. Re-assess whether a split is still needed.
- Split along one boundary. Usually untrusted input versus privileged action. Register each new agent as an identity with an owner.
- Define contracts. Typed message schemas, allowed senders and receivers, maximum hops and fan-out.
- Pilot in shadow mode. Run the multi-agent version alongside the single agent with actions disabled; compare outputs, costs and traces.
- Red-team the hops. Inject instructions into each worker's inputs and confirm they cannot reach a privileged action.
- Roll back cleanly. Keep the constrained single agent deployable behind a feature flag until the split has run without incident for an agreed period.
Detection and measurement
Log, per agent call: agent identity, on-behalf-of principal, trace and parent span IDs, tool and arguments, policy decision and token audience. The Agent Observability vs Audit Logging comparison explains which records serve security and which serve debugging.
| Metric | What it shows |
|---|---|
| Agents sharing a credential with another agent | Cosmetic splits; target zero |
| Inter-agent messages failing schema validation | Injection attempts or drift; investigate spikes |
| Tool calls denied by policy, per agent | Agents being steered beyond their role |
| Actions traceable end to end to a human principal | Auditability; target 100 percent for write actions |
| Average and maximum delegation depth and fan-out | Runaway coordination and cost risk |
| Privileged tools reachable from agents that read untrusted content | Residual blast radius; target zero |
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-5 Separation of Duties; AC-6 Least Privilege; AC-4 Information Flow Enforcement; IA-9 Service Identification and Authentication; AU-10 Non-repudiation | Distinct agent identities, narrow permissions, controlled flows between agents, attributable actions |
| NIST CSF 2.0 | PR.AA-05; DE.CM-09 | Least privilege and SoD in policy; monitoring runtime environments |
| OWASP Top 10 for LLM Applications 2025 | LLM01 Prompt Injection; LLM06 Excessive Agency | Injection reaching tools; functionality, permissions and autonomy |
| OWASP Top 10 for Agentic Applications | ASI03; ASI07; ASI08 | Delegation abuse, inter-agent channel security, cascades |
Common failure patterns
- Splitting for fashion. Adding agents because a framework makes it easy, with no change in permissions, so cost and attack surface rise with no containment.
- Trusting "internal" agents. Accepting any message from inside the system, so one injected worker steers the rest.
- One shared memory for all agents. A single poisoned entry influences every agent; see the AI Agent Memory Security Guide.
- Losing the user at the second hop. Workers act under their own identity only, so data the user may not see is returned to them.
- No caps. Unbounded loops and fan-out turn a small error into an outage or a large bill.
Practitioner checklist
- Start with a single agent and document why each additional agent is needed.
- Never let one agent both read outsider-controlled content and hold privileged write, send or pay tools.
- Give every agent its own registered identity, owner and credential.
- Exchange tokens per hop with audience restriction and the user carried as subject.
- Pass typed, schema-validated messages between agents, never free-text instructions across trust levels.
- Isolate memory, runtime and egress per agent.
- Cap delegation depth, fan-out and iterations; add a kill switch per agent.
- Propagate trace and identity context so every action traces back to a human principal.
- Red-team each hop before enabling actions.
Standards and references
- OWASP GenAI Security Project: Top 10 for Agentic Applications
- OWASP: Top 10 for LLM Applications 2025 (LLM06 Excessive Agency)
- Microsoft Azure Architecture Center: AI agent orchestration patterns
- OpenAI: A practical guide to building agents
- Anthropic: How we built our multi-agent research system
- Google Agent Development Kit: Workflows
- Cemri et al.: Why Do Multi-Agent LLM Systems Fail? (arXiv 2503.13657)
- IETF RFC 8693: OAuth 2.0 Token Exchange
Related NHI Mgmt Group resources: Multi-Agent and A2A Security Guide, Agent Orchestration vs Choreography, Secure Agent Design Patterns Guide, OWASP Top 10 for Agentic Applications Guide.