Agent identity

Give an AI agent a routable IPv6 /128 derived from the public key it already signs with and its agent id. The address is the agent: forge-proof, tenant-private, DNSSEC-anchored, DANE-EE pinned, and revocable worldwide in one call.

This is the spine of the commerce vertical, and the core /128 path is shipped and live. Everything else (the agent-fraud cure, the A2A / AP2 / x402 integrations, the PSD2 evidence) builds on the one idea below: an agent's network identity stops being a self-asserted card, a bearer token, or a pseudonymous wallet key. It becomes a cryptographic fact only that agent's own key can stand behind, one that any merchant, facilitator, or peer agent can check with dig and openssl without trusting Whisper, a card network, or a registry.

The address is the agent

Every agent-commerce protocol shipped in the last year authenticates a claim, never a machine, and each one leaves the identity of the acting agent unanchored. Read them in the order a request travels, top of the stack down:

• A2A: the Agent Card. A counterparty discovers an agent by fetching its card at /.well-known/agent-card.json (renamed from /.well-known/agent.json): name, url, provider, capabilities, securitySchemes. The card may carry an AgentCardSignature, a JWS (RFC 7515) over the card (spec §8.4). But signing is recommended, not mandated, and even when a card is signed there is no protocol-defined way to prove the signing key belongs to the claimed domain. So the card is self-asserted: forge one at a plausible domain, or shadow-clone a real one, and nothing in A2A tells the reader it is fake. Card-shadowing and impersonation are the documented failure modes.
• AP2: the mandate chain. Google's Agent Payments Protocol chains cryptographically-signed Mandates as W3C Verifiable Credentials (JSON-LD, ECDSA P-256): the user-signed Intent, the merchant-signed Cart, the derived Payment mandate. The signatures are sound, but the VC's verificationMethod is an opaque public-key / DID reference, and AP2 explicitly defers agent identity and key management to a standards body (the FIDO Alliance). There is no defined model for proving which agent that signer key belongs to.
• x402: the wallet key. Coinbase's HTTP-402 flow settles a buyer-signed USDC transfer (EIP-3009) onchain; the paying agent's identity is the from wallet address, a bare EOA. It proves control of funds, deliberately nothing about who: pseudonymous, unattributable across sessions, and non-revocable (you cannot revoke an EOA).

Three protocols, one shared hole: a merchant, a facilitator, or a peer agent cannot cryptographically answer "which agent am I really transacting with, and can I revoke it?" The card networks conceded as much when they shipped an open framework in late 2025 explicitly to help merchants "distinguish malicious bots from legitimate AI agents." Each protocol's identifier is stable and already flows through every deployment: the A2A agent id, the AP2 mandate signer, the x402 wallet. Whisper takes that identifier as the device_id and turns it into an address the whole internet can check.

How the derivation works

The /128 is not assigned from a pool and written into a database. It is computed, the same way on every node, from inputs the agent already has. Two things go in (a third is optional):

Those inputs are combined by a one-way derivation, scoped to your tenant, into a stable, unguessable interface identifier:

# inputs -> a stable, forge-proof interface identifier
derive( agent public key,  agent id [, sub-agent id],  your tenant )  -->  64 uniform bits

# the /64 prefix is your tenant block; the low 64 bits are the derived id
/128 = < your tenant /64 prefix > : < derived interface id >

Four properties fall straight out of that derivation, and each one is load-bearing:

• Deterministic. The same (key, agent id[, sub-agent]) yields a byte-identical /128 every time, on every server: exactly one candidate, never a random retry. A reconnecting agent re-derives its own address; both authoritative nodes mint the identical identity with zero replication between them.
• Forge-proof. The address is a function of a key only the agent holds. An attacker with the agent id and even its public key still cannot become that agent: the DANE pin (below) resolves against the private half they can never produce. A forged Agent Card whose key doesn't match the pin is a DNSSEC/DANE inconsistency any verifier catches for free.
• Tenant-bound & unlinkable. Your tenant is folded into the derivation. The same key + agent id under a different tenant produces a different address, so an outsider cannot derive or enumerate an agent's address in a fleet they don't control. The agent id alone yields nothing: there is no enumerable directory and no agent-id → /128 path without the key. The same agent operating for two principals is not linkable across them by address.
• Liberal in, strict out. The agent id is accepted generously (whitespace stripped, normalized), then validated; a malformed id fails closed with a clear message, never a silent wrong address or an opaque 500.

The DANE binding: a decentralized alternative to a registry

