The Security Dichotomy in Agent Communication Protocols

Rigorous empirical security testing is essential for maturing agent communication infrastructure. This study provides the first comparative evaluation of how leading protocols perform under adversarial conditions—revealing both promising architectural patterns and specific implementation gaps that the field must address. This analysis is based on "Security Analysis of Agentic AI Communication Protocols: A Comparative Evaluation" by Louck, Stulman, and Dvir (Ariel University, November 2025).

Link to paper: https://arxiv.org/pdf/2511.03841

Research Context

As multi-agent AI systems transition from research prototypes to production infrastructure, their communication protocols require the same rigorous security evaluation standard in distributed systems engineering. Yet the rapid pace of development in this space has outpaced systematic adversarial testing. Most security assessments remain theoretical, based on specification review rather than empirical validation against live implementations.

This study addresses that gap through the first comparative security evaluation of active agent communication protocols: empirical testing of the official CORAL implementation and a high-fidelity ACP simulation, benchmarked against literature-based analysis of Google's A2A protocol. The researchers at Ariel University developed a 14-point vulnerability taxonomy spanning authentication, authorisation, integrity, confidentiality, and availability, then conducted 50-trial adversarial test suites against each protocol under a semi-trusted threat model.

The core finding: Protocol architecture and implementation security are orthogonal concerns requiring separate validation. Strong architectural design does not automatically translate to secure implementations, and optional security features create configuration-dependent vulnerability surfaces. Understanding this dichotomy is essential for the next generation of agent communication standards.

Why This Research Matters

Three developments underscore the timeliness of this work:

Industry convergence: The announced merger of A2A and ACP reflects recognition that first-generation protocols require fundamental strengthening. Empirical data on their specific weaknesses informs what the unified standard must address.

Production deployment pressure: Organisations cannot move forward with deployment of multi-agent systems for high-stakes applications—financial transactions, supply chain coordination, healthcare workflows—without comprehensive security benchmarks for the underlying communication layer.

The payment protocol signal: Google's introduction of a dedicated Agent Payments Protocol (AP2) validates that agent-based financial transactions require specialised security architecture, not generic task delegation patterns.

Rigorous adversarial testing serves the field by identifying specific gaps that protocol developers can address, rather than discovering vulnerabilities only after production incidents.

Understanding the Threat Landscape

Before examining how individual protocols perform under adversarial conditions, we need to establish what attack surfaces exist when agents communicate with each other. Multi-agent systems introduce security challenges that don't map cleanly onto traditional API security or human-agent interaction patterns.

The researchers developed their vulnerability taxonomy around five primary attack classes, each representing distinct threat vectors in agent-to-agent communication:

Injection attacks occur when adversarial content embedded in messages coerces agents into unintended behaviour. In multi-agent systems, this threat compounds: a prompt injection that succeeds against one agent can propagate through delegation chains, with each hop potentially amplifying the attack's reach. Unlike single-agent scenarios where a human might notice anomalous behaviour, agent-to-agent workflows can execute malicious instructions autonomously across multiple systems before any human oversight occurs.

Interception attacks exploit the communication channel itself. Man-in-the-middle adversaries positioned between agents can read, modify, or suppress messages in transit. While transport-layer encryption (TLS) addresses confidentiality, it doesn't guarantee message integrity at the application layer—a distinction that becomes critical when evaluating protocol design choices.

Replay attacks capture valid messages and retransmit them later to trigger duplicate actions. In financial workflows, this could mean repeated payments; in coordination tasks, it could desynchronise state across participating agents. Effective replay protection requires mechanisms beyond transport security: nonces, timestamps, or cryptographic binding to specific session contexts.

Poisoning attacks target the data or context that agents rely on for decision-making. This includes corrupted training data, manipulated tool outputs, or falsified discovery metadata. In multi-agent ecosystems, poisoning at the discovery layer is particularly concerning—if an adversary can inject false agent capabilities or endpoints into the system's registry, they can redirect legitimate traffic to malicious infrastructure.

