← All Articles

A2A Agent Identity Layer Proposals: WTRMRK and Cross-Org Accountability

A2A Identity Trust Proposal

April 4, 2026 · Issues #1712 and #1713

Two significant proposals dropped this week addressing how A2A agents establish trust when communicating across organizational boundaries. As multi-agent systems proliferate, the question of agent identity becomes critical: how does Agent A know Agent B is who it claims to be, and how do we hold agents accountable for their actions?

The Problem Space

A2A Protocol v1.0 provides communication primitives but leaves identity largely to implementers. This works within a single organization where you control all agents, but falls apart in federated scenarios:

First-contact transactions: Agent A (your travel agent) needs to negotiate with Agent B (an airline's booking agent) with no prior relationship
Accountability gaps: If Agent B misbehaves, how does Agent A's organization pursue recourse?
Impersonation risks: How do you verify an agent claiming to represent "Delta Airlines" is actually authorized?

Proposal 1: WTRMRK as a Trust Primitive

Issue #1712 — 64R3N

Proposes using WTRMRK (watermarking) technology as a foundational trust primitive for A2A agent identity verification.

The WTRMRK proposal suggests embedding cryptographic watermarks into agent responses that can be verified by receiving agents. Key concepts:

Watermark Embedding

Agents embed imperceptible signatures in their outputs — not just text, but across modalities including generated images, structured data, and even behavioral patterns:

{
  "agent_card": {
    "id": "urn:a2a:agent:delta-booking-v2",
    "wtrmrk": {
      "algorithm": "WTRMRK-v1",
      "verification_endpoint": "https://verify.delta.com/.well-known/wtrmrk",
      "embedded_signals": ["text", "structured_response", "timing"]
    }
  }
}

Verification Flow

Receiving agent extracts watermark signals from response
Verification request sent to declared endpoint
Endpoint confirms watermark validity and agent authorization
Trust score computed based on verification success

Strengths and Limitations

Pro: Works across any response modality
Pro: Difficult to forge without access to watermarking keys
Con: Requires watermarking infrastructure at each organization
Con: Verification latency adds to transaction time

Proposal 2: Cross-Org Accountability Layer

Issue #1713 — kevin-biot

Addresses accountability for first-contact A2A transactions when organizations don't share an Authorization Server.

This proposal focuses less on identity verification and more on creating enforceable accountability trails:

Accountability Registry

A federated registry where organizations publish:

Agent manifests with authorized capabilities
Dispute resolution contacts
Insurance/bonding information
Historical behavior scores

Transaction Receipts

Every cross-org A2A transaction generates a cryptographically signed receipt:

{
  "transaction_id": "txn_abc123",
  "initiator": "urn:a2a:agent:my-travel-agent",
  "responder": "urn:a2a:agent:delta-booking-v2",
  "timestamp": "2026-04-04T15:30:00Z",
  "operation": "flight_booking_request",
  "result_hash": "sha256:...",
  "signatures": {
    "initiator_sig": "...",
    "responder_sig": "..."
  }
}

Dispute Resolution Path

When issues arise:

Aggrieved party submits receipt to accountability registry
Registry notifies responsible organization
30-day resolution window
Unresolved disputes affect public trust scores

Comparing the Approaches

Aspect	WTRMRK (#1712)	Accountability Layer (#1713)
Focus	Identity verification	Post-transaction accountability
Timing	Real-time verification	Asynchronous resolution
Infrastructure	Per-org watermarking	Federated registry
Trust Model	Cryptographic proof	Reputation-based

💡 These Proposals Are Complementary

WTRMRK provides real-time identity verification ("this agent is authorized by Delta"). The accountability layer provides recourse when things go wrong ("Delta's agent double-booked me"). A complete trust framework likely needs both.

Implications for Agent Developers

If either proposal gains traction:

Agent Cards will evolve: Expect new fields for trust primitive declarations
Transaction logging becomes mandatory: Keep immutable logs of all cross-org A2A exchanges
Trust verification overhead: Budget for additional latency in multi-agent workflows
Insurance requirements: Enterprise deployments may require bonding for high-value agent operations

What's Next

Both proposals are in early discussion. The A2A TSC has not yet scheduled formal review, but the timing — shortly after v1.0 release — suggests identity/trust will be a major focus for v1.1 or a dedicated extension.

For now, implementers building cross-org A2A systems should:

Design with identity verification in mind (even if mechanisms evolve)
Log all cross-org transactions with sufficient detail for future accountability
Monitor these issues for TSC direction