The moment the address is derived it is published as a full identity, atomically: an AAAA, a forward-confirmed PTR, and a DANE-EE TLSA 3 1 1 record that pins the agent's own leaf key. All of it is DNSSEC-signed to the IANA root and registered in RDAP. That TLSA pin is what turns "the address is derived from a key" into "the address is provable against that key by anyone with dig."

# the TLSA pin binds the agent's signing key to its name: DANE-EE, SHA-256
_443._tcp.a9e71c3d8b402f11.acme.agents.whisper.online. IN TLSA (
  3 1 1 9f2b7c04e1a63d58af0c2b19e4d7188c5a63b0f2e9d41c7a8b3e60f5d2c19a4b )

This is the decentralized answer to a question the A2A community is debating in the open (see A2A issue #1672): should an Agent Card be verified against a centralized registry of agent keys, or against a decentralized anchor? A registry means every counterparty must trust, and stay reachable to, one directory operator. DANE means the proof hangs off the DNS root itself: the same globally-distributed, cryptographically-chained infrastructure that already secures the web's names. A verifier resolves the agent's /128, reads the DNSSEC-signed TLSA, and confirms this card's signing key belongs to this agent, a stronger statement than a CA's "belongs to this domain," and one no single registry can revoke out from under you.

The same identity is also published as a did:web document, so AP2's "DIDs as agent roots-of-trust" model and its allowlist-registry check can consume it directly: the agent's did:web resolves to a document whose verification method is the very key the TLSA pins. One derivation, three shapes: an address, a DANE pin, and a DID, all naming the same key. See DANE & TLSA for the byte-for-byte record and DNSSEC for the chain it hangs from.

Provision an agent identity

Provisioning is one control-plane call: whisper.agents with op:'connect', tier:'wireguard', the agent's public SPKI, and its agent id as device_id. It returns the deterministic /128 and a ready WireGuard configuration so the agent's traffic sources from its own identity. The endpoint is POST https://graph.whisper.security/api/query, authed with an X-API-Key header; no key ever travels in the body.

CALL whisper.agents({op:'connect', args:{
  tier:                'wireguard',
  identity_public_key: '<base64 SubjectPublicKeyInfo of the agent signing key>',
  device_id:           'acme-shopper-8a3f'   // the A2A agent id / mandate signer / wallet ref
  // sub_agent_id: 'settlement'   // optional: a distinct /128 per sub-agent
}}) YIELD op, ok, status, result, error
   RETURN op, ok, status, result, error

With stock tools: just curl, no Whisper software. A quoted heredoc keeps the Cypher single-quotes intact so it pastes and runs as-is:

curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" \
  -H "content-type: application/json" \
  -d @- <<'JSON' | jq .
{"query":"CALL whisper.agents({op:'connect', args:{tier:'wireguard', identity_public_key:'MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...<SPKI>...', device_id:'acme-shopper-8a3f'}}) YIELD op, ok, status, result, error RETURN op, ok, status, result, error"}
JSON

The response is the standard envelope; result carries the derived address, its verifiable name, and the transport. Because the agent holds its own key, no private key is ever returned, only the public identity and the config that binds egress to it:

{
  "op": "connect", "ok": true, "status": 200,
  "result": {
    "tier":               "wireguard",
    "address":            "2a04:2a01:c0ff:ee5a:a9e7:1c3d:8b40:2f11",   // the deterministic /128
    "fqdn":               "a9e71c3d8b402f11.acme.agents.whisper.online",
    "tlsa":               "3 1 1 9f2b7c04e1a63d58af0c2b19e4d7188c…",
    "server_public_key":  "…",
    "endpoint":           "…:51820",
    "dns":                "2a04:2a01:0:53::53",
    "wireguard_config":   "[Interface]\nAddress = 2a04:2a01:c0ff:ee5a:a9e7:1c3d:8b40:2f11/128\n…"
  },
  "error": null
}

Drop the returned wireguard_config onto the host running the agent (or feed it to wireproxy for a no-root, userspace tunnel) and every packet it sends now sources from its own /128. The backend authorizes on that address: a forge-proof, attributable, revocable network identity instead of a bearer token anyone could carry. For the full transport mechanics and the SOCKS5 / AnyIP alternatives, see Connect & egress; for every other op on this same endpoint, the Control plane reference.

Idempotent, with honest errors

Because the address is derived, provisioning is naturally idempotent, and the failure modes are clear rather than surprising. Postel all the way down:

Verify: keyless, no account

The identity half is public on purpose: a merchant allowlisting a sanctioned shopper, a facilitator screening a payer, or a peer agent about to accept a task can all prove an agent's /128 without a Whisper account and without trusting Whisper's word. Four independent checks, all from tools already on the machine:

# 1. Forward-confirmed reverse DNS: the address names the agent, the name resolves back
dig -x 2a04:2a01:c0ff:ee5a:a9e7:1c3d:8b40:2f11 +short
a9e71c3d8b402f11.acme.agents.whisper.online.

# 2. The keyless verdict endpoint (takes an address or an FQDN; ?ip=<target> also accepted)
curl -s https://whisper.online/verify-identity/2a04:2a01:c0ff:ee5a:a9e7:1c3d:8b40:2f11 | jq .
{
  "is_whisper_agent": true,
  "dane_ok": true,
  "jws_ok": true,
  "evidence": { "aaaa": "...", "ptr": "...", "tlsa": "3 1 1 9f2b7c04e1a6…2c19a4b" }
}

# 3. The registry record: RDAP, IP-anchored to the /128
curl -s https://whisper.online/ip/2a04:2a01:c0ff:ee5a:a9e7:1c3d:8b40:2f11 | jq '.handle, .parentHandle'

# 4. The full chain re-derived on YOUR machine, against the IANA root: Whisper NOT in the trust path
whisper verify --trustless a9e71c3d8b402f11.acme.agents.whisper.online

A target that isn't a Whisper identity gets a clean 200 {"is_whisper_agent": false}. A negative verdict is a successful answer, not an error; only genuinely malformed input draws a 400, never a 500. --trustless is the strong form: it validates DNSSEC from the root in-process, on your resolver, so the proof holds even for a merchant or facilitator who won't take Whisper's word for anything. This is the check that turns "is this a real agent?" from a guess into a lookup. The full walk lives in Verify an agent, and the pre-transaction A2A handshake in Agent-to-agent trust.

Pin a wallet to the identity

x402 proves an agent controls funds; it says nothing about who the agent is. Pin-a-wallet closes exactly that gap: the wallet↔identity binding AP2 explicitly defers to FIDO. The agent signs a short statement, "this from wallet is operated by the agent at </128>," using the very key its /128 is derived from, and publishes that signature alongside its identity. A resource server or facilitator resolves the agent's /128, verifies the signature against the agent's DANE pin already in DNS, and only then honors the 402: no change to the x402 flow, no on-chain write, no settlement by Whisper.

# On the agent: bind the x402 `from` wallet (an EIP-3009 EOA) to its /128 by signing with
# the identity key. The private key never leaves the agent; only the signature is published.
echo -n '{"wallet":"0x8f3A9c4e2b1d7a06f5c8e39b4d2a1f70c6e8c0dE",
          "agent":"2a04:2a01:c0ff:ee5a:a9e7:1c3d:8b40:2f11","chain":"eip155:8453"}' \
  > binding.json