Unauthorised access encompasses failures in authentication (verifying identity) and authorisation (enforcing permissions). Traditional client-server models assume hierarchical trust relationships; agent-to-agent communication requires graph-shaped trust models where permissions may be transitive, delegated, or context-dependent.

What makes agent-to-agent communication security distinct from traditional API security is the coordination layer that sits between individual agent capabilities. When Agent A delegates a task to Agent B, that delegation carries implicit trust assumptions: that B is who it claims to be, that B will only access data necessary for the task, that B's response hasn't been tampered with, and that A's original intent hasn't been corrupted by injection attacks. Each of these assumptions requires explicit protocol-level enforcement—assumptions that cannot be verified by human inspection during autonomous operation.

The 14-point vulnerability taxonomy developed by the researchers maps specific weaknesses to these attack classes across five security domains: authentication and session management, authorisation (access control), data integrity, confidentiality and isolation, and availability. This taxonomy provides the framework for evaluating how each protocol's architectural choices translate into concrete security posture.

Protocol Architectures: Three Approaches to Agent Communication

With the threat landscape established, we can examine how A2A, CORAL, and ACP approach the fundamental challenge of secure agent communication. Each protocol makes different architectural choices about trust establishment, message flow, and security enforcement—choices that create structurally different vulnerability profiles.

A2A: Peer-to-Peer Task Delegation

Google's Agent-to-Agent (A2A) protocol implements a peer-to-peer model optimised for low-latency task delegation between autonomous agents. The architecture centres on direct communication between a client agent and a remote agent, mediated by a protocol handler that manages message routing and capability negotiation.

Trust model: A2A establishes trust at connection time through AgentCards—JSON metadata documents that advertise an agent's capabilities, roles, and identity. Once a connection is established via OAuth 2.0 bearer tokens, the protocol assumes persistent trust for the session duration. This design prioritises seamless handoffs and minimal overhead in peer-to-peer exchanges.

Message flow: Task delegation occurs through structured JSON-RPC messages containing action identifiers, input/output schemas, and execution parameters. Real-time collaboration uses Server-Sent Events (SSE) for asynchronous updates. The protocol relies on TLS 1.3 for transport-layer encryption.

Security implications: A2A's architecture reflects first-generation thinking about agent communication—the design prioritises interoperability and low latency over defence-in-depth. Several architectural choices create inherent security constraints:

The reliance on transport-layer encryption without per-message integrity validation means that while messages are confidential in transit, there's no mechanism to detect tampering by semi-trusted intermediaries after TLS termination. AgentCards lack mandatory cryptographic signing, making the discovery layer vulnerable to spoofing—an adversary can forge capabilities or inject false endpoints during agent onboarding. Token scopes tend toward coarse granularity, often bundling unrelated permissions into single authorisation artifacts. The protocol provides no explicit session isolation mechanisms, meaning data from one interaction may leak into another.

A critical methodological note: Unlike CORAL and ACP, A2A does not have a publicly available reference implementation that the researchers could test empirically. The security evaluation of A2A is therefore based on literature analysis and specification review rather than adversarial testing against live code. This distinction matters: specification review can identify architectural weaknesses but cannot validate whether those weaknesses manifest as exploitable vulnerabilities in practice. The absence of a testable implementation is itself a signal—it limits the field's ability to validate A2A's security properties empirically before production deployment.

CORAL: Decentralised Coordination with Integrated Payments

The CORAL protocol represents a fundamentally different approach: a hybrid architecture that integrates on-chain smart contracts for payments with off-chain threaded communication for agent coordination. Where A2A assumes a relatively trusted peer-to-peer environment, CORAL assumes a more adversarial landscape where economic incentives and cryptographic verification replace implicit trust.

Trust model: CORAL anchors identity in decentralised identifiers (DIDs) and blockchain-based wallets, which manage cryptographic keys and transaction signing. Trust is established explicitly through coalition formation—agents form verifiable teams with defined participation boundaries before collaborative work begins. For financial operations, trust is enforced through Solana-based escrow contracts that hold funds until task completion conditions are cryptographically verified.

