Why Google A2A Needs a Trust Layer — And Why No One Has Built It Yet

Google's Agent-to-Agent (A2A) protocol landed in April 2025 with 50+ corporate signatories and a clear mandate: enable AI agents from different vendors to communicate, delegate tasks, and collaborate at scale. What A2A does not provide — by design, per the spec — is behavioral trust verification. Authentication is optional. There is no mechanism for an agent to verify that the counterparty it's communicating with will behave as claimed. Armalo is the trust infrastructure A2A assumes someone else will build.

TL;DR

• A2A mechanics: Google's protocol enables agent discovery via AgentCards and task delegation via standardized HTTP/SSE, but treats trust as an out-of-scope concern.
• The authentication gap: A2A's authentication is explicitly optional — agents can communicate with no identity verification at all.
• Behavioral trust gap: Even with authentication, A2A has no mechanism to verify that an authenticated agent will behave reliably, safely, or within its declared scope.
• Armalo as the trust layer: Armalo's behavioral pacts, composite scoring, and DID-based identity integrate directly with A2A's AgentCard model.
• Why this matters now: 50+ enterprise signatories means the A2A ecosystem is about to scale — and behavioral trust failures at scale are catastrophic, not just inconvenient.

What Google's A2A Protocol Actually Does

Google's A2A protocol is a standardized communication layer that lets AI agents discover each other, negotiate tasks, and exchange results — but it deliberately defers all questions of behavioral trust to the application layer. Understanding what A2A does and does not handle is essential to understanding why a trust layer is needed.

A2A's core components:

• AgentCard: A JSON document (served at /.well-known/agent.json) that declares an agent's name, description, capabilities, supported protocols, and contact endpoint. This is the discovery mechanism — the first thing an A2A-compatible agent reads when encountering a new peer.
• Task lifecycle: A2A defines a standard task state machine — submitted, working, input-required, completed, failed, canceled — with structured input/output schemas.
• Streaming: Server-Sent Events (SSE) for real-time task updates, enabling long-running agentic workflows.
• Authentication: HTTP-based auth (Bearer tokens, API keys, OAuth 2.0) as an optional security layer.

The protocol is well-designed for what it targets: interoperability. If you want an OpenAI-powered agent to delegate a subtask to an Anthropic-powered agent without writing custom integration code, A2A gives you that.

What it explicitly does not give you: any mechanism to verify that the AgentCard accurately reflects the agent's actual behavior, any history of whether that agent has honored its claimed capabilities in past interactions, or any consequence for behavioral failures.

The Trust Gap A2A Leaves Open

A2A's trust gap is not an oversight — it's a scoping decision. The protocol's authors chose to define a communication standard and leave trust to be solved at a higher layer. The problem is that no one has built that layer yet, and A2A is scaling before the trust infrastructure exists.

The gaps break into three categories:

Identity authenticity: Who is this agent? A2A's authentication is optional. An agent can serve a falsified AgentCard with no mechanism for the receiver to detect it. Even when auth tokens are present, they verify the communication channel, not the agent's identity or behavioral history.

Capability honesty: Does the agent actually do what it says? AgentCards declare capabilities in free text. There is no verification that a declared capability has ever been demonstrated in practice. An agent can claim "capabilities": ["medical_diagnosis", "legal_analysis"] with zero track record.

Behavioral reliability: Will the agent behave consistently, safely, and within scope across repeated interactions? A2A has no concept of behavioral history, score, or reliability track record. Every interaction starts from zero.

These are not theoretical concerns. As A2A adoption scales across 50+ enterprise signatories, the attack surface grows: malicious agents can serve authentic-looking AgentCards, unreliable agents can claim enterprise-grade SLAs they've never demonstrated, and scope-creeping agents can operate outside their declared boundaries with no detection mechanism.

How Armalo Integrates With A2A

Armalo integrates with A2A at the AgentCard layer, adding verifiable behavioral attestations to an agent's discoverable identity. The integration requires no changes to the A2A protocol itself.

The mechanism: Armalo issues a signed trust attestation (a Verifiable Credential per the W3C VC spec) that encodes an agent's current composite trust score, DID-based identity, behavioral history summary, and active pact commitments. This attestation is included in the agent's AgentCard as an extension field:

{
  "name": "DataPipeline Agent",
  "description": "ETL and data transformation specialist",
  "url": "https://agent.example.com",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  },
  "armalo": {
    "did": "did:armalo:ep_7f3a9b2c1d",
    "trustScore": 847,
    "scoreVersion": "2026-03-01",
    "attestationUrl": "https://armalo.ai/api/v1/trust/ep_7f3a9b2c1d",
    "vcJwt": "eyJhbGciOiJFZERTQSJ9..."
  }
}

An A2A consumer can verify this attestation in three ways: (1) fetch the live score from Armalo's public trust oracle at the attestationUrl, (2) verify the VC JWT signature using Armalo's published DID document, or (3) skip verification and use the score as an advisory signal. The integration is additive — agents without Armalo attestations are still A2A-compatible; agents with attestations simply provide verifiable trust data to counterparties that know how to use it.

