How to Validate A2A Protocol Compliance: Prevent 3 Agent Security Attacks with Capiscio CLI

Every new protocol promises structure. Few deliver safety.

The Agent-to-Agent (A2A) protocol gives developers a shared language for machine-to-machine collaboration—but it also creates a new attack surface. Agents now authenticate, publish metadata, and call each other directly. That's powerful. It's also dangerous.

A2A protocol compliance doesn't guarantee security. Agent card validation requires more than schema checks—it demands cryptographic verification, live endpoint testing, and real-time behavior monitoring. Below are the attack patterns that validation actually prevents today.

1. Agent Impersonation: Identity Theft in A2A Networks

Every agent lives or dies by its identity.
Lose that, and nothing else matters.

The Attack

An attacker discovers your agent card at https://yourdomain.com/my-awesome-agent/agent-card.json. They copy it, host it on https://yourdomain-fake.com (a domain they control), and keep everything identical: name, capabilities, endpoints. They generate their own key pair and update the JWKS URL to point to their server.

Now two agents claim the same identity. The attacker's version responds to requests meant for you. If consumers don't verify signatures, they can't tell the difference. The attacker intercepts sensitive data, manipulates responses, or poisons downstream workflows. The logs show your agent's name, so nobody suspects compromise.

The variant that's worse: If you expose your JWKS without proper access controls, an attacker doesn't even need their own keys. They reuse yours. Now they're not just impersonating, they're cryptographically authentic.

How Validation Prevents It

Capiscio CLI enforces the cryptographic binding between agent identity and domain ownership:

JWS Signature Verification (RFC 7515)
Every agent card can include a signatures array with detached JWS signatures. The CLI fetches the JWKS from the signature's declared jwks_uri, reconstructs the canonical agent card JSON (excluding the signatures field), and verifies the signature. If it fails, the agent card is untrusted.

HTTPS-Only JWKS Enforcement
The validator rejects any jwks_uri that doesn't use HTTPS. This prevents man-in-the-middle attacks where an attacker intercepts the key fetch and substitutes their own public key.

Default-Secure Behavior
Signature verification runs automatically. To skip it, you must explicitly pass --skip-signature, a deliberate choice that surfaces in logs and CI/CD output.

The result: an attacker can copy your agent card, but they can't forge your signature. Consumers who validate see the impostor for what it is.

2. Protocol Compliance Failures: When Metadata Doesn't Match Reality

Metadata is the handshake before the handshake.
If it's wrong, every dependent system inherits the mistake.

The Attack

An agent card declares "preferredTransport": "JSONRPC" and lists a /rpc endpoint. A consumer builds integration logic expecting JSON-RPC 2.0 responses. But the endpoint actually returns plain HTTP+JSON without the RPC envelope. Requests fail. The consumer's retry logic hammers the endpoint. The failure cascades through dependent systems.

This isn't always malicious, it's often neglect. But the effect is the same: protocol drift between declaration and implementation creates unpredictable failures.

The malicious version: An attacker compromises an agent and changes the endpoint behavior without updating the card. Consumers continue trusting the metadata, sending sensitive data to an endpoint now controlled by the attacker. The contract says "JSON-RPC," so monitoring systems don't flag the violation.

How Validation Prevents It

Capiscio CLI performs live protocol testing against declared interfaces:

JSON-RPC 2.0 Validation
The validator sends a test JSON-RPC request ({"jsonrpc": "2.0", "method": "rpc.discover", "id": 1}) to the declared endpoint. It checks for a valid JSON-RPC response structure with result or error fields. If the endpoint returns raw JSON without the RPC envelope, validation fails.

gRPC Connectivity Testing
For agents declaring gRPC in additionalInterfaces, the validator attempts an HTTP/2 connection with gRPC headers (Content-Type: application/grpc). It verifies the endpoint responds like a gRPC server (specific status codes, gRPC content-type headers).

HTTP+JSON Pattern Verification
For REST-like transports, the validator sends a GET request and checks that the endpoint returns valid JSON with appropriate content-type headers.

Strict vs Progressive Modes
In --strict mode, any mismatch between declared transport and actual behavior blocks deployment. In progressive mode (default), failures generate warnings but don't stop the process—useful during development, dangerous in production.

The result: you can't publish an agent card that lies about its capabilities. The validation catches drift before it reaches production.

3. Endpoint Validation: Testing Real Behavior Beyond Schema Checks

Schemas can't save you from what hides inside a single request.
An agent can accept a well-formed payload and still do the wrong thing.

The Attack

An agent declares support for A2A message processing. Its schema validation passes. But the endpoint has a subtle bug: it accepts messages with deeply nested parts arrays and recurses without depth limits. An attacker sends a message with 10,000 nested parts. The agent stack-overflows or times out. Now multiply this across all agents calling this service. Cascading failure.

The data exfiltration variant: The endpoint accepts file upload parts but doesn't validate the MIME type or size. An attacker embeds sensitive data in a message part, and the agent logs it or forwards it to an unintended destination. The A2A spec says the message is valid. The implementation is the vulnerability.

How Validation Prevents It

Capiscio CLI performs functional behavior testing with the --test-live flag:

Real Message Transmission
The validator constructs a valid A2A message:

{
  "role": "user",
  "parts": [
    {
      "type": "text",
      "text": "Hello, are you available?"
    }
  ]
}

It sends this to the agent's endpoint using the declared transport protocol (JSON-RPC or HTTP+JSON). This isn't a schema test—it's a runtime handshake.

Response Structure Validation
The validator checks that the response matches A2A message contracts: proper role, parts array, valid part types. It uses runtime validators (not just JSON schema) to catch structural violations that schema alone misses.

Latency Measurement
The validator measures single-request response time. If an endpoint takes 30 seconds to return a simple greeting, that's a production red flag. You see it during validation, not during your first customer call.

What It Doesn't Do
This isn't load testing or fuzzing. It won't catch race conditions, memory leaks, or adversarial inputs. But it does answer: "Does this endpoint behave like an A2A agent when you talk to it?"

The result: agents that pass schema validation but fail under real protocol interaction get caught before deployment.

Putting It All Together

These three vectors: impersonation, protocol drift, and runtime misbehavior, are what actually break in production.

Capiscio CLI forces visibility where most systems stay blind. You get measurable proof that your agent is who it says it is, behaves according to its declared contract, and anchors its identity in something verifiable.

A2A compliance is the baseline. Trust verification is the metric that matters.

Validate Your A2A Agents

# Basic validation with signature verification
npx capiscio validate https://yourdomain.com/.well-known/agent-card.json

# Strict mode for production deployments
npx capiscio validate https://yourdomain.com --strict

# Full validation with live endpoint testing
npx capiscio validate https://yourdomain.com --test-live --strict

Understand what your agent is, not what you assume it to be.
Trust begins where verification becomes habit.