The Anatomy of an Agentic Jailbreak: How Attackers Chain Vulnerabilities Across Multi-Agent Systems

A single-agent jailbreak is a containable problem. An attacker manipulates an AI assistant into generating prohibited content or bypassing guardrails, and the damage stays bounded to that one interaction. Uncomfortable, but manageable.

A multi-agent jailbreak is categorically different. When AI agents are orchestrated into workflows where each agent hands off context, instructions, and data to the next, a successful attack on one agent becomes an attack on the entire chain. The blast radius is not bounded by the compromised agent. It is bounded by the network of agents that agent can reach.

For CISOs, security architects, and AI engineering leads deploying agentic systems in production, this distinction matters. The security model that worked for single-agent deployments does not transfer to multi-agent architectures. Understanding exactly how these attack chains unfold is the first step toward building defenses that actually work.

Why Single-Agent Security Falls Short

Most organizations approach AI security by hardening individual agents. They implement content filters on inputs, guardrails on outputs, and monitoring on tool calls. Each agent gets tested in isolation, and when it passes, it gets deployed.

This approach assumes that security boundaries align with agent boundaries. In a multi-agent architecture, that assumption breaks down.

When agents are orchestrated into workflows, they communicate. An intake agent passes processed requests to a reasoning agent. The reasoning agent sends queries to a data access agent. The data access agent returns results to a communication agent. At each handoff, the receiving agent treats incoming context as legitimate because it came from a trusted internal source.

This trust relationship is exactly what attackers exploit. A compromised upstream agent does not need to exfiltrate data directly. It only needs to pass manipulated context downstream to an agent that can.

A Realistic Attack Chain: Five Steps to Data Exfiltration

To understand what security teams are actually defending against, consider this realistic attack scenario against a multi-agent customer service workflow.

Step 1: Bypassing the Intake Agent

The attacker crafts a support ticket that contains a prompt injection payload embedded in what appears to be a routine customer inquiry. The payload is designed to survive the intake agent’s content filter by using encoding techniques, context manipulation, or adversarial phrasing that does not trigger keyword-based detection.

The intake agent processes the ticket as legitimate and passes the full context downstream.

Step 2: Manipulating the Processing Agent

The processing agent receives what it perceives as a legitimate customer inquiry with additional context. The injected payload instructs the agent to retrieve specific customer records as part of resolving the ticket. Because the instruction arrived through an internal channel from a trusted agent, the processing agent treats it as a valid request.

The processing agent has database access. It executes the query.

Step 3: Accessing Sensitive Data

The database query returns sensitive customer information: payment details, account histories, personal identifiers. The processing agent packages this data as part of its response to the original ticket.

At this point, the attack has achieved data access. But the data is still inside the system. The attacker needs an exit path.

Step 4: Reaching the Communication Agent

The processing agent’s response flows to a communication agent responsible for sending customer replies via email or Slack. The communication agent receives the response, which now contains sensitive data embedded in what appears to be a standard customer service reply.

The communication agent has outbound access to approved channels. It is designed to send messages.

Step 5: Exfiltration Through Approved Channels

The communication agent sends the response through its normal workflow. The sensitive data exits the organization via email or Slack, delivered directly to an address controlled by the attacker or embedded in a reply they will receive.

Every tool call in this chain looks legitimate in isolation. The intake agent processed a ticket. The processing agent queried a database. The communication agent sent a message. No individual action violated policy in an obvious way. The attack succeeded through the combination.

Why This Chain Is Hard to Detect

Traditional security monitoring looks for policy violations at the action level. It flags prohibited queries, blocked content patterns, or unauthorized tool calls. In the attack chain above, none of those triggers fire.

The intake agent’s content filter saw encoded text, not obvious malicious content. The processing agent’s database query matched the pattern of legitimate customer service operations. The communication agent’s outbound message used an approved channel for an approved purpose.

The malicious intent exists only in the relationship between the steps. Detecting it requires understanding the full workflow context, not just individual actions.

This is why runtime security that inspects every action at execution time is essential for multi-agent deployments. Security filters that only check outputs miss attacks that construct themselves across agent boundaries.

Indirect Prompt Injection: The Attack Does Not Have to Start with a User

The attack chain above began with a crafted support ticket. But multi-agent systems face an even broader threat surface through indirect prompt injection.

The malicious payload does not have to arrive through user input. It can be embedded in any content that an agent will process:

• A document uploaded to a shared drive that a research agent will summarize
• An email in an inbox that an assistant agent will read
• A database record that a retrieval agent will fetch
• A tool response from an external API that an orchestration agent will parse

Any data source that feeds into the multi-agent workflow is a potential injection point. The attacker does not need direct access to the system. They only need to place a payload somewhere an agent will encounter it.

This means the attack surface for multi-agent systems extends to every connected data source, every integrated tool, and every external system that provides context to any agent in the workflow.

What the Security Architecture Must Defend Against

Defending multi-agent workflows requires a fundamental shift in security architecture. Perimeter-based defenses that only validate inputs and outputs at the system edge leave the interior unprotected.

The architecture needs policy enforcement at each agent boundary. When Agent A passes context to Agent B, that handoff must be inspected. Constraints must limit what downstream agents can receive from upstream agents, regardless of the trust relationship between them.

This means implementing:

• Input validation at every agent, not just the intake layer
• Output constraints that limit what data each agent can pass downstream
• Tool call authorization that considers workflow context, not just individual permissions
• Data flow policies that restrict sensitive information from reaching agents with external access

Airia’s approach to enforcing AI agents addresses this directly by stopping unauthorized agent actions at the execution layer. Policy enforcement happens before the tool call fires, before the email sends, before the database query runs. This boundary-level enforcement is what prevents attack chains from propagating across agent networks.

The Governance Implication: Red Team the Workflow, Not Just the Agents

Security testing for multi-agent systems cannot stop at individual agent evaluation. An agent that passes all its unit tests can still be the weak link in an attack chain that compromises the entire workflow.

Organizations running multi-agent workflows need to red team the workflow as a system. This means:

• Testing whether attack chains can be constructed across the architecture
• Evaluating how injected payloads propagate through agent handoffs
• Assessing whether data exfiltration paths exist through combinations of legitimate tool calls
• Validating that boundary constraints actually prevent malicious context from flowing downstream

Airia’s governance and compliance capabilities support this by providing a complete inventory of every agent, model, and tool in use. When you can see the full workflow topology, you can test it as an integrated system rather than a collection of isolated components.

Building Defenses That Match the Threat

The shift to multi-agent architectures delivers real business value. Workflows that combine specialized agents can handle complex tasks that single agents cannot. But this architectural pattern also creates security challenges that single-agent defenses were never designed to address.

Security teams defending multi-agent deployments need to think in terms of attack chains, not individual exploits. The question is not whether each agent is secure in isolation. The question is whether an attacker can construct a path through the agent network that achieves their objective while making every individual step look legitimate.

Answering that question requires visibility into the full workflow, policy enforcement at every boundary, and testing that evaluates the system as a whole. The organizations that build these capabilities into their multi-agent architectures from the start will be the ones that can deploy agentic AI with confidence.

Protect your agentic workflows with security that works at every boundary. Discover what Airia can do for your organization.