OWASP ASI07 Insecure Inter-Agent Communication

When agents talk to other agents, every message is an instruction, and an instruction nobody authenticated is an attack surface. ASI07 Insecure Inter-Agent Communication is the seventh entry in the OWASP Top 10 for Agentic Applications for 2026, published by the OWASP GenAI Security Project on 9 December 2025. It covers what happens when messages between agents, coordinators, tool servers and registries can be intercepted, altered, spoofed, replayed or blocked. This guide goes deeper than our overview of the list: what OWASP includes and excludes, the controls mapped to the A2A and MCP specifications, the identity requirements for each agent on the wire, how to test and evidence the controls, and how the entry maps to other frameworks. It is written for security architects, platform engineers and AppSec teams running multi-agent systems. For all ten entries, see the OWASP Top 10 for Agentic Applications Guide.

Key takeaways

ASI07 is about live messages, not stored data or stolen permissions. OWASP separates it from ASI03 Identity and Privilege Abuse (credential and permission misuse) and ASI06 Memory and Context Poisoning (corruption of stored knowledge): ASI07 is the compromise of messages in flight between agents.
Four layers, not one. The entry spans transport, routing, discovery and the semantic layer, so TLS alone does not close it: a perfectly encrypted message can still carry a forged agent card, a replayed delegation or an instruction two agents read differently.
Every agent needs its own identity on the wire. Per-agent credentials, mutual authentication and protocol authentication bound to that identity are OWASP's first mitigation, and they depend on non-human identity hygiene: no shared keys, no long-lived tokens, fast revocation.
The specifications give you the hooks. A2A 1.0 requires TLS in production, defines signed Agent Cards (JWS over RFC 8785 canonical JSON) and per-request authentication; MCP requires audience-bound tokens and forbids token passthrough. Most ASI07 failures are these features left off.
Discovery is the soft underbelly. Research such as the Agent-in-the-Middle proof of concept shows that if an orchestrator chooses peers from self-published descriptions, a malicious agent can win the routing decision without breaking any cryptography.

What it is and who it applies to

OWASP describes multi-agent systems as depending on continuous communication over APIs, message buses and shared memory, with decentralised design and uneven trust between participants. When authentication, integrity, confidentiality or authorisation on those channels is weak, an attacker can intercept, alter, spoof or block agent messages. The entry explicitly includes covert channels, where agents leak information through timing or behavioural signals, and semantic attacks, where the message is well formed but its meaning has been manipulated. The aim of the attacker is to compromise the live exchange, leading to misinformation, privilege confusion or coordinated manipulation across agents.

ASI07 applies to you if any of these are true:

Multi-agent orchestration: a planner or supervisor agent delegates sub-tasks to worker agents, in one framework or across frameworks.
Cross-organisation agents: your agents call, or are called by, agents operated by suppliers, customers or marketplaces, typically over the Agent2Agent (A2A) protocol.
Tool and context servers: agents connect to MCP servers, which OWASP treats as communication peers as well as supply chain components (one of its scenarios is a malicious MCP endpoint advertising spoofed descriptors).
Shared buses and blackboards: agents coordinate through queues, pub/sub topics, shared memory stores or webhooks, including A2A push notifications.

A single chatbot with no peers is largely out of scope; its risks sit in ASI01 and ASI02. See the Multi-Agent and A2A Security Guide for architecture patterns.

Structure and key requirements

The entry follows OWASP's standard format: description, common examples, example attack scenarios, prevention and mitigation guidelines, and references. The tables below paraphrase the official text and add the concrete protocol control that implements each mitigation.

Common examples and attack scenarios