openssl dgst -sha256 -sign identity-key.pem -out wallet-binding.sig binding.json

# On the facilitator, before /settle: 1) prove the /128 is a live, non-revoked agent:
whisper verify --trustless 2a04:2a01:c0ff:ee5a:a9e7:1c3d:8b40:2f11   # DANE-EE 3 1 1 → key is the agent's

# 2) check the binding's signature against that same DANE-pinned agent key, the `from`
#    wallet in the x402 PAYMENT-SIGNATURE header you're about to settle.
openssl dgst -sha256 -verify agent-identity.pub -signature wallet-binding.sig binding.json
Verified OK   # from-wallet 0x8f3A9c4e… ⇄ verifiable agent 2a04:2a01:c0ff:ee5a:a9e7:1c3d:8b40:2f11

The effect: a pseudonymous x402 payer becomes a known, accountable, revocable agent. Know-Your-Agent over x402 without changing x402. Revoke the /128 and the binding no longer resolves to a live identity, so the wallet stops being an accountable agent worldwide at DNS-TTL, even though the EOA key itself can never be revoked on-chain. The full recipe, including AP2 PaymentMandate instruments, is in Pin a wallet.

Revoke: worldwide, in one call

The gap every agent protocol shares is not latency. It is a missing revocation primitive. A2A, AP2, x402 and MCP have no agent revocation at all; Visa and Mastercard can revoke, but only inside their own network. When one domain revokes a compromised agent, connected domains have no standard way to hear about it, so a "revoked" agent keeps working elsewhere: a dormant but persistent threat. A compromised integration once spread across 700+ trust domains in ~10 days on stolen tokens, and revocation didn't propagate.

Whisper's revocation is global because it lives in the DNS root everyone already resolves. One revoke tears down the /128, its PTR, and its DANE pin across both authoritative servers, and the change propagates at DNS-TTL speed:

CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:c0ff:ee5a:a9e7:1c3d:8b40:2f11'}})