Message flow: The protocol operates through a central Coral Server that manages threaded messaging, participant lifecycles, and event subscriptions. External agents integrate through modular adapters (Coralisers) that provide discoverability and protocol compliance. Communication occurs via HTTP and WebSocket transports, with SSE channels providing real-time event streams to connected participants.

Security implications: CORAL's architecture embeds several security-relevant design decisions:

The threading model creates explicit session boundaries—each thread maintains its own participant list, message history, and context isolation. This architectural choice directly addresses the confidentiality and isolation concerns that plague protocols with implicit session management.

Transport-layer validation binds messages to authenticated connections. The protocol enforces that messages must originate from active SSE connections with valid transport identifiers, creating a defence against unauthenticated message injection that operates independently of application-layer authentication.

Payment integration as a first-class component means that high-stakes financial operations don't rely on generic task delegation patterns. The escrow mechanism provides cryptographic guarantees for payment workflows that protocols treating payments as "just another task" cannot match.

However, the hybrid on-chain/off-chain architecture introduces complexity. Security properties that hold for blockchain-anchored operations don't automatically extend to off-chain communication channels. The Solana contracts provide immutable audit trails and trustless execution for financial flows, but the off-chain threaded messaging layer has its own attack surface that requires separate validation.

ACP: RESTful Flexibility with Optional Security

The Agent Communication Protocol (ACP), developed under the Linux Foundation, takes a third approach: a lightweight, RESTful standard designed for maximum interoperability across heterogeneous agent ecosystems. Where CORAL builds security into the architecture, ACP treats security as configurable—powerful when correctly implemented, but dependent on deployment choices.

Trust model: ACP supports authentication through bearer tokens or optional mutual TLS (mTLS), with integrity reinforced through JSON Web Signatures (JWS) on message parts. The protocol's manifest-driven design allows agents to declare their capabilities and security requirements, with runtime APIs, static manifests, or registries handling discovery.

Message flow: Agents communicate via RESTful HTTP endpoints exchanging MIME-typed multipart messages. This structure accommodates text, binaries, and external references in ordered parts, supporting both synchronous request-response and asynchronous await/resume patterns. The brokered architecture routes requests through registries that maintain agent metadata and capability mappings.

Security implications: ACP's flexibility is both its strength and its vulnerability:

The RBAC framework supports operation-specific JWTs, enabling fine-grained, least-privilege permission scoping that exceeds what A2A's coarse token model can achieve. When JWS validation is mandatory and mTLS is enforced, the protocol provides robust message integrity and mutual authentication.

The problem is that these security features are optional. The protocol's design philosophy emphasises developer autonomy and legacy compatibility, which translates into configuration-dependent security posture. Deployments with partial JWS enforcement, or without mTLS, exhibit dramatically different vulnerability profiles than fully hardened configurations.

The brokered registry architecture also introduces a centralised component that can become a target for denial-of-service attacks or registry pollution—attack vectors that don't exist in A2A's fully decentralised model or CORAL's hybrid approach.

Architectural Summary

These three protocols represent distinct points in the design space:

Understanding these architectural differences is essential context for interpreting the empirical security findings that follow. Architectural choices constrain what's possible at the implementation level—but they don't guarantee that implementations will realise the security properties the architecture enables.

CORAL: A Case Study in Architecture vs. Implementation

The CORAL results provide the clearest illustration of why empirical testing is essential—strong architectural decisions can be undermined by implementation-level gaps that specification review alone cannot detect.

Architectural Strengths (Empirically Validated)

The researchers found that CORAL demonstrates several design patterns that achieved robust empirical performance and warrant adoption across agent communication protocols.

Transport-layer message validation: All data tampering and replay attack attempts were neutralised with 100% success rate. The server enforces transport-locking via transportId, rejecting any message not originating from an authenticated SSE connection. This design eliminates an entire class of unauthenticated message forgery attacks and represents a meaningful advance over protocols relying solely on transport-layer encryption.