Layer	What OWASP describes	Example scenario in the entry
Transport	Unencrypted channels allowing a man-in-the-middle to inject hidden instructions	Semantic injection over unauthenticated HTTP produces outputs that look normal but are biased
Integrity	Tampered messages that blur task boundaries, causing leakage or goal confusion	Tampered reputation messages in a trading network skew which agents are trusted
Freshness	Replayed delegation or trust messages that grant access or revive stale instructions	Replayed emergency coordination messages trigger outdated procedures
Protocol	Downgrade and forged agent descriptors that make malicious commands look legitimate	Forced fallback to an unencrypted legacy mode lets an attacker inject objectives and risk parameters
Discovery and routing	Misrouted discovery traffic creating relationships with malicious agents or coordinators	A fake peer registered in discovery with a cloned schema intercepts privileged coordination traffic; a malicious MCP endpoint routes sensitive data through attacker infrastructure
Metadata	Traffic-pattern analysis revealing agent roles and decision cycles	Not a separate scenario; addressed by metadata protection controls
Semantic	One instruction interpreted differently by different agents	A single instruction parsed into conflicting intents leads agents to take contradictory actions

Prevention requirements mapped to protocol controls

OWASP mitigation (paraphrased)	Concrete control
End-to-end encryption, per-agent credentials, mutual authentication, certificate pinning, forward secrecy	TLS 1.3 everywhere (A2A recommends 1.3 and says to disable SSLv3, TLS 1.0 and 1.1); mTLS with workload certificates (A2A defines a `MutualTlsSecurityScheme`); pin to your internal CA rather than individual leaf certificates so rotation works
Message integrity: sign messages, hash payload and context, check for hidden or altered instructions	HTTP Message Signatures (RFC 9421, `Signature-Input` and `Signature` fields) or JWS over the message body; include the task ID and context hash in the signed content
Anti-replay with nonces, session IDs and timestamps	RFC 9421 `created`, `expires` and `nonce` parameters with a short acceptance window and a nonce cache; idempotency keys on side-effecting tasks
Disable weak legacy modes, bind protocol authentication to agent identity, enforce version and capability policy	Pin the `A2A-Version` your clients accept; the A2A specification advises clients to request specific versions and avoid automatic fallback; reject plain HTTP at the listener, not in application code
Metadata protection: padding, rate smoothing, no fixed schedules	Apply only where agent roles or timing are sensitive (trading, defence); jitter scheduled agent runs
Authenticated discovery, directory access control, routing anomaly monitoring	Private registry of approved agents; orchestrators may only route to registry entries; alert on new or changed endpoints
Attested registries and signed agent cards, verified continuously	A2A Agent Card signing: JWS (RFC 7515) over the card canonicalised with JCS (RFC 8785), protected header with `alg`, `kid` and optional `jku`; clients should verify at least one signature, and expired or revoked keys must not be used
Typed, versioned message schemas with explicit audiences; reject on validation failure	JSON Schema validation at the receiver; an explicit `audience` or recipient field in every message; tokens audience-bound per RFC 8707 (required by MCP)

Identity and NHI requirements

ASI07 is where agent identity stops being a governance question and becomes a wire protocol. OWASP's own appendix maps the OWASP NHI Top 10 NHI4 Insecure Authentication to ASI03 and ASI07, and NHI8 Environment Isolation to ASI07 and ASI08. In practice the identity requirements are:

One identity per agent instance class: each agent authenticates as itself, not as the platform or a shared service account, so a receiver can authorise by sender and a revocation affects one agent. See the OWASP NHI Top 10 NHI9 NHI Reuse Guide.
Workload credentials, not static keys: prefer short-lived X.509 or JWT credentials issued from workload attestation (for example SPIFFE SVIDs) over API keys in configuration. See the SPIFFE and SPIRE Guide and the mTLS Guide.
Audience-bound tokens and no passthrough: the MCP authorisation specification requires clients to send the RFC 8707 resource parameter, requires servers to accept only tokens issued for them, and forbids a server from passing the client's token through to upstream APIs. Apply the same rule to A2A: an agent that receives a token must not forward it to the next agent. See the OAuth Token Exchange and Delegation Guide.
Bound delegation: A2A section 7.6.3 recommends that credentials passed in-band are bound to the originating agent and encrypted so that only it can read them, because in-band exchange exposes credentials to every agent in the chain. It also says the TASK_STATE_AUTH_REQUIRED transition is not, by itself, authorisation for anything.
Per-request authentication and authorisation: A2A requires servers to authenticate every request and to authorise every operation, scoping results such as task lists to what the caller may see.
Separate environments: development agents must not hold credentials that a production agent will accept, which is the NHI8 link. See the OWASP NHI Top 10 NHI8 Environment Isolation Guide.

