Pin-a-wallet · A2A-trust · verify

Six copy-paste recipes put a forge-proof, revocable network identity under an AI commerce agent. Bind it to the agent id it already carries, prove it keyless, DANE-anchor its A2A Agent Card so a counterparty verifies it against the open DNS root instead of a walled-garden directory, pin an x402 wallet to it so a facilitator knows which real agent is paying, govern exactly what it may reach, kill it in one call, and see who has been checking it. Each recipe runs today against shipped primitives.

They share one primitive: a routable IPv6 /128 that an agent derives from a key it already holds (the key behind its Agent Card signature, its AP2 mandate signer, or its x402 wallet), DNSSEC-signed and DANE-pinned so anyone can verify it and nobody can forge it. Everything below is built from shipped parts: the agent /128, keyless verify, the attribution graph, per-agent egress governance, the reverse-observability op:lookups, the Merkle transparency log, and one-call revoke. Where a step is a pattern you assemble rather than a single command, or a connector still on the roadmap, it says so in plain words.

The shared primitive: an identity the agent derives, not one you hand it

An AI commerce agent already holds a signing key: the one behind its A2A AgentCardSignature (a JWS over its /.well-known/agent-card.json), the ECDSA P-256 key that signs its AP2 mandates, the EOA behind its x402 wallet, or the RFC 9421 keyid it presents to Visa's Trusted Agent Protocol. Whisper takes only its public SubjectPublicKeyInfo (SPKI) and, together with the agent id as a domain separator, deterministically derives a /128 under 2a04:2a01::/32 (AS219419). The private key never leaves the agent; the server only ever computes a public address.

That closes the exact gap the payment rails were shipped without. The A2A Agent Card's signature is recommended, not mandated, and its trust root is "the domain owner" via web PKI: self-asserted. AP2 deliberately does not define agent identity at all; it defers that to FIDO. x402's identity is a bare wallet address: "no accounts." The derivation below gives the agent an identifier with four properties none of those anchors carry together:

• Deterministic & idempotent: the same key + agent id always yields the same /128. Re-provisioning a redeployed agent for the same id returns the same address; there is no registry to keep in sync.
• Tenant-bound & fleet-unlinkable: the derivation folds in your tenant, so the same key under two operators yields two unrelated /128s. No one can link an agent across platforms by address suffix, and there is no enumeration oracle.
• Forge-proof: the /128 is DANE-EE 3 1 1-pinned to that agent's key and has DNSSEC-signed reverse DNS. A shadow-cloned agent with a different key derives a different address and can't present the pinned key.
• Revocable worldwide: one control-plane call tears the /128, its PTR, and its DANE pin down everywhere at DNS-TTL speed. That's the cross-platform revocation that A2A, AP2, x402 and MCP all lack ("not a latency problem but a missing protocol").

Recipe 1. Bind an agent to its agent id

Give an agent the identity it should have been born with, derived from the key it already holds and named by the agent id a counterparty already reads off its Agent Card. One call; the reply is the address, and a stock dig confirms the name.

