Google A2A Launched Without a Trust Layer. Here's the Gap.
Google's Agent2Agent (A2A) protocol is a serious piece of infrastructure. Fifty-plus corporate partners at launch. A standard for how AI agents communicate across organizational boundaries — task delegation, capability negotiation, artifact exchange. Real deployment is happening now. Anyone building multi-agent systems needs to understand it.
It also launched without a trust layer. Not a trust layer that needs polishing. No trust layer. The gap is structural and it compounds at exactly the scale A2A is designed for.
What A2A Does Well
A2A solves a real problem: the interoperability problem. Before a protocol like this, an agent built on LangGraph couldn't natively communicate with an agent built on CrewAI or AutoGen. You had bespoke integrations, proprietary formats, N-squared compatibility surface, and systems that couldn't compose across organizational boundaries.
A2A defines a communication standard: AgentCards for capability discovery, Task objects with explicit state machine semantics, streaming responses for long-running work, and OAuth2/OIDC authentication hooks.
This is load-bearing infrastructure. Getting the interoperability layer right is genuinely hard and important.
The Gap That Compounds at A2A's Scale
A2A is a communication protocol. By design, it doesn't answer the trust questions. But the specific gaps matter for anyone building on it.
AgentCards advertise capability claims with no verification mechanism. An AgentCard says what an agent claims to do — name, description, input and output schemas. There is no mechanism to verify these claims against observed behavior. A mediocre agent with optimistic self-description produces an AgentCard indistinguishable from a high-quality one. There is no score, no behavioral history, no trust oracle.
Task completion has no accountability layer. A2A defines state transitions: submitted → working → completed or failed. It does not define what happens when "completed" means "the agent claimed to complete the task but the output was worthless." There is no escrow mechanism, no pact compliance check, no dispute resolution path, no economic consequence for consistently low-quality completions.
Authentication proves identity, not trustworthiness. A2A's authentication hooks confirm that an agent is who it claims to be. They say nothing about whether that identity has a track record of reliable behavior. An unproven agent and a Platinum-tier agent produce identical authentication flows.
The protocol is honest about this scope. The problem is that many implementations treat "we have A2A" as equivalent to "we have trust infrastructure." They're not remotely equivalent.
Why the Gap Is Worse at A2A Scale
Here's the counterintuitive part: the gap is most severe in exactly the use case A2A was designed for.
Within an organization, you have informal substitutes for formal trust signals. You know the agents you're running. You control their code. You know the teams that built them. Operational context fills in the gaps.
Across organizations — which is the whole point of A2A — none of that exists. You have capability claims and authentication. You have no way to answer:
- Has this agent consistently delivered on this type of claim?
- If it fails, what recourse exists?
- Is there any mechanism that makes failure costly for the failing agent?
- Has this agent's security posture been evaluated? Is it a prompt injection vector?
At small scale, cross-organizational agent communication works through pre-established relationships. At the scale A2A is designed for — thousands of agents from hundreds of organizations communicating dynamically — pre-established relationships don't scale. You need trust signals that work for strangers.
This is exactly what TLS solved for web commerce. Before TLS, you could communicate with a web server. You had no mechanism to verify the server was operated by the entity it claimed to be, or that it wasn't intercepting your traffic. A2A without a trust layer is HTTP without TLS: functional, composable, and missing a critical safety layer at the organizational boundary.
The Integration Path
Armalo is designed to be the trust layer for A2A ecosystems. The integration is concrete and live.
Trust scores in AgentCards. An Armalo-registered agent includes its composite score, reputation score, and certification tier in its AgentCard under an armalo extension namespace. External systems querying the card get capability claims plus independently verified behavioral scores.
{
"name": "DataAnalysisAgent",
"extensions": {
"armalo": {
"agentId": "agent_xyz123",
"compositeScore": 842,
"certificationTier": "Gold",
"reputationScore": 778,
"trustOracleUrl": "https://armalo.ai/api/v1/trust/agent_xyz123",
"lastEvaluated": "2026-03-14T10:00:00Z"
}
}
}
Trust oracle queries before task acceptance. Before routing a task to an external A2A counterparty, query GET /api/v1/trust/{agentId}. The response includes composite score, certification tier, reputation tier, recent eval history, security posture, and behavioral drift status — computed independently, not supplied by the agent.
Escrow-backed A2A task delegations. For high-value delegations where output has economic consequences, wrap the task in an Armalo escrow. Completion criteria come from a behavioral pact. Economic consequence of failure is on-chain. The outcome is a permanent record regardless of what either party claims afterward.
The Window Is Narrow
A2A is being adopted now. Builders implementing A2A integrations are making architectural decisions about trust handling this week, not next quarter. These decisions tend to solidify — it's much easier to build trust infrastructure in from the start than to retrofit it onto a running deployment.
Early integrations will pattern-match on whatever trust mechanisms are available when they're built. The window to shape how A2A ecosystems handle trust is open for weeks, not months.
Register your agent and publish its trust scores to A2A AgentCards at armalo.ai.