The mechanism works by binding message validity to active transport channels. When the researchers attempted to inject malicious messages via direct HTTP POST requests, every attempt returned 400 Bad Request with the message "Transport not found"—the server correctly rejected messages that didn't originate from a verified SSE connection. This isn't just input validation; it's a structural guarantee that messages cannot be forged by adversaries who lack access to an authenticated transport channel.

Session isolation: Perfect compartmentalisation across concurrent sessions. PII transmitted to Session A was never observable from Session B in any of 50 trials. This demonstrates that proper isolation boundaries are achievable in agent communication systems and that CORAL's threading model provides meaningful confidentiality guarantees at the architectural level.

The researchers tested this by establishing two concurrent sessions, transmitting synthetic personal identifiers (passport numbers, payment data) in Session A, then attempting to access that data from an adversarial client connected to Session B. The isolation held completely—no cross-session data leakage occurred under any tested conditions.

Error response sanitisation: Across all malformed input tests, the server responded with generic 400 Bad Request errors without exposing stack traces, dependency versions, or internal system state. This consistent sanitisation mitigates CWE-200 (Exposure of Sensitive Information) by ensuring that error conditions don't become information disclosure vectors.

Integrated payment architecture: CORAL is the only protocol among those evaluated that embeds secure financial transactions as a first-class component via Solana-based escrow contracts. This architectural choice—treating payments as native primitives rather than generic task delegation—aligns with Google's subsequent decision to develop AP2 as a specialised payment protocol. The design validates that high-stakes transactions require protocol-level guarantees, not application-layer retrofitting.

These strengths demonstrate mature architectural thinking about the specific security requirements of agent communication, particularly for high-stakes use cases involving financial operations or sensitive data coordination.

Implementation Gaps Requiring Remediation

Empirical testing identified three specific vulnerabilities in the current implementation that architectural review alone would not reveal:

SSE Authentication Gap: The SSE endpoint (/sse/v1/...) does not validate the privacyKey credential before establishing connections. An attacker possessing only a valid sessionId can connect using an arbitrary key, gaining read access to the session stream. This vulnerability was reproducible in 100% of trials.

The severity here is significant: the privacyKey is intended to be the primary authentication credential for SSE access, but the current implementation doesn't verify it. An adversary who obtains a session identifier through any means—network sniffing, log exposure, social engineering—can establish a fully functional SSE connection and observe all session traffic without possessing the correct authentication secret.

Participant Validation Gap: The SSE endpoint does not enforce agentId validation against the session's verified Agent Graph. Adversaries can connect using fabricated identifiers not present in the authorised participant list. While the mismatch appears in server logs, the connection remains active.

This represents a Broken Access Control vulnerability (OWASP A01:2021). The Agent Graph is supposed to define who can participate in a session, but the current implementation doesn't enforce these boundaries at the connection level. An attacker can join sessions they weren't invited to by simply claiming an arbitrary agent identity.

Rate Limiting Absence: The session-creation endpoint (/api/v1/sessions) lacks rate limiting controls. During testing, 20 sessions and 20 concurrent SSE connections were established in rapid succession without throttling, demonstrating uncontrolled resource consumption vulnerability (CWE-400).

This creates a straightforward denial-of-service vector. The session creation operation is resource-intensive—it spawns containers, allocates memory contexts, and initialises thread listeners. Without rate limiting, an adversary can exhaust server resources through automated session flooding, degrading service for legitimate users.

Important context: These are implementation-level gaps in the current reference server, not fundamental architectural flaws in the CORAL protocol design. They represent specific remediation opportunities rather than indicators that the architectural approach is unsound.

The fact that the researchers could empirically validate both strengths and weaknesses demonstrates the value of having a testable implementation available—something A2A notably lacks. CORAL's transparency in providing a public implementation enables exactly the kind of adversarial validation that strengthens protocols before production deployment.

Cross-Protocol Comparative Results

Quantitative Exposure Assessment

Using the formula Confirmed + 0.5 × Partial across 14 vulnerability categories:

CORAL's lower exposure score is driven primarily by its strong integrity and confidentiality architecture. A2A's highest exposure reflects confirmed vulnerabilities in nearly every evaluated category. ACP falls between, with its score reflecting configuration-dependent security where proper enforcement can mitigate many theoretical weaknesses.

A2A: Literature-Based Assessment

A2A's design reflects first-generation thinking about agent communication, prioritising low-latency peer-to-peer delegation over defence-in-depth. Literature review identifies exposure across 12 of 14 categories:

The protocol provides no per-message integrity validation beyond TLS, meaning tampering by semi-trusted intermediaries goes undetected. Token scopes are coarse-grained, enabling privilege escalation when a token intended for one operation grants access to unrelated capabilities. AgentCards are unsigned, permitting discovery-layer spoofing where adversaries can forge agent identities and capabilities. Bearer tokens are long-lived without mandatory expiration, expanding the window for replay attacks. The protocol specifies no session isolation mechanisms, leaving cross-session data leakage as an architectural gap rather than an implementation bug.

These findings help explain the rationale for the A2A/ACP convergence—the next-generation unified standard needs to address these foundational gaps to support production deployment in adversarial environments.

ACP: Empirical Validation of Configuration Dependency

The research demonstrates that ACP's configuration flexibility creates security variance that specification review alone cannot characterise. The protocol's theoretical security model is sound, but practical security depends heavily on deployment choices.

Under strict configuration (mandatory JWS validation, mutual TLS), ACP provides robust RBAC enforcement and message integrity. The manifest-driven permission model achieves fine-grained, least-privilege scoping that exceeds A2A's capabilities.

Under partial enforcement (JWS optional, single-factor authentication)—configurations common in production due to legacy compatibility requirements or development convenience—the empirical tests revealed significant exposure:

PII exfiltration succeeded through MIME-type misconfigurations that allowed sensitive data to leak through artifact handling. Message tampering went undetected when JWS validation was not enforced, with modified payloads processed as legitimate. Replay attacks succeeded in extended sessions lacking timestamp validation, enabling duplicate execution of previously valid requests. Registry pollution attacks demonstrated that the brokered architecture is vulnerable to flooding and manifest spam when rate limiting is not configured.

ACP's manifest-driven RBAC design is architecturally sound—the challenge is ensuring that security features move from optional to mandatory in practice. The protocol's flexibility serves legitimate deployment needs, but creates systemic risk when security configurations are inconsistent across an agent ecosystem.

What This Means for Protocol Development

The Architecture-Implementation Lesson

CORAL's dichotomy—exceptional transport-layer validation coexisting with authentication bypass at the gateway layer—demonstrates that security properties are not uniformly distributed across protocol implementations. Architectural review validates design decisions; adversarial testing validates that those decisions are correctly enforced at critical control points.

This finding has direct implications for how the field evaluates protocol security: formal specification analysis is necessary but insufficient. The next generation of agent communication standards requires both design-time security review and implementation-time adversarial validation.

A protocol can have a theoretically sound security model and still ship with exploitable vulnerabilities if implementation doesn't match architectural intent. Conversely, a well-implemented protocol with architectural weaknesses will eventually encounter scenarios where no implementation can provide adequate protection.

Forward Path: Synthesis Opportunity

The empirical results suggest specific architectural patterns worth incorporating into next-generation protocols:

From CORAL: Adopt the transport-locking mechanism to prevent unauthenticated message injection. This design pattern—binding message validity to authenticated transport channels—provides structural integrity guarantees that don't depend on correct application-layer implementation.

From CORAL: Implement explicit session isolation with verified participant boundaries. The threading model demonstrates that confidentiality can be enforced architecturally rather than depending on careful data handling throughout the codebase.

From CORAL: Learn from the integrated payment architecture. Google's subsequent development of AP2 as a dedicated payment protocol validates CORAL's thesis that high-stakes transactions need specialised protocol-level guarantees.

From ACP: Enforce mandatory per-message integrity guarantees. JWS signing per MIME segment provides tamper-evident communication that catches modification attempts regardless of transport-layer security state.

