In early 2025, a red team at a major financial services firm discovered that a compromised customer-facing agent could pass malicious instructions upstream to a privileged orchestration agent — one with write access to the firm's CRM and email systems. No external attacker was required. The breach path was entirely internal, agent to agent.
That incident isn't an edge case anymore. As multi-agent systems move from demos to production, the attack surface grows faster than most security teams expect. You're not just securing a single model; you're securing a distributed system where agents spawn subagents, share memory, call external tools, and act on each other's outputs.
This post covers the specific AI security controls that matter in multi-agent deployments — not the generic advice, but the practical steps that map to real threat vectors your team will encounter.
The Attack Surface Is Bigger Than You Think
In a single-agent setup, your security perimeter is relatively narrow: prompt inputs, tool permissions, and output filtering. Add a second agent and you double the trust relationships. Add an orchestrator coordinating five specialized agents and you have a mesh of inter-agent communication channels, each one a potential injection point.
Multi-agent systems introduce threats that single-agent security models don't account for: lateral movement between agents, trust elevation when a low-privilege agent passes instructions to a high-privilege one, and context poisoning where one agent's corrupted memory propagates through shared state.
Your threat model needs to cover all three layers: the human-to-agent interface, the agent-to-agent interface, and the agent-to-tool interface.
Prompt Injection Doesn't Stop at the User Input
Prompt injection is well-documented at the user boundary, but in multi-agent systems it travels. An agent scraping a web page can be fed adversarial content designed to alter the instructions it passes downstream. A summarization agent processing an email can be manipulated into issuing tool calls it was never intended to make.
This is called indirect prompt injection, and it's one of the harder problems in AI security today. The defense isn't a single filter — it's a combination of output validation, constrained output schemas, and treating every inter-agent message as untrusted input.
Practically: if your orchestrator receives a message from a subagent, parse and validate it against an expected schema before acting on it. Never pass raw agent output directly into another agent's system prompt without sanitization.
Agent Identity and the Privilege Problem
In most frameworks — LangGraph, CrewAI, AutoGen, OpenClaw — agents are distinguished by role and capability, but authentication between agents is often implicit. Agent A trusts Agent B because they're both in the same pipeline. That's not a security boundary; that's an assumption.
Implement explicit identity tokens for inter-agent communication. Even a simple HMAC-signed message header is better than nothing. Define which agents can issue instructions to which other agents and enforce that in your orchestration layer, not just in documentation.
The principle of least privilege applies here exactly as it does in traditional systems. A research agent that reads web pages should not have write access to your database, even if the orchestrator does. Scope tool permissions to the agent that needs them, not to the pipeline as a whole.
For a deeper look at how memory surfaces extend this problem, see Memory Safety in Multi-Agent Systems.
Common Mistakes
- Shared tool credentials across agents. When all agents in a pipeline use the same API key or database connection, a single compromised agent can act on behalf of the entire system. Scope credentials per agent role.
- Trusting agent output without validation. Passing raw LLM output from one agent directly into another agent's prompt creates an injection path. Parse and validate at every boundary.
- Logging only at the orchestrator level. Subagent behavior is invisible if you only log what the orchestrator sees. Capture every agent's inputs, outputs, and tool calls separately.
Sandboxing Tool Execution
Tools are where agents touch real systems — filesystems, APIs, databases, shell environments. They're also where the damage happens when something goes wrong.
Run tool execution in isolated environments. If an agent needs to run code, that code should execute in a container with no network access unless explicitly required, no write access outside a defined scratch directory, and a hard timeout. Frameworks like Letta and some AutoGen configurations support pluggable tool executors — use them to enforce boundaries rather than relying on the model to stay in scope.
For shell-capable agents like those built with Aider or Cline, treat every bash call as if a junior developer with root access wrote it. Review what commands your agent can invoke, restrict them to a whitelist if possible, and log every execution with its full context.
Securing the Memory Layer
Agent memory — short-term context, long-term vector stores, shared state — is an attack surface that often goes unexamined. An adversary who can write to an agent's memory store can influence future behavior without ever touching the prompt at inference time.
Segregate memory by agent role. A customer-facing agent's conversation history should not be readable by a privileged back-office agent unless there's a specific, audited reason for it. Apply the same read/write controls to your vector databases that you'd apply to any sensitive datastore.
Also consider memory poisoning via normal use: if users can cause an agent to store arbitrary information in long-term memory, they can plant instructions that activate later. Implement write-time filtering and periodic memory audits for production systems.
See Navigating AI Security Risks for a broader breakdown of how these memory vectors interact with enterprise compliance requirements.
Output Filtering and Exfiltration Controls
Agents that can send email, post to Slack, call webhooks, or write to external APIs are potential exfiltration vectors. An attacker who can manipulate an agent's output can use those outbound channels to extract data without ever touching your network boundary.
Implement output filtering on every outbound channel. This isn't just about blocking toxic content — it's about detecting anomalous data patterns in agent outputs. An agent that suddenly starts including base64-encoded strings in its Slack messages should trigger an alert.
For high-sensitivity environments, consider an allow-list approach: agents can only send data to pre-approved destinations, and any new destination requires an explicit policy update. This is operationally heavier but much easier to audit.
Security Guardrails
- Validate inter-agent messages against a schema. Treat messages from other agents as untrusted input. Define expected output formats and reject anything outside them before passing to the next stage.
- Scope API keys per agent, not per pipeline. Rotate credentials independently so a single compromised agent doesn't expose the full system.
- Log every tool call with its invoking agent's identity. You need a chain of custody for every action, not just the final outcome.
- Set hard token and time limits on subagent execution. Unbounded agents can be forced into expensive or dangerous loops by adversarial inputs. Cap both.
- Require human-in-the-loop approval for irreversible actions. File deletions, financial transactions, and external communications should pause for confirmation unless you've explicitly decided otherwise.
Monitoring and Anomaly Detection
The hardest part of AI security in multi-agent systems isn't prevention — it's detection. Agents that behave unexpectedly often look normal at the output level until you examine the chain of reasoning and tool calls that got them there.
Build monitoring into your orchestration layer from the start. Capture: the system prompt each agent received, every tool call and its parameters, every inter-agent message, and the final output. Store these logs in a tamper-evident format — append-only if possible.
Set behavioral baselines during testing and alert on deviations in production. An agent that normally calls three tools per task and suddenly calls fifteen is worth investigating, even if the final output looks clean. Many frameworks expose observability hooks; use them rather than bolting on logging after the fact.
For teams already running governance frameworks, Building Trust in AI Governance covers how audit trails connect to compliance workflows.
Supply Chain Risk in Agent Dependencies
Your agents are only as trustworthy as the tools, plugins, and MCP servers they connect to. The MCP server ecosystem is growing fast, and not every server in that ecosystem has been security-reviewed.
Before connecting an MCP server or third-party tool to your agent pipeline, ask: Who maintains it? What data does it access? What does it send upstream? For internal deployments, prefer self-hosted or reviewed servers over pulling community packages directly into production.
Pin versions of every tool integration. An auto-updating MCP server dependency is a supply chain risk — an update to a package you didn't review can change the behavior your agents rely on, or introduce a vulnerability you didn't test for.
Governance and the Human Approval Layer
Not every action should be autonomous. For multi-agent systems handling sensitive operations, define explicit categories of actions that require human approval before execution.
This isn't a failure of the agent design — it's a deliberate control. Document which agents can act autonomously, under what conditions, and what triggers a pause-for-review. Make that policy machine-readable where possible so it's enforced at runtime, not just in a runbook somewhere.
For regulated industries, this governance layer is also your audit trail. Regulators want to see that a human was in the loop for consequential decisions, even when AI handled the analysis. Build the approval workflow into the architecture, not as an afterthought.
For patterns specific to financial services deployments, AI Agent Governance in Financial Services is worth reading alongside this post.
Closing: Security Is Architecture, Not a Feature Flag
Most of the vulnerabilities in multi-agent systems today aren't zero-days — they're design decisions made without a threat model. Trust between agents was implicit. Tool permissions were copied from a tutorial. Logging was added after the first incident instead of before.
AI security in these systems is an architectural concern. The patterns in this post — least privilege, validated inter-agent communication, sandboxed tool execution, behavioral monitoring — need to be in your design from the start, not retrofitted when something breaks.
If you're building or auditing a multi-agent system now, start with a threat model. Map every agent, every trust relationship, and every external call. Then work through the controls above systematically.
Define Your Multi-Agent Trust Boundaries Before Someone Else Does
Use the OpenAgents.mom wizard to generate an agent configuration with least-privilege defaults, sandboxed tool scoping, and inter-agent permission boundaries built in from the first file.