For the full pattern library, see the Agent-to-Agent Authentication Guide.

Implementation steps

Map every channel. Draw each agent-to-agent, agent-to-MCP, agent-to-bus and webhook path, with protocol, version, authentication method and data classification. Unknown channels are the first finding; shadow MCP servers are common. See the Unsanctioned AI Agents and MCP Servers Guide.
Enforce transport security at the edge. Terminate only TLS 1.3 (or 1.2 with forward-secret suites where 1.3 is unavailable), disable plain HTTP listeners, and send HSTS. Test by attempting a plaintext and a TLS 1.1 connection from a test client: both must fail.
Issue per-agent identities. Register each agent in your identity provider or workload identity system with an owner, purpose and environment. Replace shared API keys with short-lived credentials. Roll out per agent pair, starting with the highest-privilege orchestrator.
Turn on mutual authentication. Start in log-only mode: record peer identity on every call and alert on calls without one. After two weeks with no unexplained unauthenticated calls, switch to enforce. Rollback is the listener setting, so keep it in configuration, not code.
Sign and verify agent cards and registry entries. Publish signed A2A Agent Cards at /.well-known/agent-card.json, keep the signing keys in a managed key store, and configure clients to verify against a trusted key store rather than any key reachable through jku.
Close discovery. Orchestrators route only to agents in an approved registry, matched on verified identity, not on name or description. Treat agent descriptions as untrusted text: they must not influence routing through the model.
Add message integrity and anti-replay for high-impact flows. Sign payment, deployment, access-granting and emergency messages with RFC 9421 or JWS, including created time, expiry and nonce, and reject duplicates.
Validate schemas and audiences at every receiver. Reject messages that fail schema validation or name another recipient. Log rejections; they are your best early signal.
Harden webhooks. For A2A push notifications, authenticate every webhook, validate callback URLs against private address ranges to prevent server-side request forgery, and process notifications idempotently.
Retest after each protocol upgrade. A2A 1.0 introduced breaking changes; MCP revisions change transport behaviour. Each upgrade is a downgrade-attack opportunity until old versions are switched off.

Evidence and assessment

Assessors, auditors and red teams will look for proof that the controls run, not that they exist in a design document.

Test	Method	Pass condition
Plaintext and downgrade	Connect without TLS, with TLS 1.1, and with an older protocol version header	All refused; attempt logged with source identity
Peer spoofing	Call an agent with a valid certificate for a different agent, or none	Refused by authorisation, not only authentication
Agent card tampering	Serve a modified card with the original signature, and a card signed by an unknown key	Client rejects both and does not route to the agent
Replay	Resend a captured signed message after the acceptance window and inside it	Both rejected (expiry and nonce cache)
Token passthrough	Present a token issued for agent A to agent B	Rejected on audience
Discovery poisoning	Register a look-alike agent with an exaggerated description in a test registry	Orchestrator does not select it; registry change raises an alert
Semantic ambiguity	Send an instruction with conflicting fields or embedded natural-language overrides	Schema validation rejects it before any agent acts

Metrics that show it is working:

Authenticated channel coverage: percentage of inter-agent calls carrying a verified peer identity (target 100% in production).
Signed card coverage: percentage of registered agents with a valid, current Agent Card signature.
Shared credential count: number of credentials used by more than one agent (target zero).
Rejected message rate: schema, audience, signature and replay rejections per thousand messages, with every spike investigated.
Time to revoke an agent: minutes from decision to the agent being unable to authenticate to any peer.

Keep the logs that let you reconstruct a conversation between agents: sender and receiver identity, task ID, message hash, protocol version and decision. See the AI Agent Observability and Incident Response Guide.