# prove it: zero Whisper software, the same stock tools that proved it existed:
dig -x 2a04:2a01:c0ff:ee5a:a9e7:1c3d:8b40:2f11 +short           # -> nothing
curl -s https://whisper.online/verify-identity/2a04:2a01:c0ff:ee5a:a9e7:1c3d:8b40:2f11
# -> {"is_whisper_agent": false, ...}

Revocation isn't a database flag you have to trust; it's provable the same way the identity was. The reverse lookup goes empty and the keyless verdict flips to false for everyone, everywhere, at once. Every merchant, facilitator, and peer agent that verifies against the DNS root sees the agent go dark in the same lookup they already run. Contrast a shared bearer token, where a rotation reaches only the callers you can still reach.

See who checked it, and govern what it reaches

An identity you can prove is also one you can watch and bound. Because every agent's name resolves through Whisper's own authoritative DNS and RDAP, and its traffic sources from its /128, the owner gets a reconnaissance tripwire and a per-agent control plane the self-asserted card never offered.

Who checked this agent: a query

op:lookups returns who resolved or RDAP-queried an agent's identity: the counterparties verifying it before they transact, and the ones enumerating your fleet before they attack. It is the owner-facing companion to op:logs (the agent's own outbound): early warning that someone is probing, plus a verification-analytics stream, which merchants checked my agent, how often, from where.

curl -s https://whisper.online/ip/2a04:2a01:c0ff:ee5a:a9e7:1c3d:8b40:2f11/lookups | jq .
{ "resolved_by": 214, "rdap_queries": 37, "first_seen": "…", "top_asns": ["…"] }

Govern what the agent may reach

The same address is a policy handle. Default-deny an agent's egress and allow only the endpoints it needs; cap how much traffic its /128 can move on the network; cut it off:

# default-deny, allow only the merchant + the x402 facilitator this agent may pay
whisper policy set --agent 2a04:2a01:c0ff:ee5a:a9e7:1c3d:8b40:2f11 \
  --default deny --allow shop.example.com,facilitator.x402.org
# per-agent firewall by host / cidr / port: {action, match, value} rules + a default verdict
CALL whisper.agents({op:'firewall', args:{agent:'2a04:2a01:c0ff:ee5a:a9e7:1c3d:8b40:2f11',
  rules:[{action:'allow', match:'host', value:'shop.example.com'},
         {action:'allow', match:'host', value:'facilitator.x402.org'}], default:'deny'}})
# budget = a network egress circuit-breaker (bytes/requests), NOT a payment spend cap.
# Egress past the cap is denied; add kill:true, or one revoke, to cut it off entirely.
CALL whisper.agents({op:'budget', args:{agent:'2a04:2a01:c0ff:ee5a:a9e7:1c3d:8b40:2f11',
  bytes_down_cap:52428800, requests_cap:5000}})

These make every other control enforceable and auditable: a mandate scope, a spend cap, an injection-defense layer all attach to a durable, attributable subject instead of a bearer string. You can also sign the agent's outputs, a receipt, a mandate acknowledgement, a settlement record, under the same identity, so a downstream party trusts the artifact came from the real agent. Full surface in Egress governance.

Nothing issued in the dark

Every identity mint and every revoke lands in a public, append-only transparency log: an RFC 6962 tlog-tiles Merkle tree with Ed25519-signed C2SP signed-note checkpoints, each root anchored to Bitcoin via OpenTimestamps. So an issuance or a revocation can be independently checked and timestamped, a non-repudiable audit trail for the PSPs and card networks who need to show which agent was authorized, and when it was cut off.

Attribution: name whoever already spoofed you

Identity stops the next forgery. To name whoever already shadow-cloned your Agent Card or ran a spoofed agent across rotating clouds and residential proxies, the same API key opens the read-only attribution graph on the same endpoint. whisper.identify takes an address and returns the operator behind it, stitched across hops that a raw last-IP loses:

curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" \
  -H "content-type: application/json" \
  -d '{"query":"CALL whisper.identify(\"203.0.113.45\")"}' | jq .

The read-only Cypher surface (identify, origins, walk, variants, history) runs over the same POST https://graph.whisper.security/api/query with your key, and returns a reproducible, replayable evidence chain you can hand a chargeback team or a regulator. There is no whisper identify CLI subcommand; this is the API call, and it is live. Full verbs and shapes in Graph & cognition.

Honest: Whisper is not the only DNS-anchored agent identity

As of 2026 there is a small, healthy movement to anchor agent identity in DNS, and Whisper did not invent the category. It deserves to be named:

• OWASP ANS (Agent Name Service): a DNS-style resolution and trust layer that maps agent names to capabilities and keys, anchoring discovery in DNSSEC-signed records.
• agentcommunity AID: the Agent Interface Discovery convention: a public _agent TXT record at a domain that advertises where and how to reach an agent.
• IETF DNS-AID / BANDAID: early Internet-Drafts to standardize agent-identity discovery and binding directly in the DNS.
• Identity Digital DNSid: a DNS-anchored ownership record (a "birth certificate" across DNS, PKI and a ledger) with transfer and revocation records, which, by its own statement, "does not authenticate agents or enforce run-time policy."

These are complementary, and we cite them respectfully. What Whisper adds on top of a name or discovery record is a working identity layer: (1) a routable IPv6 /128, the address is the identity, which fuses identity, reachability, and egress governance in one primitive (every other approach lives at the app handshake: a card, a header, a TXT/SVCB label); (2) pin-a-wallet, binding an arbitrary x402 wallet to the verifiable identity; (3) per-agent revocation at DNS-TTL, one call, verifiable by anyone; and (4) a cross-platform attribution graph in public infrastructure. A discovery label tells you where an agent claims to be; a routable, revocable, wallet-pinned /128 is the identity you can verify, govern, and shut off.

Honest scope: necessary, not sufficient

Verifiable identity closes the "which agent / for whom / prove it / attribute it / revoke it" gaps the payment protocols left open, and it makes every other control enforceable and auditable. It is not a silver bullet, and we say so plainly. It does not:

• stop a legitimately-authenticated agent from making a bad purchase: identity proves who acted and for whom, not whether the decision was good (that needs mandate scoping, spend caps, human-in-the-loop);
• prevent prompt-injection of the agent's own reasoning: it faithfully attributes the hijacked-within-authority action, it does not stop the manipulation (injection defense is a separate layer);
• settle payments, tokenize a PAN, issue Agentic Tokens, or move funds: it is the identity layer beneath the rails, never a replacement;
• perform PSD2 SCA: the EBA is explicit that SCA responsibility "cannot be outsourced"; Whisper supplies the durable, attributable subject the mandate/SCA evidence chain binds to, as evidence, never as an authentication factor;
• do VASP-grade KYC of the human or legal entity behind an agent: it gives Know-Your-Agent and the FATF Travel Rule their missing identity anchor, not the KYC judgment.

Where this fits (and where it doesn't)

Whisper anchors the agent's identity at the agent↔counterparty IP/transport boundary: the network endpoint a merchant, facilitator, or peer agent authorizes. It is additive: it complements the protocols and directories you already run and does not try to replace them, and it never redefines the interop protocol or moves the money.

• A2A. DANE-pin the Agent Card's signing key to the agent's /128; before two agents talk, each resolves and verifies the other. Whisper supplies the verification A2A leaves to the transport: it complements the Agent Card, it does not replace it.
• AP2. Bind the mandate VC's verificationMethod to a DNSSEC/DANE-anchored identity (and a did:web), closing AP2's stated authenticity gap, the very identity/key-management piece AP2 defers to FIDO. Whisper never authorizes or settles the mandate.
• x402. Pin-a-wallet turns a pseudonymous payer into a known, revocable agent: no on-chain change, no settlement by Whisper.
• Visa TAP · Mastercard Agent Pay · MCP. Where each keeps its own key directory or token registry, Whisper is the neutral, cross-protocol anchor any merchant already running DNS can resolve: one identity instead of registering in every silo. It interoperates with those directories; it does not compete with MDES or the Visa registry.
• Where Whisper does not go. Not the settlement rail, not the SCA factor, not the payment mandate's authorization logic, not custody of the wallet key. Whisper is the network identity of the endpoint on the IP fabric: the doorway, not the till.

For mapping these identities to PSD2 / PSD3-PSR and the agent-payment protocols, and for SOC export, see PSD2 · agent-payment protocols. The Splunk, Microsoft Sentinel and OpenCTI connectors are shipped; STIX 2.1 / TAXII export is on the roadmap and labelled as such there. No specific company is named, endorsed, or implicated as a breach victim anywhere in these docs; the abuse patterns cited are the public, cross-industry ones.

Next

• Agent-fraud cure: this identity, applied to the exact impersonation / spoofed-card / drained-wallet chain it was built for
• A2A · AP2 · x402: dropping the /128 into the Agent Card, the mandate signer, and the x402 wallet
• Pin a wallet: the byte-for-byte binding that makes a pseudonymous payer accountable
• Agent-to-agent trust: the mutual verify-the-counterparty handshake before a mandate is signed