What is agent-to-agent data exposure?

It is proprietary information leaving your control inside the messages agents send each other. When one agent delegates a task to another, it includes context so the second agent can do the work. If that context is not deliberately scoped, it commonly carries customer records, internal metadata and case history that the receiving agent never needed and that nobody approved sending.

What is the lethal trifecta in AI security?

A term coined by Simon Willison for the combination that makes data exfiltration possible: access to private data, exposure to untrusted content, and the ability to communicate externally. Any two are manageable. All three together mean attacker-controlled text can instruct the agent to take private data and send it out. It cannot be fixed by prompting, because models cannot reliably distinguish instructions by their source.

What is MCP tool poisoning?

Tool descriptions function as instructions to the agent, so whoever writes a description can influence agent behaviour. Tool poisoning embeds malicious instructions in that description. Related attacks include rug pulls, where a server silently redefines a tool after you approved it, and tool shadowing, where one malicious description alters how the agent uses a different legitimate tool. OWASP codifies all three in its MCP Top 10.

Can prompt injection be prevented in multi-agent systems?

Not reliably by prompting or model-level guardrails, because language models cannot dependably tell where an instruction originated. The workable approach is architectural: once an agent has ingested untrusted input, constrain it so that input cannot trigger consequential actions. In practice that means breaking one leg of the lethal trifecta rather than trying to detect every malicious phrasing.

How do I log agent-to-agent conversations for audit?

Log the payloads, not just the outcomes. Most agent logging records that a task completed and with what result, which is useless for a data exposure question. You need what was sent, to which agent, containing which fields, with timestamps. Without payload-level logging you cannot answer a regulator asking what data left your estate.

Will MCP and A2A fix these problems in future versions?

Partly, but not entirely, and the distinction matters for planning. Research published in June 2026 assessing five interoperability protocols concluded that governance constitutes a missing architectural layer above these standards rather than a missing feature within them. They were designed for task coordination and do that well. Enforcing who may know what has to be built at your own boundary.

Securing Agent-to-Agent Conversations: Data Exposure

When your agent delegates a task to another agent, what does it actually send? In most deployments nobody knows, because the payload is prose rather than a schema and nobody reads it. This covers the four ways proprietary data leaks between agents, why MCP and A2A will not stop it, and seven controls that work.

✦Key Takeaways

The delegation payload is natural language, not a schema, so the question of what your agent sent cannot be answered by reading an interface definition.
The recipient is non-deterministic. You are not calling a function; you are briefing a system that decides for itself what to do with the content, including forwarding it.
The lethal trifecta is private data access, exposure to untrusted content, and the ability to communicate externally. No single agent needs all three, because the chain assembles them.
Security analysis of A2A finds it streams whole context payloads to peers with no selective filtering, which makes over-disclosure the default behaviour rather than an attack.
Tool poisoning, rug pulls and tool shadowing are codified in OWASP's MCP Top 10, and more than forty MCP-related CVEs were filed during 2026.
The confused deputy problem is back: MCP servers often act with their own broad credentials rather than the requesting user's, so the permission boundary disappears at the handoff.
June 2026 research across MCP, A2A, ACP, ANP and ERC-8004 found voting and dissent preservation universally absent. Governance is a missing architectural layer, not a missing feature you can wait for.
Payload minimisation, scoped credentials and conversation-level logging remove most realistic exposure, and none of the three requires exotic tooling.

You have encrypted the database, reviewed the vendor's data processing agreement, and confirmed where the model is hosted. Then your scheduling agent delegates a task to a supplier's booking agent, and to give it enough context to work with, it passes the entire customer record.

Nobody approved that. Nobody logged it. It happened because the delegation was a natural language message between two systems, and no one had defined what that message was allowed to contain.

This is the least governed surface in most agentic deployments. Organisations that carefully control which humans see which data are running agents that hold conversations nobody reads, containing whatever the sending agent judged relevant at the time. This article covers what actually leaks in those conversations, why the protocols will not stop it, and the controls that work.

Why the Agent Conversation Is a New Surface

Two standards now carry most of this traffic, and they solve different problems.

The Model Context Protocol governs agent-to-tool communication: how an agent discovers and calls a database, an API or a file store. Agent2Agent, developed by Google and contributed to the Linux Foundation, governs agent-to-agent communication: how one agent discovers another through an Agent Card, delegates a task, and streams results back.

Between them they have made agent interoperability genuinely easy. That is the point, and it is also the problem, because two properties of these channels break the assumptions security teams normally rely on.

The first is that the payload is natural language. A conventional API call has a schema: defined fields, defined types, and a reviewable contract. A delegation message is prose. There is no schema to inspect and no field list to restrict, so what did we send cannot be answered by reading the interface definition.

The second is that the recipient is non-deterministic. When your agent hands a task to another agent, that agent decides what to do with the content. It may summarise it, forward it, store it in memory, or include it in a call to a third system you have never heard of. You are not calling a function. You are briefing a colleague you have never met, who may in turn brief someone else.

The Lethal Trifecta

The clearest framework for this risk comes from Simon Willison, who named the lethal trifecta, the combination that produces data exfiltration. An agent becomes dangerous when it has all three of:

Access to your private data, which is usually the whole point of deploying it
Exposure to untrusted content, meaning any text or image an attacker can influence
The ability to externally communicate, in ways that could carry data out

Any two are manageable. All three together mean that untrusted content can instruct the agent to take private data and send it somewhere. Willison's point is that this cannot be fixed with better prompting, because language models cannot reliably distinguish the importance of instructions based on where those instructions came from. A well-phrased instruction inside a document your agent is reading looks a great deal like an instruction from you.

The multi-agent case is worse in a specific way. You rarely assemble the trifecta deliberately. You give one agent database access, another the ability to read incoming email, and a third the ability to call external APIs, and then you let them delegate to each other. No single agent has all three capabilities. The chain does. Each component passed its own review, and the composition was never reviewed at all.

Venn diagram of the lethal trifecta showing private data, untrusted content and external communications overlapping, with the intersection marked as where exfiltration becomes possible — No single agent holds all three. The composition does, and nobody reviews compositions.

How the Trifecta Assembles by Accident

A concrete version, because this is easier to see than to describe.

A mid-sized UK professional services firm deploys three agents over about six months, each individually sensible.

The first is an inbox agent that reads incoming client email, classifies it and drafts replies. It has mailbox access and no database access. Reviewed and approved.

The second is a matter agent with read access to the case management system, used to answer internal questions about live matters. It sits behind the firm's SSO and cannot send email. Reviewed and approved.

The third is a research agent that can call external legal research APIs and general web search. It holds no client data. Reviewed and approved.

Then someone connects them, because the obvious productivity win is letting the inbox agent answer client queries directly. Now an email arrives containing a paragraph of text crafted to read as an instruction. The inbox agent, which cannot reliably distinguish that paragraph from a legitimate request, delegates to the matter agent for context, receives client details, and delegates to the research agent to check this against public filings, passing the context along.

Every individual approval was correct. The composition has access to private data, exposure to untrusted content and an outbound channel, and no one reviewed the composition because there was no artefact to review. The three approvals happened in different months, and the connection between them was a configuration change rather than a deployment.

This is the shape of most realistic exposure. Not a breached agent, but three safe agents wired into an unsafe chain.

Four Ways Proprietary Data Actually Leaks

Over-Broad Context in Delegation

The most common leak is not an attack. It is the default behaviour.

Security analysis of A2A has found that its streaming communication model tends to pass entire context payloads to peers, with no selective filtering or data segmentation built in. If your agent holds a customer record and delegates a sub-task, the straightforward implementation sends the record, because trimming it requires deliberate engineering that nothing in the protocol prompts you to do.

The result is routine over-disclosure: identity data, calendar contents and internal metadata crossing organisational boundaries because it happened to be in context.

Tool Poisoning and Rug Pulls

Tool descriptions are instructions. An agent reads the description of an available tool to decide when and how to use it, which means whoever writes that description can influence agent behaviour.

OWASP codified this as tool poisoning in its MCP Top 10, alongside two related attacks. A rug pull is when a server silently redefines a tool after you approved it, so what you audited and what runs are different. Tool shadowing is when a malicious tool description alters how the agent uses a different, legitimate tool.

Invariant Labs demonstrated both poisoning and rug pulls against production MCP servers in 2025, showing a poisoned description instructing an agent to exfiltrate user data. More than forty MCP-related CVEs were filed during 2026.

The Confused Deputy

This is the oldest bug in computer security and it has arrived intact in agent systems.

An MCP server frequently executes actions using its own credentials, which are typically broad, rather than the permissions of the user or agent that made the request. A request that should have been refused gets performed because the deputy holding the keys did not check who was really asking.

In an agent chain this compounds. Agent A, acting for a user with limited rights, asks agent B to do something. Agent B holds service-level credentials. The user's permission boundary silently disappears at the handoff.

Agent Impersonation and Card Poisoning

Discovery in A2A works through Agent Cards, JSON metadata advertising an agent's capabilities and endpoint. Documented weaknesses include cloning or mimicking legitimate agents, and embedding malicious content in the card itself, which your agent reads while deciding whom to trust.

If discovery is open and cards are not verified, your agent chooses collaborators based on self-reported claims.

What the Protocols Will Not Do For You

It is tempting to assume the standards bodies will close these gaps. The research suggests otherwise, and the distinction matters for planning.

A June 2026 paper by Richard Kang and Yudho Diponegoro assessed MCP, A2A, ACP, ANP and ERC-8004 against six governance dimensions: membership, deliberation, voting, dissent preservation, human escalation, and audit and replay. It found voting and dissent preservation universally absent across all five protocols, with deliberation absent or partial.

Their conclusion is the important part. Governance is a missing architectural layer above current interoperability standards rather than a missing feature within them. These protocols were designed for task coordination, and they do that well. They were not designed to enforce who may know what.

The practical translation: this is not on a roadmap you can wait for. If your agents pass proprietary data between them, the controls have to be built at your boundary.

Seven Controls That Work