Mapping to other frameworks

Framework	Reference	Relevance to ASI07
OWASP Top 10 for LLM Applications 2025	LLM02 Sensitive Information Disclosure, LLM06 Excessive Agency	OWASP's own Appendix A mapping
OWASP Agentic AI Threats and Mitigations	T12 Agent Communication Poisoning, T16 Insecure Inter-Agent Protocol Abuse	Source threats for the entry (Appendix A)
OWASP NHI Top 10	NHI4 Insecure Authentication, NHI8 Environment Isolation	Appendix C mapping
MITRE ATLAS	AML.T0051 LLM Prompt Injection, AML.T0073 Impersonation, AML.T0080 AI Agent Context Poisoning	Semantic injection, spoofed peers, poisoned context arriving by message
MITRE ATT&CK	T1557 Adversary-in-the-Middle, T1565.002 Transmitted Data Manipulation, T1550 Use Alternate Authentication Material	Interception, tampering and replay of stolen tokens
NIST SP 800-53 Rev. 5	SC-8, SC-23, IA-3, IA-9, AC-4, SI-10, AU-10	Transmission integrity, session authenticity, service authentication, flow enforcement, input validation, non-repudiation
NIST CSF 2.0	PR.AA-01, PR.AA-03, PR.DS-02, DE.CM-01	Identities managed, services authenticated, data in transit protected, network monitored
ISO/IEC 27001:2022 Annex A	5.14 Information transfer, 8.5 Secure authentication, 8.20 Networks security, 8.24 Use of cryptography	Policy and control anchors for inter-agent channels

Related entries: OWASP Agentic Top 10 ASI03 Guide for delegated privilege, OWASP Agentic Top 10 ASI04 Guide for malicious tool servers, and OWASP Agentic Top 10 ASI08 Guide for what happens when a bad message propagates.

Common pitfalls

Trusting the network instead of the peer. Agents on the same cluster or VPC accept each other without authentication. One compromised pod can then speak for any agent. OWASP notes that perimeter defences do not work for decentralised agent systems.
Letting the model choose peers from descriptions. The LevelBlue SpiderLabs Agent-in-the-Middle proof of concept (April 2025) showed a host agent's LLM judge picking a rogue agent because its self-published card claimed to be the best choice. Routing must be decided by policy on verified identity.
Accepting tool servers on name alone. OWASP's incidents tracker tags the postmark-mcp malicious MCP server under ASI07: a server presenting itself as a trusted integration silently copied every email an agent sent to an attacker. Verify publisher and pin versions.
Exposing agents without authentication. The same tracker maps reports of Copilot Studio agents that were publicly reachable without authentication to ASI03 and ASI07. Default-open agent endpoints are an inter-agent channel anyone can join. See the Securing Microsoft Copilot Studio Agents Guide.
Forwarding tokens down the chain. Passing the user's or orchestrator's bearer token to each worker turns one interception into access everywhere and breaks audit attribution. Exchange for a new, narrower token at each hop.
Leaving fallback on. Supporting an old protocol version or plain HTTP "for compatibility" is exactly the downgrade path OWASP describes.

Practitioner checklist

Inventory every inter-agent, agent-to-MCP and webhook channel with protocol version and authentication method.
Require TLS 1.3 (or forward-secret TLS 1.2) on every channel and remove plaintext listeners.
Give every agent its own short-lived workload credential and remove shared keys.
Enforce mutual authentication and per-request authorisation on every agent endpoint.
Sign Agent Cards and registry entries, and verify signatures against a trusted key store.
Route only to agents in an approved registry, decided by policy, never by model reading descriptions.
Audience-bind all tokens and prohibit token passthrough between agents and MCP servers.
Sign high-impact messages with expiry and nonce, and reject replays.
Validate typed, versioned schemas with explicit recipients at every receiver.
Run the downgrade, spoofing, replay and discovery-poisoning tests after every protocol change.

OWASP Agentic Top 10 ASI07 Guide