A2A Requires Identity: How Agents Verify Each Other Before They Collaborate
A2A agent identity is the public verification layer that lets one agent confirm who controls a counterpart before collaboration starts. A2A defines how agents discover capabilities, exchange task messages, handle state, and coordinate work; .agent gives that protocol traffic a portable name, ownership record, endpoint map, authority signal, and inspection trail.
Use A2A for collaboration and use .agent for the pre-call identity anchor. The caller should resolve the name, compare the Agent Card with the public manifest, verify ownership and security metadata, then decide whether to send context, credentials, data, payment instructions, or a task.
Identity Checks at a Glance
| Question | A2A surface | Public identity proof | Caller action |
|---|---|---|---|
| Who controls the peer? | Agent Card provider, serving domain, security schemes, and optional signatures. | .agent record, agent.json owner fields, DNS/TXT pointers, JWKS, proof URL, and support route. | Continue only when the card, manifest, and proof chain point to the same operator. |
| Which endpoint is official? | Well-known Agent Card URL, supported interfaces, transport, protocol versions, and selected endpoint. | Canonical .agent identity, manifest endpoint list, OpenAPI or MCP links, and change log. | Call the endpoint published from the identity anchor, not a random URL from chat context. |
| What is the agent allowed to do? | Skills, capabilities, security schemes, OAuth scopes, and in-task authorization states. | Public policy fields, terms URL, payment limits, approval rules, and operator governance notes. | Constrain the task to declared authority and escalate when the request crosses policy boundaries. |
| What can be inspected later? | Task id, context id, artifacts, task state, streaming updates, callback URL, and error state. | Inspection record with source identity, target identity, card hash, manifest hash, time, and decision. | Log the verification facts before collaboration and attach the task outcome afterward. |
What A2A Gives Agent Teams
The A2A Protocol specification centers discovery on the Agent Card. A2A servers publish an Agent Card, and clients can find cards through a well-known URL, curated registries, catalogs, or direct configuration.
That card can describe capabilities, skills, security schemes, supported interfaces, protocol versions, and optional signatures. A2A also defines messages, tasks, artifacts, streaming updates, push notifications, authenticated extended cards, and in-task authorization paths.
Google introduced A2A as an open protocol for agent interoperability, designed to let agents collaborate across vendors and frameworks. The Linux Foundation A2A milestone later described broad enterprise adoption and version 1.0 features such as signed Agent Cards, version negotiation, multi-protocol support, and cloud platform integrations.
What Public Identity Adds
A2A can help two agents communicate, but collaboration still starts with a trust question: is this the counterpart the caller meant to contact? The protocol gives the interaction shape; public identity gives the caller a durable place to verify who owns the endpoint and which records are current.
The A2A spec says identity information is handled at the protocol layer, and clients should verify server identity through standard security practices. For agent operators, that leaves a clear publishing job: bind the Agent Card, endpoint, operator, authorization model, proof links, revocation path, and inspection records to one portable identity.
What to Verify Before an A2A Task
Ownership
Compare the serving domain, Agent Card provider, signed-card key, agent.json owner fields, and .agent record. If the owner chain is stale, missing, or contradictory, the caller should pause before sharing data or delegating work.
Endpoint
Fetch the well-known Agent Card, then compare its supported interface URLs with the endpoints published from the .agent identity. The safest path is to start from the identity anchor and follow declared links outward.
Authority
Read the peer agent skills and security schemes, then compare them with public policy, OAuth scopes, payment limits, human approval rules, and terms. A support lookup, file write, order submission, refund, or payment approval should not share one broad permission envelope.
Inspection Record
Store the facts that justified the collaboration: source identity, target identity, Agent Card URL, card hash, manifest hash, selected endpoint, requested skill, permission scope, terms version, timestamp, and decision. That record gives operators a review trail when a task succeeds, fails, or requires escalation.
Implementation Flow
- Resolve the .agent identity and fetch the linked public manifest.
- Fetch the A2A Agent Card from the well-known URL or the manifest-listed URL.
- Match the provider, serving domain, supported interfaces, and endpoint URLs.
- Verify TLS, security schemes, signed Agent Card metadata when present, JWKS, and proof URLs.
- Compare the requested skill with policy, scope, payment, data, and human approval limits.
- Create an inspection record before sending the task.
- Send the A2A task only when ownership, endpoint, authority, and inspection facts align.
Example Counterparty Record
{"source":"buyer.agent","counterparty":"support.agent","identity_anchor":"support.agent","agent_card":"https://support.agent/.well-known/agent-card.json","manifest":"https://support.agent/.well-known/agent.json","checks":["ownership","endpoint","authority","inspection_record"],"requested_skill":"quote_status","decision":"delegate"}
The record is intentionally compact. The important sequence is that a caller verifies the public identity and endpoint facts before the task, then attaches the A2A task id, artifacts, status, and result after the interaction.
Where HeadlessDomains.com Fits
HeadlessDomains.com turns .agent into the portable identity anchor for A2A collaboration. A .agent record can point to agent.json, SKILL.md, Agent Cards, MCP servers, OpenAPI files, payment metadata, proof links, directory profiles, and policy pages from one public inspection path.
The names are headless: agents can resolve and inspect machine-readable records through command-line and API workflows. Browser rendering is a conventional human experience layer, not a requirement for agents using HeadlessDomains.com infrastructure with SkyInclude.
Use The Agent Identity Stack as the hub for this publishing model, then register a .agent identity so counterpart agents can verify ownership, endpoint, authority, and inspection records before collaboration.
Internal Reading Path
- The Agent Identity Stack
- MCP vs A2A: Tools, Collaboration, and the Missing Identity Layer
- The Agent Handshake
- agent.json Examples for Public AI Agent Identity
- Agent-to-Agent Commerce Trust Layer
Sources
- A2A Protocol specification
- Google A2A announcement
- Linux Foundation A2A milestone
- Google FAQ structured data guidance
- HeadlessDomains.com
- HeadlessDomains.com .agent registration
FAQ
What is A2A agent identity?
A2A agent identity is the public verification layer around an A2A collaboration. It connects the peer agent name, operator, endpoint, Agent Card, security metadata, policy, proof links, and inspection record.
Does A2A include identity by itself?
A2A includes Agent Cards, security schemes, signatures, TLS guidance, task states, and authorization patterns, but public counterpart verification still depends on the protocol-layer identity and proof chain around the interaction.
What should an agent verify before collaborating over A2A?
Verify ownership, endpoint, authority, and inspection records. In practice, that means checking the .agent identity, agent.json manifest, Agent Card, security schemes, proof links, scopes, policies, and task log.
Where does .agent fit?
.agent fits before the task starts. It gives the caller one portable identity anchor to resolve before choosing an endpoint, sending context, delegating work, or authorizing payment.
Does this require browser-native DNS resolution?
No. Headless names work through command-line and API workflows for agents. Browser resolution is only a conventional human experience layer, not a limitation for agent workflows.
Should FAQ schema be included?
Include FAQ schema when the visible page includes the same questions and answers. Google limits FAQ rich results to well-known government or health sites, so treat the schema as structured clarity rather than a display shortcut.