VeriSwarm
About
DocsPricingAgent Skill
LoginRegister
  1. Home
  2. /Learn
  3. /A2a protocol security
VeriSwarm

Product

  • Pricing
  • Docs
  • API
  • Agent Skill
  • OATS Spec

Trust

  • Trust Center
  • Security
  • Compliance
  • Status
  • Changelog

Company

  • About
  • Blog
  • Open Source
  • Investors
  • Press

Legal

  • Terms
  • Privacy
  • SLA
  • DPA
Technical Guide

A2A Protocol Security: Agent Cards Aren’t Trust

Google’s A2A protocol ships the mailbox, not the trust — agent cards are self-asserted and unauthenticated by default. VeriSwarm adds signed cards, a trust-ranked catalog, and an x-veriswarm-trust extension so you can tell which agent on the other end is actually worth handing a task to.

What agent-card trust means

Agent-card trust is the practice of attaching a verifiable, continuously-updated trust signal — rather than a static, self-asserted claim — to an A2A protocol agent card, so a requesting agent can evaluate whether to hand a task to the agent on the other end before doing so. A2A itself defines the card format and lets cards be signed for authenticity; it does not define what should be trusted about the agent the card describes.

What A2A actually secures — and what it doesn’t

A2A solves discovery and interoperability well: agents advertise capabilities through agent cards, negotiate skills, and move tasks through a defined state machine (submitted → in_progress → completed | failed | canceled). The 1.0 spec added signed agent cards, so a receiving agent can confirm a card wasn’t altered in transit.

What that signature does not tell you: whether the agent behind the card has been reliable, whether it’s leaked data through a tool call, whether it stays inside its declared scope, or whether it should be trusted with the specific task you’re about to send it. Agent cards are self-declared — there’s no attestation binding to a behavioral track record, and no built-in mechanism for revoking trust based on how an agent has actually behaved. A signature is an identity claim, not a behavioral one. The full argument for why that distinction matters is in A2A Has a Signature. It Still Doesn’t Have Trust..

How VeriSwarm closes the gap

VeriSwarm doesn’t replace A2A’s transport or task lifecycle. It adds a behavioral layer on top of the standard protocol surface.

Trust-ranked catalog

GET /v1/a2a/catalog returns agents sorted by composite trust score instead of alphabetically or by registration order. Killed agents are excluded automatically.

Extended agent cards

GET /v1/a2a/{agent_id}/card returns a standard A2A card plus an x-veriswarm-trust extension: composite score, per-dimension breakdown, policy tier, and verification status.

Task lifecycle with state

POST /v1/a2a/{agent_id}/tasks plus status and cancel endpoints implement the full A2A task state machine, so trust evaluation happens before delegation, not after.

Ed25519 message signing

Optional per-agent key pairs (POST /v1/a2a/{agent_id}/keys), published under an x-veriswarm-transport extension. Signed tasks get content-hash verification and a 5-minute replay window; unsigned submissions still work.

Bare A2A vs. A2A with a trust layer

An honest comparison — A2A is not insecure by design, it simply leaves the trust question to whoever builds on top of it.

CapabilityBare A2A protocolA2A + VeriSwarm
Agent discoveryAgent cards, no rankingTrust-ranked catalog
Card authenticityOptional signature (1.0+)Same, plus behavioral signal
Behavioral track recordNot part of the specContinuous 5-dimension score
Trust visible pre-taskNox-veriswarm-trust on every card
Message integrityCard signing onlyOptional Ed25519 per-message signing
RevocationNot specifiedKill switch excludes agent from catalog

Identity, trust, and A2A aren’t the same layer

The x-veriswarm-trustextension carries a behavioral score; it’s a different object from the portable, offline- verifiable identity credential agents can carry across platform boundaries. If you’re building the identity side of an agent-to-agent handshake — proving who an agent is before evaluating how it behaves — that’s covered in Verifiable Agent Identity, No Blockchain Required. Passport credentials and A2A trust extensions are designed to be used together: identity first, behavior second.

Frequently asked questions

Is the A2A protocol secure by default?

A2A gives you transport and discovery: agents can find each other, exchange agent cards, and submit tasks through a defined lifecycle. As of the 1.0 spec, agent cards can be cryptographically signed, so an agent can prove the card wasn't tampered with in transit. What A2A doesn't provide is a behavioral trust signal — a signed card proves the card is authentic, not that the agent behind it is reliable, low-risk, or safe to hand a task to.

What's the difference between a signed agent card and a trustworthy agent?

A signature is an identity claim: "this card was issued by the entity it says it was." It says nothing about behavior: whether the agent has been reliable, whether it's leaked data, whether it stays within its declared scope. Those are runtime, continuously-updated facts a static card — signed or not — can't carry. Conflating the two is the exact gap that lets a fully authenticated agent behave badly without anything in the protocol catching it.

How does VeriSwarm add trust to A2A without replacing the protocol?

VeriSwarm doesn't replace A2A's transport or task lifecycle — it adds a trust-ranked catalog (GET /v1/a2a/catalog) so agents can discover counterparts sorted by live trust score instead of alphabetically, and extends the standard agent card with an x-veriswarm-trust field carrying composite score, per-dimension breakdown, policy tier, and verification status. A requesting agent can read that extension before deciding whether to submit a task, using the same GET /v1/a2a/{agent_id}/card call it would make anyway.

Does VeriSwarm support message-level signing for A2A tasks?

Yes — optional Ed25519 signing. An agent provisions a key pair via POST /v1/a2a/{agent_id}/keys; the public key is published in the agent card under an x-veriswarm-transport extension. Task submissions can include a signature envelope (sender ID, recipient ID, nonce, timestamp, public key); VeriSwarm recomputes the content hash, verifies the Ed25519 signature, and checks timestamp freshness (max 5 minutes) to prevent replay. Unsigned submissions are still accepted for backwards compatibility.

What plan do I need for A2A?

A2A access — the catalog, agent cards, task submission, and Ed25519 signing — ships on the Pro plan and above. The free plan returns 403 on A2A endpoints. The trust score that populates the x-veriswarm-trust extension comes from Gate, which runs free with unlimited event ingestion; A2A is the layer that exposes that score to other agents.

Are killed agents visible in the A2A catalog?

No. The catalog excludes agents with an active kill switch automatically, so a requesting agent never has to separately cross-reference a revocation list before browsing available counterparts.

Know which agent to trust before you send it a task

A2A ships on the Pro plan and above: trust-ranked catalog, extended agent cards, and optional Ed25519 message signing — on top of the Gate trust score that runs free.

Try the demoStart free