Minimise the payload at the delegation boundary. Decide explicitly what a delegated task needs and pass only that. A booking agent needs an availability window and a reference, not a customer record. This single control removes most real-world exposure, and it is engineering work rather than a product you can buy.

Side by side comparison of a delegation payload, showing the default version carrying five unnecessary customer fields and the scoped version carrying only task, window and an opaque reference — Same outcome, nothing to leak. Scoping the payload is the highest-leverage control available.

Break the trifecta deliberately. Map which agents have private data access, which are exposed to untrusted content, and which can communicate externally. Where a chain assembles all three, break one leg on purpose: an agent that reads untrusted email should not also hold database credentials and outbound network access.

Pin tool definitions and re-verify. The official MCP security guidance is explicit that approval must bind to a specific definition. Hash the tool descriptions you approved and check them at runtime. If a definition changes, halt and require re-approval rather than proceeding. This turns rug pulls from silent into noisy.

Delegate scoped credentials, not ambient authority. Every agent-to-agent call should carry a short-lived, narrowly scoped token representing the original requester's permissions, not the calling service's. If your agents share a service account, you have no permission boundary at all.

Treat every agent response as untrusted input. Output from another agent is content from a system you do not control, which may have been influenced by content it does not control. Validate and constrain it exactly as you would a form submission from the public internet.

Log the conversation, not just the outcome. Most agent logging records that a task completed. For data exposure you need the payloads: what was sent, to which agent, containing which fields. Without this you cannot answer a regulator asking what left your estate. This is the same discipline as tracing reasoning paths for audit, which we set out in the blueprint for agentic governance.

Allowlist egress. Constrain which external endpoints agents can reach. Exfiltration needs a destination, and an allowlist is the cheapest control that removes the third leg of the trifecta for agents that genuinely need the other two.

Conclusion

The uncomfortable summary is that most agent-to-agent data exposure in 2026 is not the result of an attack. It is the result of a default: the sending agent included everything it had, because nothing told it not to, and nobody read the message.

That is good news operationally, because default problems are cheaper to fix than adversarial ones. Payload minimisation, scoped credentials and conversation-level logging will remove most of the realistic exposure in a typical deployment, and none of the three requires exotic tooling.

What they do require is treating the gap between your agents as a controlled boundary rather than plumbing. If you are building agents against systems that hold client data, the same care you apply to data residency and GDPR belongs on the delegation channel, and it belongs there before the second agent goes live rather than after.

Frequently Asked Questions

What is agent-to-agent data exposure?: It is proprietary information leaving your control inside the messages agents send each other. When one agent delegates a task to another, it includes context so the second agent can do the work. If that context is not deliberately scoped, it commonly carries customer records, internal metadata and case history that the receiving agent never needed and that nobody approved sending.
What is the lethal trifecta in AI security?: A term coined by Simon Willison for the combination that makes data exfiltration possible: access to private data, exposure to untrusted content, and the ability to communicate externally. Any two are manageable. All three together mean attacker-controlled text can instruct the agent to take private data and send it out. It cannot be fixed by prompting, because models cannot reliably distinguish instructions by their source.
Is the A2A protocol secure?: A2A provides transport security and authentication, but it does not solve data minimisation for you. Published security analysis finds its streaming model tends to pass entire context payloads to peers with no selective filtering or segmentation, so sensitive metadata crosses organisational boundaries simply because it was in context. Scoping the payload is your responsibility, not the protocol's.
What is MCP tool poisoning?: Tool descriptions function as instructions to the agent, so whoever writes a description can influence agent behaviour. Tool poisoning embeds malicious instructions in that description. Related attacks include rug pulls, where a server silently redefines a tool after you approved it, and tool shadowing, where one malicious description alters how the agent uses a different legitimate tool. OWASP codifies all three in its MCP Top 10.
What is the confused deputy problem in agent systems?: It occurs when an MCP server or downstream agent executes actions using its own broad credentials rather than the permissions of the user or agent that made the request. A request that should have been refused gets performed because the component holding the keys did not verify who was really asking. In agent chains this compounds, because a user's permission boundary can silently vanish at the first handoff.
Can prompt injection be prevented in multi-agent systems?: Not reliably by prompting or model-level guardrails, because language models cannot dependably tell where an instruction originated. The workable approach is architectural: once an agent has ingested untrusted input, constrain it so that input cannot trigger consequential actions. In practice that means breaking one leg of the lethal trifecta rather than trying to detect every malicious phrasing.
How do I log agent-to-agent conversations for audit?: Log the payloads, not just the outcomes. Most agent logging records that a task completed and with what result, which is useless for a data exposure question. You need what was sent, to which agent, containing which fields, with timestamps. Without payload-level logging you cannot answer a regulator asking what data left your estate.
Will MCP and A2A fix these problems in future versions?: Partly, but not entirely, and the distinction matters for planning. Research published in June 2026 assessing five interoperability protocols concluded that governance constitutes a missing architectural layer above these standards rather than a missing feature within them. They were designed for task coordination and do that well. Enforcing who may know what has to be built at your own boundary.

Securing the Agent-to-Agent Conversation: Preventing Proprietary Data Exposure