Pass the agent id as the generic device_id. Re-running with the same agent key + agent id returns the same /128 (it's idempotent), so it's safe to run from a deploy loop or a spawn hook:

# Bind an AI shopping agent to the agent id it already carries. device_id = the agent id.
# Re-running with the same agent key + id returns the SAME /128 (idempotent).
curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" \
  -H "content-type: application/json" \
  -d '{"query":"CALL whisper.agents({op:'"'"'connect'"'"', args:{tier:'"'"'wireguard'"'"', identity_public_key:'"'"'<base64 SPKI of the agent key>'"'"', device_id:'"'"'acme-shopper-7f3a91'"'"'}}) YIELD op, ok, status, result, error RETURN op, ok, status, result, error"}' | jq .
{ "op":"connect", "ok":true, "status":200,
  "result":{ "address":"2a04:2a01:a9e7::7f3a",
             "name":"shopper-7f3a91.acme.agents.whisper.online",
             "dane":"3 1 1", "dnssec":"signed", "wireguard":"<peer config>" } }

Confirm the /128 and its name from the other side, keyless. The reverse DNS is forward-confirmed (PTR ⇄ AAAA), so nothing but dig is required:

dig +short -x 2a04:2a01:a9e7::7f3a
shopper-7f3a91.acme.agents.whisper.online.

# …and the forward AAAA resolves straight back, completing the round trip that makes it forge-proof:
dig +short AAAA shopper-7f3a91.acme.agents.whisper.online
2a04:2a01:a9e7::7f3a

The mint is not issued in the dark. Every /128 minted and every one revoked lands in a public, append-only Merkle transparency log, so you, and a PSP or auditor allocating chargeback liability later, can replay the full lifecycle of the identity that acted:

# The identity's ordered lifecycle (mint, any rotations, revoke), keyless:
curl -s https://whisper.online/ip/2a04:2a01:a9e7::7f3a/transparency

Recipe 2. Prove an agent's identity, keyless

Once bound, any counterparty (a merchant's checkout before it accepts an agent order, a payment facilitator before it settles, a peer agent before it delegates a task) proves the agent is real without an account, without joining Visa's or Mastercard's directory, and without trusting Whisper as an authority. The proof re-derives against the IANA DNSSEC root. This is the whole point: "is this a real agent?" stops being a guess and becomes a lookup.

The trustless check walks the full chain (DNSSEC to the IANA root, the DANE-EE pin, and the transparency-log entry) and prints exactly what it trusted:

# Prove any agent identity, trustless: re-derived against the IANA DNSSEC root,
# with no Whisper API trusted as an authority anywhere in the chain.
whisper verify --trustless 2a04:2a01:a9e7::7f3a
dnssec   pass   DNSSEC-root   AAAA, PTR and TLSA(3 1 1) all DNSSEC-validated to the IANA root
dane     pass   DNSSEC-root   served leaf SPKI-SHA256 == TLSA pin
ledger   pass   DNSSEC-root   transparency-log entry present, signature verifies
CRYPTOGRAPHICALLY PROVEN: trust anchor DNSSEC root (IANA) + DANE-EE; Whisper API NOT trusted

The same fact is reachable with tools already in every ops toolbox: one keyless HTTPS call, or plain dig:

# Is this address a real, DANE-anchored agent identity? One keyless call, no install:
curl -s https://whisper.online/verify-identity/2a04:2a01:a9e7::7f3a
{"is_whisper_agent":true,"dane_ok":true,"jws_ok":true,
 "evidence":{"address":"2a04:2a01:a9e7::7f3a",
   "ptr":"shopper-7f3a91.acme.agents.whisper.online.",
   "forward_aaaa":"2a04:2a01:a9e7::7f3a"}}

# An impostor or shadow-cloned agent: no registered /128 for its key, no DANE pin it can present:
curl -s https://whisper.online/verify-identity/2a04:2a01::1
{"is_whisper_agent":false,"detail":"no Whisper agent identity anchors this address"}

A stolen bearer token or a leaked API key buys an attacker nothing here. The identity is a network fact bound to a key, not a bearer string that "grants access to anyone who possesses it." It can't be lifted off the wire and replayed from another host.

Recipe 3. A2A-trust: DANE-anchor your Agent Card

An A2A Agent Card is the first thing a counterparty reads, and it is self-asserted: the AgentCardSignature is recommended, not mandated, and even when present its trust root is "the domain owner" via web PKI. The card networks answer this by each standing up a central key directory (Visa's JWKS, Mastercard's registry, Cloudflare Web Bot Auth) that you verify against only if you're a member. DANE-anchoring the card's signing key to the agent's /128 is the decentralized alternative: the open DNSSEC root is the neutral, publicly-verifiable key directory, and anyone with dig can check "this card's key belongs to this agent", a stronger claim than "belongs to the domain," with no registry to join.

The card publishes its /128 and its signing key travels DANE-pinned to it. A verifier reads the card, resolves the /128's TLSA record from the DNSSEC root, and checks the card's signing-key SPKI hash against the pin, all keyless, stock tools:

# A2A Agent Card cross-references its Whisper identity (excerpt):
#   "url": "https://acme.example/agents/shopper",
#   "provider": { "url": "https://acme.example" },
#   "whisperIdentity": "2a04:2a01:a9e7::7f3a"   ← resolve + DANE-check this

# Verifier: full trustless proof that the card's key belongs to THIS agent.
whisper verify --trustless 2a04:2a01:a9e7::7f3a
dane   pass   DNSSEC-root   served leaf SPKI-SHA256 == TLSA pin

# Stock-tools equivalent: the DNSSEC-signed TLSA pin the card's signing key must match:
dig +short TLSA _443._tcp.shopper-7f3a91.acme.agents.whisper.online
3 1 1 b653a4ef…fcb82d1d
# hash the AgentCardSignature's public key (SPKI, DER) and compare to the pin above:
openssl pkey -pubin -in agent-card-signing.pub -outform der | openssl dgst -sha256
b653a4ef…fcb82d1d   # == TLSA pin → the card belongs to THIS agent, proven off-platform

Revocation is the primitive A2A, AP2, x402 and MCP all lack: when an Agent Card is compromised or retired, one op:revoke pulls the DNS/RDAP record and every counterparty's next DANE check fails within the TTL. That's a global off-switch, not a per-network deactivation that leaves the identity "a dormant but persistent threat" everywhere else. That teardown is Recipe 5.

Recipe 4. Pin an x402 wallet to the agent

x402 is deliberately pseudonymous: the paying identity is the from wallet address (an EOA), which proves control of funds but not who: unattributable and non-revocable (you cannot revoke an EOA). A facilitator honoring a 402 sees anonymous money. Pin-a-wallet binds that wallet to the agent's verifiable, revocable /128, so the facilitator resolving the payment can answer the question x402 leaves open (which real, still-authorized agent is paying) with no change to the onchain flow. It is the wallet↔agent link x402 lacks and AP2 explicitly defers to FIDO.

The agent produces the binding by signing a statement "this wallet is operated by the agent at /128" with the same key whose public half anchors the /128 (see Sign agent outputs). Publish it alongside the identity; a facilitator verifies it keyless against the DANE pin already in DNS:

# On the agent: bind the x402 wallet to the /128 by signing with the identity key
# (the private key stays on the agent; only the signature goes out).
echo -n '{"wallet":"0x8F3a91B2c4D5e6F708192A3b4C5d6E7f8091A2b3",
          "agent":"2a04:2a01:a9e7::7f3a","chain":"eip155:8453"}' \
  | openssl dgst -sha256 -sign identity-key.pem -out wallet-binding.sig

# On the facilitator, before /settle: prove the /128 is a live, non-revoked agent…
whisper verify --trustless 2a04:2a01:a9e7::7f3a       # DANE-EE 3 1 1 → key is the agent's

# …then check the binding's signature against that same DANE-pinned agent key:
# this is the x402 `from` wallet in the 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 0x8F3a… ⇄ verifiable agent 2a04:2a01:a9e7::7f3a

# The facilitator now knows WHICH real agent is paying, and can refuse if it's revoked.

Revoke the /128 and the binding no longer resolves to a live identity. The wallet stops being an accountable agent everywhere at DNS-TTL, even though the EOA key itself can never be revoked onchain. That is the accountability x402 was built without, added without touching the settlement.

Recipe 5. Govern and kill an agent

An identity you can prove is also one you can fence. An agent that can spend is an identity-aggregation point: "an agent outside its scope can drain assets faster than a human can react." So make least-privilege the policy, cap what it can move, and keep the one-call kill-switch ready. Because egress source-binds to the agent's own /128, these controls apply to the agent, not to a fragile IP allowlist.

Set the resolution policy to default-deny and allow only the destinations the agent legitimately needs, using the CLI or the control plane's op:policy:

# Default-deny the agent's egress; allow only its merchant API and x402 facilitator.
whisper policy set --agent 2a04:2a01:a9e7::7f3a \
  --default deny --allow api.merchant.example,facilitator.x402.example

# The same, over the control plane (op:policy): allow by name or subdomain:
curl -s https://graph.whisper.security/api/query -H "X-API-Key: whisper_live_xxx" \
  -H "content-type: application/json" \
  -d '{"query":"CALL whisper.agents({op:'"'"'policy'"'"', args:{agent:'"'"'2a04:2a01:a9e7::7f3a'"'"', default:'"'"'deny'"'"', allow:['"'"'api.merchant.example'"'"','"'"'facilitator.x402.example'"'"']}})"}'

Tighten it with a per-agent firewall by host, cidr or port, cap what the agent can move with a budget (a wallet-drain circuit-breaker), and keep the kill-switch one verb away:

# Per-agent firewall (op:firewall): allow the facilitator on 443, deny all else:
curl -s https://graph.whisper.security/api/query -H "X-API-Key: whisper_live_xxx" \
  -H "content-type: application/json" \
  -d '{"query":"CALL whisper.agents({op:'"'"'firewall'"'"', args:{agent:'"'"'2a04:2a01:a9e7::7f3a'"'"', rules:[{allow:'"'"'host'"'"', host:'"'"'facilitator.x402.example'"'"', port:443},{deny:'"'"'all'"'"'}]}})"}'

# Budget + kill-switch (op:budget): cap daily egress, trip the switch past the cap:
curl -s https://graph.whisper.security/api/query -H "X-API-Key: whisper_live_xxx" \
  -H "content-type: application/json" \
  -d '{"query":"CALL whisper.agents({op:'"'"'budget'"'"', args:{agent:'"'"'2a04:2a01:a9e7::7f3a'"'"', egress_mb_per_day:50, on_exceed:'"'"'kill'"'"'}})"}'

# A compromised or rogue agent: cut it off worldwide in one call (op:revoke):
whisper kill --revoke 2a04:2a01:a9e7::7f3a   # worldwide, at DNS-TTL

After the revoke, every keyless check from Recipe 2 flips to is_whisper_agent:false for that address within the DNS TTL, and the Recipe 4 wallet binding stops resolving to a live agent. There's no cross-domain revocation protocol to wait on, no per-network deactivation that leaves the identity working elsewhere. Containment is one call, and it lands in the transparency log.

Recipe 6. See who checked it, then back-trace the operator

Two questions the payment rails can't answer, both keyed. First: who has been checking my agent's identity? Because every agent's name resolves through Whisper's own authoritative DNS and RDAP, the owner sees exactly who looked: a reconnaissance tripwire and a verification-analytics stream. Second: when a rogue agent rotates its egress across clouds and residential proxies to evade attribution, who is really behind it? The attribution graph fingerprints the operator, not the disposable last IP.

Part A: who checked your agent. Ask who has been resolving a single agent's identity, keyless per-address, or the whole fleet with your key. One counterparty verifying your agent before it transacts is signal; one source resolving hundreds of your agents' names in seconds is enumeration:

# Who verified or RDAP-queried this agent's identity? Keyless, per-address:
curl -s https://whisper.online/ip/2a04:2a01:a9e7::7f3a/lookups
{"address":"2a04:2a01:a9e7::7f3a","window":"24h",
 "lookups":[{"kind":"TLSA","count":4},{"kind":"PTR","count":2},
            {"kind":"rdap","count":3}]}   # counterparties checking you before they transact

# Fleet-wide, with your key (op:lookups): the single source walking your whole fleet:
curl -s https://graph.whisper.security/api/query -H "X-API-Key: whisper_live_xxx" \
  -H "content-type: application/json" \
  -d '{"query":"CALL whisper.agents({op:'"'"'lookups'"'"', args:{scope:'"'"'fleet'"'"', window:'"'"'90s'"'"'}})"}' | jq .
  source 203.0.113.7: resolved 640 distinct agent identities in 90s   ⚠ enumeration

Part B: back-trace the operator. Feed a suspicious source into whisper.identify. There is no whisper identify CLI verb; passing the address over POST https://graph.whisper.security/api/query is the interface:

# Who really operates the rogue agent behind a rotating egress? The graph API.
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(\"34.90.x.x\")"}' | jq .
  operator:  <fingerprinted> · seen across AWS / GCP / Azure
  residential swarm collapsed by JA4: same tooling, 41 exit IPs → 1 operator
  evidence:  reproducible, replayable JSON for the dispute and an auditor

# Cluster the rotation into one genealogy; whisper.walk / whisper.history expand + timeline it.
curl -s https://graph.whisper.security/api/query -H "X-API-Key: whisper_live_xxx" \
  -H "content-type: application/json" \
  -d '{"query":"CALL whisper.origins(\"34.90.0.0/16\") YIELD asn, prefix, first_seen RETURN asn, prefix, first_seen"}' | jq .

Take the enumerating source from Part A straight into whisper.identify and anonymous recon becomes an attributed operator, before an impostor agent ever presents a forged card. Every finding is a reproducible, replayable evidence chain your fraud team, a PSP, and a dispute reviewer can all replay.

Where each recipe stops, and what's roadmap

Honest scoping, grouped by recipe. Whisper anchors the IP/DNS/transport boundary; the payment settlement, the mandate authorization, the SCA factor, and the agent's own reasoning stay exactly where they are. Verifiable identity closes the which-agent / for-whom / prove-it / attribute-it / revoke-it gaps the rails left open, and makes every other control (spend caps, mandate scope, injection defense, human approval) enforceable and auditable. It is the missing anchor, not a substitute for the guardrails on top.

Next

• Agent identity: the full derivation the /128 above comes from, key + agent id to address
• A2A · AP2 · x402: where each socket binds, protocol field by protocol field
• DANE & TLSA: the 3 1 1 pin every check here rests on, byte for byte
• PSD2 · agent-payment protocols: where these recipes map into KYA, Visa TAP and Mastercard Agent Pay evidence