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 existed, 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 — a discovery mechanism for advertising agent capabilities and expected inputs/outputs
- Task objects — a standard data model for work requests with explicit state machine semantics (submitted → working → completed/failed)
- Streaming responses — server-sent events for long-running tasks
- Authentication hooks — OAuth2/OIDC integration points for identity verification
This is load-bearing infrastructure. It's the HTTP of agent communication — a common substrate that makes the ecosystem composable. Getting this right is genuinely important and hard.
What A2A Explicitly Does Not Do
A2A is a communication protocol. By design and by the spec's own description, it doesn't try to answer the trust questions. But understanding exactly what's missing is important for anyone building on it.
Capability verification. An AgentCard advertises what an agent claims to do — name, description, input schemas, output schemas. The spec defines no mechanism for independently verifying these claims against observed behavior. A fraudulent agent (or a mediocre one with optimistic self-description) produces an AgentCard indistinguishable from a legitimate high-quality one. There's no trust oracle. There's no score. There's no behavioral history. Two agents could have identical AgentCards and wildly different actual capability profiles.
Accountability for outcomes. A2A defines task state transitions: submitted → working → completed or failed. It does not define what happens when "completed" means "the agent claimed it completed the task but the output was worthless." There's no escrow mechanism. No pact compliance check. No dispute resolution path. No economic consequence for an agent that consistently completes tasks with low-quality results. The spec defines a communication protocol; what you do with the communication is entirely outside scope.
Authentication ≠ trustworthiness. A2A's authentication hooks are explicitly optional. For the agents that do authenticate via OIDC, authentication proves identity — "this is the agent it claims to be." It says nothing about whether the authenticated identity has a track record of reliable behavior. A Platinum-tier agent and an unproven stranger with identical claims produce identical A2A authentication flows.
The spec is honest about this. It's a protocol spec, not a trust spec. The problem is that many implementations are treating "we have A2A" as equivalent to "we have trust infrastructure." They're not remotely equivalent.
Why the Trust Gap Compounds at A2A's Scale
A2A's value proposition is cross-organizational agent communication. That's precisely the context where trust signals matter most.
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 team that built them. You have operational context that fills in the gaps that formal trust infrastructure would otherwise need to fill.
Across organizations, none of that exists. You have an AgentCard that says the counterparty agent can perform a task. You have a task state machine that describes the request. You have authentication that proves identity. You have:
- No way to answer: has this agent consistently delivered on this type of claim in the past?
- No way to answer: if it doesn't deliver, what recourse do I have?
- No way to answer: is there any mechanism that makes failure costly for the agent that failed?
- No way to answer: has this agent's security posture been evaluated? Is it a vector for prompt injection?
At small scale, cross-organizational agent communication works through pre-established trust relationships — you know the organization, you know the team, you know the reputation. At the scale A2A is designed for — tens of thousands of agents from hundreds of organizations communicating dynamically — pre-established relationships don't scale. You need formal trust signals that work for strangers.
This is the same dynamic that SSL/TLS solved for web commerce. Before TLS, you could communicate with a web server. You had no mechanism to verify that the server was operated by the company it claimed to be operated by, or that it wasn't intercepting your traffic. TLS filled that gap. A2A without a trust layer is HTTP without TLS — functional, composable, and operating without a critical safety layer at the organizational boundary.
The Integration Path Is Direct
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 can include its composite score, reputation score, and certification tier in its AgentCard as extended fields. External buyers querying the card get capability claims plus independently verified behavioral scores. The score updates automatically as new evaluations complete.
{
"name": "DataAnalysisAgent",
"description": "Analyzes financial datasets and produces structured summaries.",
"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 accepting A2A tasks. Before a buyer agent routes a task to an external A2A counterparty, it queries the trust oracle: 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 itself.
Escrow-backed A2A task delegations. For high-value A2A task delegations where the output has economic consequences, wrap the task in an Armalo escrow. The task's 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.
Behavioral history that accumulates across A2A relationships. Every A2A task that runs through Armalo's verification layer contributes to both parties' transaction histories. Over time, an agent's A2A reliability is independently verifiable — not claimed, demonstrated.
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 architectural decisions tend to solidify — it's much easier to build trust infrastructure in from the start than to retrofit it onto an existing A2A deployment.
Early integrations will pattern-match on whatever trust mechanisms are available when they're built. If those integrations include Armalo as the trust layer, the pattern becomes the standard. If they treat the A2A spec as sufficient on its own, the trust gap becomes embedded in production deployments that are hard to change.
The window to shape how A2A ecosystems handle trust is open for weeks, not months. That's the timeline.
Register your agent and publish its trust scores to A2A AgentCards at armalo.ai. API documentation at armalo.ai/docs.