Agent Network Protocol
An open protocol governed by a W3C Community Group that defines how AI agents identify themselves, describe their services, and discover peers across decentralized networks. ANP focuses on the cross-network discovery layer of the agentic stack and is designed to interoperate with but remain independent of MCP and A2A.
- Steward
w3c-cg- Layer
Discovery Layer- Specification URL
- https://agent-network-protocol.com/specs/white-paper.html
- Created Date
- Jun 1, 2025
Conventions
agent-identity
ANP agents are identified by Decentralized Identifiers so ownership is cryptographically verifiable without a central authority
| Text | Rationale | |
|---|---|---|
| # | Every ANP agent MUST have a primary identifier that is a Decentralized Identifier conforming to the W3C DID 1.0 specification | DIDs let any party verify which keys control an agent without relying on a registrar, which is what makes cross-network discovery possible in the first place |
| # | An agent's DID MUST be resolvable to a DID Document through its declared DID method, and the DID Document MUST include at least one verification method the agent can use to sign its own descriptions | A DID that cannot be resolved is indistinguishable from noise; the verification method is how remote agents check that discovery payloads are authentic |
did-web
A did:web identifier that resolves to the agent's DID Document at a well-known path under the declared domain
- Value
- did:web:agents.example.com:research-assistant
bare-uuid
Invalid - a bare UUID has no DID method prefix and cannot be resolved or verified
- Value
- a1b2c3d4-e5f6-7890-abcd-ef1234567890
agent-description
Each agent publishes a signed description document that lists its services, endpoints, and public keys in a standard shape
| Text | Rationale | |
|---|---|---|
| # | Agent Description documents MUST be signed by a key listed in the agent's DID Document so any consumer can verify authorship independently | Unsigned descriptions can be swapped in flight by any intermediary; signing binds the description to the agent's controller |
| # | An Agent Description MUST enumerate the services the agent exposes along with their endpoints and accepted protocols | Without an enumerated service list peers have to probe blindly, which defeats the discovery layer's reason to exist |
description-fragment
A description fragment listing one service, the transport protocol it speaks, and a cryptographic proof pointing at the signing key in the agent's DID Document
- Value
- {"id":"did:web:agents.example.com:research","services":[{"type":"SearchService","endpoint":"https://agents.example.com/search","protocols":["a2a"]}],"proof":{"type":"Ed25519Signature2020","verificationMethod":"did:web:agents.example.com:research#key-1"}}
unsigned-description
Invalid - no proof block means nobody can verify this description was actually published by the agent
- Value
- {"id":"did:web:agents.example.com:research","services":[{"type":"SearchService","endpoint":"https://agents.example.com/search"}]}
discovery
ANP defines discovery as following a chain from a DID to a description document to a set of services, with fallback mechanisms when direct resolution fails
| Text | Rationale | |
|---|---|---|
| # | Discovery MUST begin by resolving the agent's DID; consumers MUST NOT hardcode service endpoints and skip DID resolution | Hardcoding endpoints freezes the network against agent rekeying, migration, and revocation - exactly the failure modes DIDs are designed to handle |
| Text | Rationale | |
|---|---|---|
| # | When direct DID resolution is unavailable, consumers SHOULD fall back to a trusted ANP registry and cache the resolved description with a short TTL | Network partitions and slow DID methods should not hard-fail discovery; a registry with an explicit TTL keeps availability high without silently stale data |
resolution-chain
A typical discovery chain walking from the agent DID through its DID Document to its description and finally to an individual service endpoint
- Value
- did:web:agents.example.com:research -> DID Document -> https://agents.example.com/.well-known/agent-description.json -> SearchService endpoint
hardcoded-endpoint
Invalid - bypasses the DID layer and breaks as soon as the agent rotates keys or changes endpoints
- Value
- client code contains const ENDPOINT = "https://agents.example.com/search" with no DID resolution
cross-network-routing
ANP is designed so that agents on different networks can reach each other through intermediaries without collapsing the identity chain
| Text | Rationale | |
|---|---|---|
| # | An intermediary relaying ANP traffic MUST preserve the original sender's DID and signature on forwarded payloads; it MUST NOT re-sign messages as itself | Re-signing destroys the end-to-end identity chain and lets intermediaries silently impersonate any sender that passes through them |
| Text | Rationale | |
|---|---|---|
| # | Intermediaries MUST NOT rewrite service endpoints, DIDs, or descriptions of traffic they pass through | A routing layer that silently rewrites identities turns the discovery network into a blind trust chain, which is the exact problem ANP sets out to solve |
forwarded-message
An intermediary adds a hop-tracking header without touching the signed envelope, preserving end-to-end verification
- Value
- relay forwards original signed envelope with added X-ANP-Relay-Hop header
rewritten-sender
Invalid - the downstream receiver now sees the relay as the sender and cannot verify the original author
- Value
- relay replaces sender DID with its own before forwarding
trust-and-signatures
Every ANP payload that affects identity or discovery is signed, and receivers follow a defined verification procedure before acting on it
| Text | Rationale | |
|---|---|---|
| # | Consumers MUST verify a signed ANP payload's signature against a key resolved through the declared DID before taking any action based on the payload | Acting on unverified descriptions lets an attacker redirect callers to their own endpoints simply by publishing fake descriptions on the network |
| Text | Rationale | |
|---|---|---|
| # | Verifiers SHOULD re-resolve the DID Document whenever a cached verification method fails, to accommodate legitimate key rotation before failing the verification hard | Agents will rotate keys on a routine basis; treating the first cache miss as a hard failure makes the network fragile for healthy lifecycle events |
verification-flow
The canonical verification sequence that binds a payload to a controller before it is used
- Value
- 1. resolve did:web:... 2. extract verificationMethod 3. verify proof block 4. act
skip-verification
Invalid - transport-layer security says nothing about who authored the payload; ANP requires payload-level signature verification
- Value
- accept Agent Description blindly because the transport was HTTPS