AI-to-AI communication already runs on MCP and A2A, and neither mandates an audit trail. See how each fails, and where to enforce control on agent traffic.
AI-to-AI communication already runs on two open protocols. MCP connects an agent to tools. A2A connects agents to each other. Neither mandates an audit trail, and the missing human-readable record is a present gap in shipped software rather than a future problem about machines inventing a language.
Two protocols carry almost all of it, and they solve different problems.
| MCP | A2A | |
|---|---|---|
| Full name | Model Context Protocol | Agent2Agent |
| Connects | An agent to tools, data, and APIs | An agent to another agent |
| Origin | Anthropic, open standard | Google, now under the Linux Foundation |
| Transport | JSON-RPC 2.0 | HTTP, JSON-RPC 2.0, gRPC, Server-Sent Events |
| Shape | Vertical, client to tool server | Horizontal, peer to peer |
A real system uses both. An orchestrator delegates a task over A2A to a specialist agent, and that specialist reaches its database over MCP. Neither side hands over its tools or its memory.
Adoption is not theoretical. MCP added OAuth 2.0 authentication in March 2025 and now sees more than 97,000,000 monthly SDK downloads. ACP, a third protocol from IBM Research, folded into A2A under the Linux Foundation in August 2025, leaving two standards rather than three. Governance questions raised by this layer appear in the governance layer beneath automation.
Worries about AI-to-AI communication usually point at a future where machines invent their own language. The gap is nearer than that, and it is documented.
MCP lacks mandatory audit trails. It also lacks credential revocation on session close and consent gates for sensitive tools. Those are absences in the specification, not bugs awaiting a patch.
The gap between spec and implementation is sharper still. Researchers auditing agent protocols found the MCP specification states that servers must sanitize tool outputs and clients should validate tool results before passing them to the model. The reference SDK implements neither.
So the human-readable record people worry about losing was never mandatory. Every organization running agents today is relying on whatever logging its own stack happens to produce. Consequently the fix is a requirement you impose rather than a standard you wait for.
Discover how Threatcop protects your workforce from modern cyber threats.
Treating agent traffic as one risk category produces controls that miss half of it. The two protocols have distinct threat models.
| A2A threat model | MCP threat model | |
|---|---|---|
| Main attack | Agent impersonation, context poisoning through the Agent Card, webhook SSRF, OAuth token theft and replay | Tool exploitation and data exfiltration through a compromised tool |
| Trust boundary | Decentralized, per agent; each peer verifies identity and scopes independently | Between the client and the tool server |
| Blast radius | High, because it targets the identity fabric of the agent network | More contained, at the tool boundary |
A2A attacks go after trust itself. Anyone can deploy an agent claiming to be a helpful analysis service while quietly stealing data. Worse, the Agent Card advertising its abilities is a public document. An attacker can study it, or poison it.
API keys and TLS do not solve this. They protect the channel while saying nothing about the identity, intent, or behaviour of the agent at the other end. Impersonation mechanics of this kind appear in why impersonation attacks keep rising.
In May 2026, the Cloud Security Alliance called MCP one of the most rapidly weaponized attack surfaces in agentic AI. It cited the breadth of the supply chain exposure.
By that point, at least seven confirmed high or critical-severity CVEs spanned major MCP-integrated platforms, including MCP Inspector, LiteLLM, Cursor IDE, LibreChat, and Windsurf. More were under active tracking.
Researchers surveying the MCP lifecycle catalogued the recurring failures, and none of them requires a novel attack:
Exposure is often self-inflicted. Binding a local MCP server to 0.0.0.0 during testing publishes its context endpoint to the whole network. That is the same mistake that put tens of thousands of AI agents on the public internet this year.
The popular fear runs like this. AI will write code and swap messages in a form no human can read. When something breaks, nobody can repair it.
The instinct is sound and the timing is wrong. Agents today communicate in JSON-RPC over HTTP. Every message is readable. Every A2A interaction is an ordinary API call. Nothing is encrypted beyond normal transport security, and nothing is obfuscated.
What is actually missing is not readability. It is retention, correlation, and the requirement to keep any of it. An organization can read a single agent message and still have no record of which agent called which tool, under whose identity, three weeks ago.
That distinction matters because the two problems have different fixes. A future language problem would need new standards. A present logging problem needs a decision this quarter, which is the sort of gap covered in visibility across enterprise security platforms.
Every A2A interaction is an API call. That single fact decides where to enforce control.
An API gateway already sits in this path and already does authentication, rate limiting, and logging. Therefore, it is the natural enforcement point for agent traffic, rather than something new bolted alongside it.
At the gateway, you can require authentication on every agent request and restrict MCP endpoints to approved agents. Message content can be logged for compliance review, and sensitive data blocked before it leaves. Agent Card URLs can also be rewritten, so peers resolve through you rather than directly.
For authorization itself, the Cloud Security Alliance recommends a separate hardened service with its own access controls, audit logging, and key management, kept isolated from the systems it governs. Policy-as-code engines such as Open Policy Agent or Cedar do the evaluation, with policies version-controlled and deployed like any other code.
Work through these before agents start delegating to each other in production.
Item 4 is the one that answers the audit trail concern directly. Nobody will mandate it for you.
Protocols do not choose which agents may talk to each other. People do, usually during an integration sprint, often by accepting a default.
Three decisions stay human. Which peers an agent may discover and trust. What data may cross an agent boundary at all. And who gets told when an agent starts calling something new.
Those choices are made by developers and integration owners rather than by a security team reviewing a design document afterwards. So the training that matters is narrow and role-specific. What does an Agent Card assert? What does a token scope grant? And why is an unsigned peer hostile until proven otherwise, rather than merely unverified?
Threatcop’s TLMS delivers that as role-based content rather than one shared AI module, so the people wiring agents together get the scenarios they will actually meet. Programme design for this sits in role-based training that matches job function.
Ask one question of whatever agent infrastructure you already run. Can you show which agent called which tool, under which identity, on a given day last month?
Most teams cannot, and that answer is the whole problem stated plainly. It is also fixable this quarter, at the gateway, without waiting for a protocol to require it.
Then decide who is allowed to connect an agent to a new peer, and make sure those people know what they are approving before the integration ships rather than after.
AI-to-AI communication is the exchange of tasks, context, and results between autonomous AI systems without a human in each step. In practice it runs over two open protocols. The Model Context Protocol connects an agent to tools and data. Agent2Agent connects agents to one another so a planning agent can delegate to a specialist without exposing its own tools or memory.
MCP is vertical and connects an agent to tools, data sources, and APIs over JSON-RPC 2.0. A2A is horizontal and connects agents to each other over HTTP, JSON-RPC, gRPC, or Server-Sent Events. Their threat models differ accordingly: MCP attacks concentrate at the tool boundary, while A2A attacks target agent identity and trust across the network.
Not by default. MCP does not mandate audit trails, and it also lacks credential revocation on session close and consent gates for sensitive tools. Any record of which agent called which tool, under which identity, comes from logging an organization chooses to implement, most practically at an API gateway sitting in the agent traffic path.
Agents today communicate in JSON-RPC over HTTP, and every message is human-readable. The practical gap is not readability but retention and correlation: organizations frequently keep no durable record linking agent actions to identities over time. That is a logging decision available now, rather than a standards problem waiting on future protocols.
Enforce at the API gateway, since every A2A interaction is an API call. Require mutual authentication between peers. Verify Agent Cards cryptographically. Scope OAuth tokens narrowly and revoke them on session close. Log every call with the identity used. Validate tool outputs before they reach the model, and restrict MCP endpoints to authorized agents only.
Adhish Chakma is a Senior Product Manager at Kratikal, where he leads product initiatives focused on cybersecurity and AI-powered solutions. With experience in product management and cybersecurity, he works on developing practical technologies that address evolving security challenges. His areas of interest include People Security Management, cybersecurity awareness, AI-driven security, email security, and human-layer risk. He is passionate about building security products that make organizations more resilient against emerging cyber threats.
Attacks against AI target the system itself, not your inbox. See the three OWASP lists covering the model, agent,...
Continuous compliance readiness means evidence accumulates as controls operate. See what assessors ask for, the parameter trap, and a...
AI phishing prevention starts with a correction: AI authorship cannot be measured reliably. See which recognition signals died, which...