Patterns/Agent Patterns

Protocol Doesn't Verify Intent

Why formalized inter-agent communication doesn't solve trust problems

The Conventional Framing

A2A (Agent-to-Agent) protocols formalize how agents communicate with each other. Instead of ad-hoc message passing, agents use standardized formats, schemas, and handshakes. This enables interoperability between agents from different systems.

The pattern is positioned as bringing order to multi-agent chaos—well-defined contracts instead of implicit assumptions.

Why Protocol Doesn't Equal Security

A protocol defines message format, not message intent. A well-formed A2A message can carry malicious content just as easily as legitimate content. The protocol validates structure, not semantics.

Standardization actually helps attackers. Once they understand the protocol, they can craft well-formed malicious messages that pass schema validation.

What protocols don't do:

  • Verify intent. The protocol can't tell if a message reflects authentic agent purpose or compromised agent output.
  • Authenticate meaning. Schema validation confirms format, not that the content is safe or appropriate.
  • Establish trust. That an agent can speak the protocol doesn't mean it should be trusted.

Architecture

Components:

  • Protocol specification— message formats and schemas
  • Validation layer— checks message conformance
  • Agent endpoints— send and receive protocol messages
  • Discovery— how agents find each other

Trust Boundaries

┌─────────────────────────────────────────────────────────┐ │ A2A MESSAGE │ │ │ │ { │ │ "type": "task_request", ← Valid schema │ │ "source": "agent_a", ← Can be spoofed │ │ "content": "...", ← Can contain injection │ │ "signature": "..." ← Proves origin, not safety│ │ } │ │ │ │ Protocol validation: PASS │ │ Content safety: UNKNOWN │ │ Intent verification: IMPOSSIBLE │ └─────────────────────────────────────────────────────────┘
  1. Agent → Protocol layer — message content is untrusted
  2. Protocol → Receiving agent — validation is format-only
  3. Content → Agent processing — injection enters via content field

Threat Surface

ThreatVectorImpact
Content injectionMalicious content in well-formed messagesInjection delivered via protocol
Identity spoofingClaim to be trusted agent in messageReceiver trusts malicious sender
Protocol abuseValid messages used for unintended purposesProtocol features enable attacks
Schema exploitationEdge cases in schema enable malformed messagesBypass validation via schema gaps

The ZIVIS Position

  • •
    Protocol is transport, not trust.A2A defines how to send messages, not whether to trust them. Every message is untrusted input regardless of protocol conformance.
  • •
    Validate content, not just format.Schema validation is necessary but not sufficient. Content validation must happen at the receiving agent, specific to the message type.
  • •
    Authentication isn't authorization.Knowing who sent a message doesn't mean you should do what it asks. Each message needs authorization checks independent of source.
  • •
    Design for adversarial peers.Assume any agent you communicate with might be compromised. Protocol doesn't guarantee peer safety.

What We Tell Clients

A2A protocols are useful for interoperability but provide zero security guarantees. A well-formed message can be just as malicious as a malformed one.

Treat every A2A message as untrusted input. Validate content semantically, not just structurally. Don't let protocol conformance substitute for security checks.

Related Patterns