← All Articles

A2A Agent Identity and Trust Framework Proposal

A comprehensive proposal addresses the "who are you?" problem for autonomous agents — proposing verification levels, trust signals, and delegation chain security for the Agent-to-Agent Protocol.

The Problem

The A2A protocol currently recommends TLS certificate validation and allows optional JWS signatures on AgentCards for agent identity. These mechanisms verify the domain hosting an agent but do not verify the agent itself. In a world where autonomous agents delegate tasks to each other, this gap creates serious security concerns:

• No verified agent identity — AgentProvider fields are self-asserted with no verification
• No trust evaluation framework — agents have no standardized way to assess other agents
• No delegation chain security — when Agent A delegates to Agent B who delegates to Agent C, there's no trust propagation or authorization boundaries
• No AgentCard revocation mechanism — compromised agents can't be removed from the ecosystem
• No application-layer message integrity — TLS secures transport but not message content

These aren't edge cases. As A2A moves past 1.0 and into production deployments, these gaps become blockers for enterprises that need to know which agents they're trusting with sensitive operations.

The Proposal: Three Verification Levels

The proposal introduces a tiered verification system that balances accessibility with security:

Level	Verification	Use Case
Self-Asserted	Agent claims identity via AgentCard	Development, testing, low-risk operations
Domain-Verified	DNS/TLS proves domain control	Standard production deployments
Organization-Verified	Third-party attestation of legal entity	Enterprise, financial, healthcare

Consuming agents can set minimum verification requirements based on operation sensitivity. A weather lookup might accept self-asserted; a financial transaction might require organization-verified.

Key Components

1. Standardized Trust Signals

Beyond verification levels, the framework proposes standardized signals that agents can use to evaluate each other:

• Reputation scores — aggregated from past interactions
• Capability attestations — verified claims about what an agent can do
• Compliance certifications — SOC 2, HIPAA, etc.
• Insurance/bonding status — for high-value operations

These signals would be communicated via the existing AgentExtension and metadata fields, maintaining backwards compatibility.

2. Mandatory AgentCard Signing

Currently, JWS signatures on AgentCards are optional. The proposal argues this should flip: unsigned cards would be acceptable only for development/testing.

3. Revocation Endpoints

When an agent is compromised or decommissioned, there's currently no standardized way to revoke its identity. The proposal adds:

• A revocation check endpoint that verifiers can query
• Revocation lists that can be cached for performance
• Grace periods for propagation

4. Delegation Chain Security

When agents delegate tasks to each other, the proposal introduces:

• Authorization boundaries — explicit limits on what delegated agents can do
• Trust propagation rules — how trust flows through delegation chains
• Chain-of-custody tracking — auditable records of delegation paths

This is particularly important for enterprise deployments where a company's agent might delegate to third-party specialists but needs to maintain governance.

5. Message Signing

Beyond AgentCard signing, the proposal adds message-level signing for individual A2A requests and responses. This provides:

• Non-repudiation — proof of who sent what
• Integrity — detection of tampering
• Auditability — cryptographic evidence for compliance

Comparison with UCP Signing

Interestingly, this proposal lands the same day that UCP's message signing specification merged. The approaches share philosophical similarities:

• Both use existing protocol structures (AgentExtension/metadata vs. UCP profiles)
• Both support tiered trust levels
• Both address key discovery and revocation

The key difference: UCP focuses on commerce transactions (agent-to-business), while A2A focuses on agent-to-agent delegation. A complete agentic ecosystem will need both.

Implementation Considerations

The proposal acknowledges several challenges:

• Performance: Verification checks add latency; caching strategies are essential
• Adoption: Existing agents would need upgrades; migration period required
• Governance: Who operates verification authorities? How are disputes resolved?
• Privacy: Trust signals could leak operational information; selective disclosure needed

The full proposal includes design rationale documents addressing these tradeoffs.

What's Next

The proposal is currently open for community discussion. Key questions being debated:

• Should mandatory signing apply only to AgentCards, or extend to all messages?
• What's the right balance between decentralized and centralized verification?
• How should this interact with existing identity systems (DID, OAuth, etc.)?