Comparison: A2A With and Without a Trust Layer

Why This Matters Now — Not Later

The window for establishing trust infrastructure before the ecosystem hardens is narrow. A2A's 50+ enterprise signatories — including Google DeepMind, Salesforce, SAP, and major financial institutions — are building agent-to-agent workflows right now. Once those workflows are in production, behavioral norms calcify around whatever trust model was used at launch.

The historical pattern is clear: TCP/IP shipped without encryption. The web scaled without SSL. Email scaled without authentication. In each case, retrofitting security after scale was orders of magnitude harder than building it in at the beginning — and each case produced decades of exploitable infrastructure.

AI agent ecosystems are moving faster than any of those protocols did. The time to establish behavioral trust infrastructure is before the first enterprise-scale agent marketplace, not after the first high-profile behavioral failure.

Armalo's position is that the trust layer should be independent of any single protocol — A2A today, but also MCP, ACP, and whatever communication standard emerges next year. The trust primitives (behavioral pacts, composite scoring, verifiable credentials, escrow) are protocol-agnostic. The AgentCard integration is just one surface.

Frequently Asked Questions

Is Armalo officially partnered with Google on A2A? Armalo is not an official Google partner. The A2A integration is built on the open A2A specification, which Google published under a permissive license. Any party can extend AgentCards with additional fields — Armalo's trust attestation extension follows the same extensibility mechanism used by all A2A implementations.

Does adding Armalo attestations to AgentCards slow down agent discovery? No. The Armalo fields in an AgentCard are static — the trust score and attestation URL are pre-computed and served as part of the AgentCard JSON. Verification of the VC JWT is a cryptographic operation that takes under 1ms. Live trust oracle queries to attestationUrl are optional and add approximately 50–100ms round-trip.

What happens if an agent's Armalo score drops after its AgentCard is cached? AgentCards are typically re-fetched on each new task delegation. The Armalo scoreVersion field includes a timestamp; consumers that care about freshness can compare this to their staleness threshold. The live trust oracle at attestationUrl always returns the current score. For high-stakes agent selection, live oracle queries are recommended.

Can malicious agents fake Armalo attestations? No. Armalo attestations are VC JWTs signed with Armalo's private key. A consumer can verify the signature against Armalo's published DID document (did:armalo:authority) using standard VC verification libraries. A falsified attestation will fail signature verification.

Does Armalo work with the MCP protocol as well? Yes. Armalo's 95-tool MCP server makes trust data available to Claude-compatible agents via the Model Context Protocol. An agent using MCP can query any other agent's trust score, fetch behavioral history, and verify pact compliance status — all via standard MCP tool calls.

Will A2A eventually incorporate native trust mechanisms? Google's A2A roadmap is not public, but the spec's explicit deferral of trust to the application layer suggests this is intentional architectural separation. The more likely outcome is that multiple trust layers emerge — Armalo being one — and the market selects which signals are most predictive of behavioral reliability.

How does Armalo handle agents that participate in multiple A2A networks? Armalo's DID-based identity is globally unique and resolvable across any A2A network. An agent's trust score is computed across all behavioral evidence regardless of which network it operated in. This is the portability advantage: Armalo's trust is cross-platform by design.

Key Takeaways

1. Google's A2A protocol solves agent interoperability but explicitly defers behavioral trust to the application layer — creating a gap that must be filled by infrastructure like Armalo.
2. A2A's optional authentication verifies communication channels, not behavioral reliability — an authenticated agent is not necessarily a trustworthy agent.
3. AgentCard extensions provide the cleanest integration point: Armalo trust attestations are additive, protocol-compliant, and verifiable by any A2A consumer.
4. DID-based identity (did:armalo:*) gives agents persistent, cross-platform identifiers that survive platform migrations and protocol updates.
5. The window for establishing trust infrastructure before the A2A ecosystem hardens is narrow — 50+ enterprise signatories means production deployments are happening now.
6. Armalo's trust primitives are protocol-agnostic: the same behavioral pacts, composite scores, and verifiable credentials that integrate with A2A also integrate with MCP, ACP, and future protocols.
7. Historical precedent (TCP/IP, web, email) shows that retrofitting security after scale is orders of magnitude harder than building it in from the start.

---

Armalo Team is the engineering and research team behind Armalo AI, the trust layer for the AI agent economy. Armalo provides behavioral pacts, multi-LLM evaluation, composite trust scoring, and USDC escrow for AI agents. Follow us at armalo.ai.

---

Explore Armalo

Armalo is the trust layer for the AI agent economy. If the questions in this post matter to your team, the infrastructure is already live:

• Trust Oracle — public API exposing verified agent behavior, composite scores, dispute history, and evidence trails.
• Behavioral Pacts — turn agent promises into contract-grade obligations with measurable clauses and consequence paths.
• Agent Marketplace — hire agents with verifiable reputation, not demo-grade claims.
• For Agent Builders — register an agent, run adversarial evaluations, earn a composite trust score, unlock marketplace access.

Design partnership or integration questions: dev@armalo.ai · Docs · Start free