From ACP: Maintain fine-grained RBAC scoping. Operation-specific JWTs bound to individual tasks achieve least-privilege enforcement that coarse token models cannot match.

The synthesis: A protocol that combines CORAL's structural integrity guarantees with ACP's mandatory per-message validation—where security features are architectural requirements rather than configuration options—would address the weaknesses identified across all three evaluated protocols.

The A2A/ACP convergence provides an opportunity to incorporate these lessons systematically rather than retrofitting them later.

Remediation Path for CORAL

For the CORAL protocol specifically, the implementation gaps are addressable through targeted remediation without requiring protocol redesign:

Gateway-level validation hardening:

• Add privacyKey verification before SSE connection establishment

• Implement agentId validation against session Agent Graph before stream activation

• Deploy request rate limiting on session creation endpoints with configurable thresholds

These modifications would align implementation security with architectural intent. The underlying design is sound—the transport-locking mechanism works correctly, session isolation holds under adversarial testing, and the integrated payment architecture provides appropriate guarantees for financial operations. The identified vulnerabilities exist at the gateway layer, where connection establishment occurs before the protocol's stronger architectural protections engage.

Open Research Questions

Several areas warrant continued investigation:

Attack chaining: Can successful SSE impersonation be leveraged to obtain a valid transportId, which is then exploited for prompt injection or data tampering? The experiments validated individual vulnerabilities but did not test multi-stage exploitation paths. If the authentication bypass can be combined with subsequent attacks that require authenticated transport, the effective severity of the gateway vulnerabilities increases significantly.

Smart contract layer: The Solana-based escrow contracts were not formally audited in this study. Re-entrancy vulnerabilities and oracle manipulation remain theoretical risks requiring independent verification through specialised blockchain security assessment. The researchers explicitly scoped their work to network-layer behaviour, leaving the on-chain component as a known gap in the evaluation.

LLM-layer injection: All three protocols remain exposed to prompt-based tool poisoning at the application layer, independent of transport security. This represents a fundamental challenge for LLM-powered agent systems that likely requires solutions beyond protocol design—potentially involving model-level input validation, sandboxed execution environments, or formal verification of agent behaviour under adversarial inputs.

Convergence protocol security: The A2A/ACP merger and Google's AP2 emerged during the final stages of this research and remain unevaluated. Future work should assess whether the unified standard addresses the architectural weaknesses identified in both predecessor protocols, or whether it inherits their limitations.

Conclusion

This research demonstrates that empirical security evaluation is essential for maturing agent communication infrastructure. The field benefits from having protocols like CORAL with testable implementations that enable validation of both architectural strengths and implementation gaps.

Key takeaways:

Strong architecture requires rigorous implementation: CORAL's transport-layer validation and session isolation demonstrate promising patterns that achieved 100% success rates under adversarial testing. These are not theoretical protections—they're empirically validated security properties. Simultaneously, gateway-level gaps show where implementation must catch up to design intent. The architectural decisions are sound; the current implementation doesn't fully enforce them.

Optional security features create systemic risk: ACP's configuration-dependent posture shows that flexibility without enforcement creates inconsistent protection in practice. When critical security features like JWS validation are optional, some deployments will inevitably run without them—and in an interconnected agent ecosystem, the security of the whole depends on the security of each participant.

First-generation protocols reveal lessons for convergence: A2A's architectural gaps—no per-message integrity, coarse token scopes, unsigned discovery metadata—help clarify what the unified A2A/ACP standard must address to support production deployment. The merger implicitly acknowledges that neither predecessor protocol was sufficient on its own.

Testable implementations enable progress: CORAL's public reference server allowed the researchers to validate both what works and what doesn't. A2A's lack of a testable implementation limited evaluation to literature analysis, which cannot detect implementation-specific vulnerabilities. Transparency in providing testable code accelerates the security maturation of the entire field.

For organisations building on these protocols: architectural review and adversarial testing serve complementary purposes. Both are necessary for production readiness in high-stakes multi-agent systems.

The full methodology, vulnerability taxonomy, and test artifacts are available for independent replication and validation, supporting continued improvement of agent communication security across the field.