OWASP ASI07 Explained: Insecure Inter-Agent Communication

TL;DR

OWASP ASI07 ("Insecure Inter-Agent Communication") covers the class of failures where one AI agent consumes instructions, tool outputs, or authority assertions from another agent without enough provenance, validation, or privilege separation.
In practice, ASI07 is what happens when a system treats "message from another agent" as a trusted channel instead of an untrusted input crossing a trust boundary.
The main failure patterns are: instruction relay (one agent forwards attacker-controlled text to another), authority confusion (a receiving agent over-trusts the sender's identity or permissions), and unsafe action chaining (low-trust agent output automatically drives a higher-privilege tool or worker).
ASI07 rarely appears alone. It usually combines with agent goal hijack (ASI01), often via indirect prompt injection, plus tool misuse (ASI02), privilege failures (ASI03), or cross-tool chaining that ends in execution (ASI05).
The operational fix is simple to state and hard to implement: treat every agent-to-agent message as untrusted data unless the runtime can prove provenance, preserve scope, and require confirmation before privileged actions.

What ASI07 actually says

OWASP ASI07 names the security problem that appears once AI systems stop being a single chatbot and start acting as agent networks. A planner agent calls a researcher agent. The researcher calls a browser tool. A wallet agent receives a proposed transaction from a strategist agent. A coding agent receives a diff from a review agent. A routing agent forwards tool output to a specialist worker.

Every one of those hops is a security boundary, even if the product team does not model it that way.

The mistake behind ASI07 is assuming that because both endpoints are "our agents," the communication between them is trustworthy by default. It is not. The sending agent may be compromised by prompt injection, poisoned tool output, stale memory, or a malicious connector. The receiving agent may misinterpret the sender's output as authoritative instructions rather than untrusted context. And once multiple workers can trigger each other automatically, a single poisoned message can propagate through the whole graph.

That is why ASI07 matters: inter-agent communication multiplies the blast radius of every earlier compromise.

The three core ASI07 failure modes

1. Instruction relay

A low-trust or attacker-influenced agent emits text that gets passed to another agent as if it were safe context. The receiver reads the text, and the LLM treats it partly as data and partly as instruction.

This is the multi-agent version of indirect prompt injection. The first agent becomes a laundering layer. Instead of the attacker speaking directly to the privileged agent, the attacker influences a weaker agent upstream and lets normal orchestration move the payload downstream.

Example pattern:

A retrieval agent reads an issue, email, web page, or support ticket.
The retrieved content contains adversarial instructions.
The retrieval agent summarizes or forwards that content to an execution-capable agent.
The execution-capable agent treats the forwarded text as part of its working instructions.

The receiving agent often loses the provenance metadata that would have revealed the text originated from untrusted external content.

2. Authority confusion

The receiving agent assumes the sender already performed the required checks. "If the planner sent this, it must be approved." "If the wallet agent got this request from the strategy agent, it must be intended." "If the code-review worker says apply the patch, go ahead."

This is a classic confused-deputy shape, except the deputy is another AI component. The sender's identity is mistaken for the sender's legitimacy. In secure systems, identity alone is never enough; scope and authorisation must travel with the request.

When they do not, the receiving agent upgrades the sender's output into stronger authority than it actually has.

3. Unsafe action chaining

A worker with low trust or weak validation produces output that automatically triggers a higher-privilege step: sending email, writing files, deploying code, signing transactions, changing firewall rules, or running shell commands.

The danger is not only one malicious message. The danger is automation without friction. A multi-agent pipeline can convert a cheap upstream manipulation into an expensive downstream action in seconds.

In audit terms, this is the inter-agent version of cross-tool chaining: each hop looks reasonable in isolation, but the composed workflow crosses from untrusted content to privileged action without a checkpoint.

How ASI07 differs from adjacent OWASP items

ASI07 overlaps heavily with other OWASP agentic risks, so the clean distinction matters.

ASI01 (Agent Goal Hijack) is about changing what an agent wants to do. ASI07 is about how that compromised intent or content moves between agents.
ASI02 (Tool Misuse) is about an agent misusing an available tool. ASI07 is about one agent causing another to act, often across different permission scopes.
ASI03 (Identity and Privilege Abuse) is about the agent having too much authority or using identity unsafely. ASI07 is about unsafe handoff of requests and assumptions between agents that do not share the same privilege model.
ASI05 (Unexpected Code Execution) becomes relevant when an inter-agent chain eventually reaches an exec primitive. In that case ASI07 is the propagation layer; ASI05 is the final impact.

In practice, many findings should be mapped to ASI07 + one downstream item rather than forced into a single bucket.

What insecure inter-agent communication looks like in production

The easiest way to spot ASI07 is to ask a simple question:

If a lower-trust agent says something false, dangerous, or attacker-influenced, what stops the next agent from acting on it?

If the answer is "the next agent will probably notice," that is not a control.

Common production patterns include:

A research worker browsing public sources and handing a "recommended action" directly to an operations worker.
A support triage agent forwarding user-written summaries into an admin-capable internal assistant.
An MCP host orchestrating multiple specialist agents where tool outputs are flattened into plain text before being passed along.
A coding agent receiving patch instructions from another worker without preserving source provenance, risk level, or whether the content originated from an untrusted repository issue.
A trading or treasury workflow where a strategist agent proposes a transaction and a wallet-connected executor signs or stages it without an explicit human checkpoint.

Each pattern shares the same structural flaw: message passing is treated as collaboration, not as an adversarial interface.

Why multi-agent systems amplify risk

Three properties make ASI07 especially dangerous.

More hops means more trust assumptions

A single-agent system has one prompt-construction pipeline to harden. A multi-agent system has many. Every new worker adds another place where provenance can be stripped, sanitisation can fail, or permissions can be widened by convenience.

Context gets rewritten at every step

Agent frameworks routinely summarize, compress, or restate messages between workers to save tokens. That helps cost and latency, but it destroys evidence about where the content came from. By the time a privileged agent sees the message, it may look like a clean internal instruction instead of an external adversarial payload.

Privilege boundaries become conceptual instead of technical

Teams often say things like "the planner is low risk" or "the reviewer can't do anything on its own." But if a low-risk worker can still trigger a higher-risk worker automatically, then the real permission boundary is not technical — it is merely conventional. Attackers love conventional boundaries.

A practical ASI07 threat scenario

Consider a common development workflow:

1GitHub issue -> triage agent -> planning agent -> coding agent -> terminal / git tools

Now add one malicious issue comment.

The attacker posts a comment containing hidden prompt-injection instructions.
The triage agent reads the issue and produces a "clean summary" for the planner.
The planner forwards a task list to the coding agent, including attacker-influenced priorities or hidden directives.
The coding agent writes files or executes tool calls because it believes the task originated from the internal planner.
The host logs only the final tool action, not the original source of the malicious instruction.

Nothing in that chain requires the attacker to compromise the privileged coding agent directly. The weak link is the trust relationship between agents.

The same pattern appears in wallet-enabled systems:

1market-monitor agent -> strategy agent -> transaction-builder agent -> signer

If upstream content can bias the strategist and downstream checkpoints are weak, ASI07 turns one manipulated market signal into a real onchain action.

Detection and mitigation

Defending against ASI07 requires protocol design, not just better prompting.

1. Preserve provenance across every hop

Get funded for your audit

Core grants cover up to $32k. Growth and Builder tiers available. Rolling applications.

No spam. Unsubscribe anytime.

Every inter-agent message should carry structured metadata: source channel, original trust level, whether the content was user-supplied or externally retrieved, which sanitisation stages ran, and whether any human approved it.

If a receiving agent sees text without provenance, it should treat it as untrusted by default.

2. Separate data from instructions

Do not forward raw free-form text from one agent into another agent's instruction slot. Pass external content as structured data fields. Reserve instruction channels for the orchestrator or approved human operator.

This is the same principle as instruction hierarchy, applied across multiple agents instead of one.

3. Enforce scope inheritance

A lower-trust worker must never expand its privileges by asking a higher-privilege worker to act on its behalf. The request should inherit the sender's trust level and authorisation limits unless an explicit policy or human approval upgrades it.

The key invariant: message routing must not be a privilege-escalation mechanism.

4. Require checkpoints before high-impact actions

Any inter-agent chain that reaches code execution, credential use, production changes, or transaction signing should require a review step that surfaces:

who originated the request,
what untrusted inputs influenced it,
what exact action will happen next,
and what authority the destination agent will exercise.

This matters most for Web3 teams. If the last step can move assets, publish contracts, rotate keys, or alter infrastructure, treat every upstream agent message as potentially attacker-shaped until proven otherwise.

5. Audit compositions, not components

Teams often review each agent in isolation. ASI07 lives in the seams. Audit the actual workflow graph: which agent can talk to which, what fields are passed, what metadata is lost, and which downstream actions can be triggered automatically.

A component that is harmless alone may be dangerous in sequence.

How Zealynx audits for ASI07

A Zealynx MCP Security Audit treats ASI07 as a workflow-integrity problem. The five focused tests are:

Agent graph enumeration. Map every agent, worker, planner, and tool-mediated relay path in the deployment.
Provenance-retention review. Verify whether source trust metadata survives every hop or gets flattened into plain text.
Privilege-propagation test. Check whether lower-trust agents can trigger higher-privilege actions indirectly.
Prompt-boundary testing. Inject adversarial content upstream and measure whether downstream workers reinterpret it as instructions.
High-impact checkpoint verification. Confirm that code execution, transaction signing, credential use, and production changes require explicit review with full source context.

Findings typically map to ASI07 plus ASI01, ASI03, or ASI05 depending on the downstream impact.

Conclusion

OWASP ASI07 is the risk category that appears when teams move from "an AI assistant" to an AI system of cooperating workers without redesigning trust. The more agents you add, the more tempting it becomes to treat internal messages as safe shortcuts. That convenience is exactly what attackers exploit.

The right mental model is not "our agents are talking to each other." It is: untrusted content is crossing multiple boundaries and may be gaining authority at every hop.

If your agent stack can browse, code, deploy, email, sign, or administer anything important, inter-agent communication deserves the same threat modelling discipline as any other privileged protocol.

If you want a concrete review of agent orchestration, MCP connectors, tool authority, and high-risk action paths before they become incidents, Zealynx can help with an MCP Security Audit.

FAQ

1. What is OWASP ASI07 in one sentence?

OWASP ASI07 (Insecure Inter-Agent Communication) covers attacks where one AI agent consumes instructions, summaries, or authority claims from another agent without enough provenance, validation, or privilege separation, allowing attacker-influenced content to propagate across a multi-agent system.

2. How is ASI07 different from prompt injection?

Prompt injection explains how adversarial instructions first enter the system, usually through direct or indirect prompt injection. ASI07 explains how that compromised content then moves between agents. In many real deployments, ASI01 is the entry point and ASI07 is the propagation mechanism.

3. Why are multi-agent systems riskier than a single agent?

Multi-agent systems add more hops, more summarisation layers, and more chances to lose provenance metadata. They also create soft privilege boundaries where a lower-trust worker can influence a higher-privilege worker indirectly. That makes compromise easier to propagate and harder to trace.

4. Can inter-agent communication lead to wallet or transaction risk?

Yes. If a strategist, monitor, or research agent can influence a transaction-building or signing flow, insecure inter-agent communication can turn manipulated upstream content into a real asset movement. For Web3 systems, every path that ends in wallet authority needs explicit checkpoints and preserved source context.

5. What is the main engineering control for ASI07?

The main control is preserving trust metadata and scope across every hop. A receiving agent should know where the message came from, whether it originated from an untrusted source, what sanitisation ran, and whether the sender had authority to request the downstream action. Without that, message passing becomes implicit privilege escalation.

6. How do I test for ASI07 in my own agent stack?

Map the full workflow graph, inject adversarial content into upstream low-trust agents, and observe whether downstream workers reinterpret the content as instructions or execute high-impact actions without review. Test the compositions, not just the individual components.

7. Does MCP automatically solve ASI07?

No. Model Context Protocol standardises how tools and hosts exchange context, but it does not guarantee safe trust propagation between multiple agents, workers, or tool-mediated relays. Security still depends on provenance, policy enforcement, and least privilege at the host level.

8. How does Zealynx audit for insecure inter-agent communication?

Zealynx audits ASI07 by mapping the agent graph, checking whether provenance survives each hop, testing whether low-trust workers can trigger higher-privilege actions, injecting adversarial upstream content, and verifying explicit checkpoints before code execution, transaction signing, or production changes.

Glossary

Term	Definition
Trust Boundary	A point where data or control crosses from one security domain to another. In multi-agent systems, every message between workers should be treated as crossing a trust boundary unless proven otherwise.
Indirect Prompt Injection	An attack where adversarial instructions are embedded in content the AI agent reads as part of task execution rather than in a direct user message. A common entry point for ASI07 propagation.
Cross-Tool Chaining	A security pattern where individually-allowed capabilities become dangerous when composed together. ASI07 often uses inter-agent relays to create the same effect across workers.
MCP Host	The runtime that connects models to tools and coordinates context exchange. In multi-agent deployments, the host is responsible for preserving provenance and enforcing policy between components.
Instruction Hierarchy	The practice of separating privileged instructions from untrusted data channels. For ASI07, the same discipline must apply not only inside one agent but across the entire agent graph.

View complete glossary →

Get funded for your audit

Core grants cover up to $32k. Growth and Builder tiers available. Rolling applications.

No spam. Unsubscribe anytime.