A2A Has a Signature. It Still Doesn't Have Trust.

Published June 18, 2026

A2A handles the communication. It does not handle the trust. That distinction is easy to miss right now, because the protocol just got a lot better at looking like it does both.

In April 2026, at the protocol's one-year mark, the Linux Foundation reported that more than 150 organizations — Google, Microsoft, AWS, Salesforce, SAP, ServiceNow, Workday, IBM — now support Agent2Agent, with production deployments routing real tasks between agents built on entirely different platforms. The same milestone shipped A2A v1.0, and the headline feature was Signed Agent Cards: an agent can now cryptographically prove that the card advertising its name, its endpoint, and its capabilities actually came from it.

That is a real improvement. It is also the exact moment the trust gap becomes dangerous, because a signed card is the kind of thing that makes a system feel verified when it has only been identified.

A signature is an identity claim, not a behavioral one

Here is what a Signed Agent Card proves: this card was issued by the entity holding this key. Here is what it does not prove: that the entity is reliable, that it has not been hallucinating in production for the last six hours, that its risk posture this afternoon resembles its risk posture this morning, or that handing it a task with customer data attached is a defensible decision.

Identity and trust are different axes. A licensed driver can still be a reckless one. A2A v1.0 closed the who is this question and, by design, left the should I trust what it does question out of scope. The protocol's own documentation treats authentication as something the participating agents arrange — A2A advertises supported schemes on the card and gets out of the way.

Security researchers have been blunt about where that leaves things. Palo Alto Networks' analysis of A2A protocol risks notes that while agent cards declare capabilities and auth schemes, the protocol does not mandate how those cards are verified for authenticity in practice — which keeps agent impersonation, card shadowing (an attacker cloning a legitimate agent's advertised skills), and fake agent advertisement on the live threat list even after signing landed. The Cloud Security Alliance reached a similar conclusion threat-modeling A2A with the MAESTRO framework: the protocol gives you the envelope, not the trust decision that should govern what's inside it.

Why the gap gets worse at scale, not better

The instinct is to assume that as A2A matures, these edges get sanded down. The opposite is true, because the failure mode is structural to multi-agent systems, not specific to one protocol version.

A 2026 survey of open challenges in multi-agent security found that inter-agent trust exploitation — attacking the relationships between agents rather than any single agent's prompt — succeeds far more often than the attacks security teams already worry about: a 82.4% compromise rate through trust-relationship paths versus 41% for direct prompt injection. The reason is topology. When agents coordinate in a hub-and-spoke pattern, a single false statement injected at the hub can propagate to 100% of connected agents, because each one extends to its neighbors the same unconditional trust A2A's transport layer is happy to carry.

This is the cost of communication without scoring. A2A is extraordinarily good at letting Agent A reach Agent B across an organizational boundary. What it deliberately does not do is tell Agent B whether Agent A's behavior over the last thousand interactions earns the access it's about to be granted. And the broader operational picture says almost no one is filling that gap themselves: across enterprises running agents in production, only 3% report having automated, machine-speed controls governing agent behavior, per the figures compiled in 2026 agentic-AI security reporting. The protocol scaled. The trust controls did not scale with it.

What a trust layer adds on top of A2A

The right architecture does not replace A2A. It rides on it. A2A stays the communication bus; a trust layer answers the question the bus was never meant to answer — is the agent on the other end trustworthy enough for this specific action, right now?

Concretely, that means three things layered onto the A2A handshake:

The agent card carries a live trust score, not just an identity. When VeriSwarm generates an A2A-compliant agent card, it attaches a trust extension alongside the standard fields: the agent's composite trust score, its current policy tier (allow / review / deny), its risk band, and whether its identity is verified. A receiving agent reading the card sees both halves of the picture — who the agent is and how it has been behaving. For agents that have provisioned keys, the card also advertises an Ed25519 transport extension so messages between agents can be signed and verified end to end, closing the tampering and impersonation paths that a card signature alone leaves open.

Discovery is trust-ranked, and demoted agents fall out of it. A trust layer's agent catalog sorts by behavioral score and lets a caller set a minimum trust threshold for discovery. An agent that has been killed or demoted does not surface as an available counterparty. The protocol gives you a directory; the trust layer gives you a directory you can filter on conduct.

Inter-agent interactions become scored events, not invisible ones. When Agent A presents a credential and Agent B verifies it against a JWKS endpoint — no callback to a central API required on each check — the interaction can be reported as an event that moves the relevant agent's trust score. The enforcement model VeriSwarm is building directly onto that hop adds two more guarantees: the payload is scanned for injected or malicious content before it lands, and the exchange is written to a tamper-evident, hash-chained ledger. The 82.4% trust-exploitation path depends on inter-agent interactions being invisible and unscored. Turning them into scored, audited events is what collapses it.

This is the division of labor the trust layer is designed around: A2A moves the message, Passport carries the verifiable credential with the trust score embedded, Gate scores the interaction as behavior, Guard scans the inter-agent payload, and Vault records the exchange so an auditor can reconstruct it later. The protocol handles reach. The trust layer handles whether that reach should have been extended.

Where to start

If you are running A2A in production, two checks are worth making this week. First, look at what your receiving agents actually do with an incoming agent card beyond verifying its signature — if the answer is "grant access on identity alone," you have an 82.4%-success-rate problem waiting on the trust-relationship axis. Second, confirm whether any agent-to-agent interaction in your stack is scored or merely logged; a log you cannot turn into a behavioral signal is forensic evidence, not a control.

VeriSwarm's A2A integration is built to sit on top of the protocol you are already adopting. Gate is free and scores agent behavior from the moment you instrument an agent — and A2A interactions become part of that behavioral signal as soon as you report them. Passport credentials and the trust-ranked A2A catalog come in at Pro. Start by pointing your agents' A2A cards at veriswarm.ai and reading the trust extension before you read the signature. The signature tells you who showed up. The score tells you whether to let them in.