The agent presents a mandate to pay. You still can't answer which agent this is.
The card networks just shipped agent-commerce rails — Visa Intelligent Commerce and TAP, Mastercard Agent Pay, OpenAI/Stripe ACP, Google/Coinbase AP2 — and every one makes "the agent must carry a cryptographic identity a relying party can verify and revoke" a hard requirement. Then each builds its own siloed key directory, an A2A Agent Card is a JSON file anyone can self-publish, an x402 wallet is a bare pseudonymous address, and no protocol propagates a revocation across platforms. So the one question your checkout, your facilitator, or a peer agent most needs answered — which agent, really, and is it still authorized — stays a guess.
dig before honoring its payment, with its wallet pinned to it and an off-switch you pull worldwide in one call. Verify the agent before you let it pay.
whisper verify --trustless — anchored at the IANA DNS root. Our own API is not in the trust path.
Every new agent-commerce rail leans on an agent identity that none of them anchors in public infrastructure.
A2A discovers and delegates, AP2 signs the mandate, x402 settles onchain, Visa TAP and Mastercard Agent Pay run the card leg — all done well. But the identity underneath is either self-asserted, network-scoped, or pseudonymous. Here is the vacuum, in three moves.
The Agent Card is a file anyone can write
A2A's identity is a self-published card at /.well-known/agent-card.json. The spec standardizes how to declare auth but leaves verification to the transport — so a forged or shadow-cloned card at a plausible domain is technically indistinguishable from the real one.
Steal the token, become the agent
An agent is authenticated by a bearer credential — an API key, an OAuth token, a self-asserted card — that "grants access to anyone who possesses it, not a verified identity." Non-human identities outnumber humans ~109:1, and 28.65M hardcoded secrets leaked on public GitHub in 2025.
A "revoked" agent keeps working elsewhere
When one domain revokes, connected domains have no standard way to hear it — "not a latency problem but a missing protocol." A compromised integration reached 700+ trust domains in ~10 days on stolen tokens; the revocation never propagated.
Strip it down and it isn't a hundred bugs — the rails are good. It's two structural gaps in the identity layer they were all built without. Close both and "which agent is this" turns from a guess into a lookup any relying party can run.
One is an agent you can't prove. The other is a compromised agent you can't stop.
Both are the kind a red-teamer names on sight — not a compliance checkbox. Here they are, and here's exactly how each closes without redefining a single payment protocol.
A bearer credential or a self-asserted Agent Card is not an identity — it's a secret whoever holds it can present. Nothing at your checkout or your facilitator separates the real agent from an impersonator, because there is no forge-proof identity to check it against. Every domain validates in isolation; there's no shared anchor.
The answer — the address is the agent. Derive each agent's routable /128 from the public key it already holds — the key behind its Agent Card AgentCardSignature (JWS), its Visa TAP / Web Bot Auth keyid (RFC 9421), or its AP2 mandate-signing key — with the agent_id as the domain separator. It's DNSSEC-anchored, DANE-EE 3 1 1 pinned, RDAP-registered, re-derivable by anyone with dig and openssl. A forged Agent Card whose key can't prove the /128 simply fails; a stolen bearer with no agent key behind it authenticates to nothing. One identity your checkout resolves — instead of registering separately in Visa's, Mastercard's and Cloudflare's directories.
The private key never leaves the agent (only the public half is an input); the agent_id alone yields nothing without the key (enumeration-resistant); and because the derivation is tenant-bound, the same agent under two platforms yields two unrelated /128s — no one can link it across operators.
"An Agent Card is just JSON at a well-known URL — anyone can publish one that says it's you. How is your /128 different?"
Because it's derived from the agent's own key and anchored in the IANA DNS root. A verifier resolves it with dig and openssl, trusting no platform, and DANE pins the exact key the agent must prove in the handshake — a card that can't prove that key is just a claim. Honest limit: identity proves who and for whom, not whether the purchase itself was a good idea. Mandate scope, spend caps and human approval do that — we make each of them enforceable and auditable, we don't replace them.
When one platform cuts an agent off, the others never hear it — a missing protocol, not a latency bug — so a compromised or rogue agent keeps transacting elsewhere. And because its egress rotates across clouds and residential proxies, every domain validates it in isolation with no shared defense and no attribution to hand a chargeback desk.
The answer — revocation is a DNS record, and attribution is a graph. op:revoke pulls the /128's DNS, PTR and DANE pin; every verifier that resolves it — on any platform, in any rail — sees it gone at DNS-TTL. That's the cross-domain revocation the ecosystem calls missing. And the attribution graph — 7.44B nodes, 39.3B relationships of fused BGP, DNS, WHOIS, TLS and hosting — fingerprints the operator across rotating egress (infrastructure genealogy for clouds; a JA4/JA3 client fingerprint for a residential swarm) and returns a reproducible evidence chain for the chargeback fight. Meanwhile op:lookups tells you who resolved or RDAP-queried your agent's identity — an early warning that someone is enumerating your fleet, or checking your agent before they transact with it.
from address to a verifiable agent identity, so a facilitator resolves "which agent is this, and is it still authorized" from public DNS before it settles — no change to the onchain flow. The same lookup feeds op:lookups (who checked) and honors op:revoke (gone everywhere at DNS-TTL)."A compromised integration reached 700+ domains in ~10 days and revocation never propagated. What's actually different here?"
Revocation lives in one place every verifier already consults — the DNS record for the /128 — not a per-platform database row that has to be pushed everywhere. Pull it once; anyone who resolves the agent, on any rail, sees it revoked at DNS-TTL. Honest limit: this revokes identities anchored with us — we can't pull a Visa or Mastercard network token; that stays in their directory. We're the neutral anchor that interoperates with them, not their replacement.
Gap 1 is the root cause; Gap 2 is enforcement made durable. Both ride the payment rails you already run, untouched. Now — who moves first, and exactly where we do and don't fit.
Four people carry this problem — and each one buys the same primitive for a different reason.
Different triggers, different vocabulary, one mechanism underneath: the address is the agent. Find your seat.
A · Merchant · marketplace · payment platform
Trigger: agent traffic grew >1,300% in 9 months; you eat the chargeback when an agent purchase is disputed; behavioral fraud telemetry breaks when a non-human checks out; and you want to verify an agent before you honor its mandate.
Lead: verify the agent's identity from DNS before you accept its payment, and revoke a compromised agent in one call — additive to your existing fraud stack. One identity your checkout resolves instead of three network directories (neutral across Visa/MC/ACP/AP2); turn "is this a real agent?" from a guess into a lookup; and get attribution for the chargeback fight — every request maps to a revocable, publicly-verifiable identity and its egress /128.
You say: good-bot vs bad-bot · HTTP Message Signatures · keyid · well-known key directory · agent allowlist · chargeback liability · verified agent.
B · Agent framework · marketplace · registry
Trigger: A2A Agent Card discovery and the identity debate in issue #1672 — to transact at all, agents must be registered and recognizable, yet A2A leaves card verification to implementers, so a listing a counterparty can actually verify is missing.
Lead: give every listed agent a verifiable, revocable, domain-anchored identity without standing up a centralized CA — the decentralized DANE alternative. device_id = agent_id = a routable /128 derived from the key the agent already holds; a public, DNSSEC-anchored allowlist entry, no per-network onboarding, revocable at DNS-TTL, verifiable by anyone with dig.
You say: Agent Card · /.well-known/agent-card.json · securitySchemes · MutualTls · signed agent card · allowlist registry · DID · key rotation.
C · Wallet · x402 facilitator
Trigger: x402 is deliberately "no accounts, no PII" — the wallet key proves control of funds, not who is paying — and you need to know which real agent is behind a payment for allow/deny and abuse control, without reintroducing accounts.
Lead: pin-a-wallet binds an x402 wallet to a verifiable agent identity so you can answer "which agent is this" for allow/deny and abuse control — without reintroducing accounts. Resolve the from address → a DANE-anchored, non-revoked agent before you honor the 402; no change to the onchain flow. Convert pseudonymous money into a known, revocable agent paying.
You say: HTTP 402 · PAYMENT-SIGNATURE · EIP-3009 transferWithAuthorization · from / payTo · USDC on Base · /verify + /settle · KYA · Travel Rule.
D · AP2 · payment-protocol adopter
Trigger: AP2 chains VC-signed mandates (Intent / Cart / Payment) superbly, but explicitly defers agent identity and key management to standards bodies — the FIDO Alliance's Agentic Authentication work — and does not specify it in-protocol.
Lead: a verifiable agent identity for the mandate signer — input to the FIDO Agentic Authentication WG that AP2 defers identity to. Bind the mandate's verificationMethod / signer key to a DNSSEC/DANE-anchored /128 so the Credentials Provider and merchant independently confirm "this Shopping Agent key = verifiable agent X" — closing AP2's stated Authenticity and Accountability — and revoke the /128 to kill that agent's trusted identity across every mandate.
You say: IntentMandate · CartMandate · PaymentMandate · W3C Verifiable Credential · verificationMethod · Credentials Provider · scoped delegation.
A fifth seat, too: the PSP or acquirer that has to classify agent transactions, allocate liability across a four-party chain, and bind SCA/mandate evidence to a durable subject under PSD3/PSR — everyone verifies keyless; only the agent's operator needs a key.
The strongest thing we can say is also the most honest: we're the neutral identity anchor the rails were built without — and nothing more.
Over-claiming in payments is the fastest way to lose a compliance reviewer, so we draw the line before they do. Three tiers: what we do today, what we complement, and what we will not claim.
● Direct — additive, today
A publicly-verifiable, revocable agent identity — a DANE-anchored /128 from the agent's own key; pin-a-wallet to bind an x402 wallet to it; egress governance + a per-agent kill-switch (firewall · budget · policy · revoke); and cross-platform attribution + op:lookups. The shipped bundle no single rail provides together.
◐ Complementary — interoperates, never replaces
An open anchor for AP2's deferred-to-FIDO identity, Visa TAP's keyid directory, and Mastercard's registry; a KYA / FATF-Travel-Rule identity anchor (the technical binding, not VASP-grade KYC); a2a-trust — mutual verify-the-counterparty before the mandate; and evidence for PSD3/PSR liability allocation (forward-looking — the RTS isn't published).
✕ We do not claim
Not a payment processor — we never settle, tokenize a PAN, or move funds. Not PSD2/SCA/PCI compliance itself. Identity ≠ intent — we don't stop fraud a fully-authorized agent commits inside its mandate. And not the only DNS-anchored agent-identity scheme — ANS, AID, DNS-AID and DNSid exist. Each spelled out below.
| Claim | Status | What it means — and its limit |
|---|---|---|
| Publicly verifiable, revocable agent identity (DNSSEC/DANE /128) | ● DIRECT | Derived from the agent's own key, checkable with dig + openssl trusting no platform, revocable at DNS-TTL. Shipped & live. |
| Pin-a-wallet — bind an x402 wallet to the verifiable identity | ● DIRECT | Assembled from shipped primitives (did:web + DANE + transparency log + keyless verify) plus one stock-JOSE signing step; a one-command whisper pin-wallet wrapper is on the roadmap. |
| Egress governance + per-agent kill-switch (firewall · budget · policy · revoke) | ● DIRECT | Govern exactly what an agent may reach, cap it, and cut it off worldwide in one call. Shipped & live. |
Cross-platform attribution + op:lookups | ● DIRECT | Fingerprint the operator across rotating egress; see who resolved or RDAP-queried your agent. Shipped & live. |
| a2a-trust — mutual verify before the mandate is signed | ● DIRECT | Each agent resolves the other's /128 + DANE before they transact — the step A2A and MCP structurally lack. Additive, not a fork. |
Open anchor for AP2 (FIDO) / Visa TAP keyid / MC registry | ◐ COMPLEMENTARY | One globally-resolvable identity that interoperates with each directory; we bind the public identity, they keep the token and the rail. |
| KYA / FATF Travel-Rule originator anchor | ◐ COMPLEMENTARY | The technical agent↔wallet↔identity binding KYA needs — not the VASP-grade KYC judgment of the legal person; the VASP still owns collect/verify/transmit. |
| PSD3/PSR delegated-agent-auth evidence | ◐ COMPLEMENTARY | A neutral identity substrate an RTS-compliant scheme can reference. Forward-looking — the PSD3/PSR SCA RTS text isn't published. |
| PSD2 Strong Customer Authentication (SCA) | ✕ NOT CLAIMED | SCA assumes a human and "cannot be outsourced" (EBA Q&A 6141). We supply attributable evidence of which agent acted under a mandate — never an SCA factor. |
| Payment processing / settlement / PAN tokenization | ✕ NOT CLAIMED | We never move money or tokenize the card. The identity layer beneath the tokens and rails, never a replacement. |
| Stops fraud a fully-authorized agent commits (identity ≠ intent) | ✕ NOT CLAIMED | Identity proves who + for whom, not whether the decision was sound. Doesn't stop prompt-injection of the agent's reasoning, or a thief with the signing key — pair with mandate scope, spend caps, injection defense, human approval. |
| The only / first DNS-anchored agent identity | ✕ NOT CLAIMED | ANS, AID, DNS-AID and Identity Digital's DNSid exist. We differentiate within the category — a routable /128 with egress, pin-a-wallet, and DNS-TTL revoke — not a discovery label or an ownership record. |
The one-sentence version: they authorize the payment; we prove the agent — to anyone, without trusting us — anchor its wallet, and revoke it in one call. The open identity layer Visa TAP, Mastercard Agent Pay, ACP, AP2 and KYA each need but each solve inside their own silo. See the full comparison →
Three planes on one primitive — and all three exit into the payment stack you already run.
The primitive is one line: the address is the agent — a routable IPv6 /128 out of 2a04:2a01::/32 (announced by AS219419), DNSSEC-anchored, DANE-EE pinned, verifiable by anyone with dig. Point it at your agents and you get identity, attribution, and governance — no new silo, and the rails stay yours.
Nothing issued in the dark
Every agent identity minted and every revocation lands in a public, append-only RFC 6962 Merkle transparency log, Ed25519-signed and anchored to Bitcoin via OpenTimestamps — an auditable issuance-and-revocation trail a facilitator, an auditor, or a chargeback desk can replay. Honest status: tamper-evident and Bitcoin-anchored today; independent external witnessing is the next step, and we already speak the C2SP witness protocol so any third party can co-sign.
Govern what an agent may reach
A per-agent /128 with a graph-first resolver and source-bound egress enforces default-deny — allow the facilitator and the settlement endpoint, block the rest — with op:firewall, op:budget caps on traffic and spend, and op:revoke to cut a compromised agent off worldwide in one call.
Pin-a-wallet, honestly staged
Today: bind an x402 wallet to a DANE-anchored agent identity by publishing a signed did:web credential at the agent's own name — so a counterparty verifies the agent and the wallet from one public DNS lookup, checked against the transparency log. On the roadmap: a one-command whisper pin-wallet that wraps the last signing step.
Additive & availability-safe
It rides existing DNS/IPv6 and adds no chokepoint in your checkout path. If a verifier authorizes against the DANE/verify path, that plane is built to fail open — a Whisper outage degrades to the anchors you already run, never a false decline. Anycast on AS219419, no single node in the path.
Don't take our word for it — our API isn't in the trust path.
Two tiers, by design. No key: anyone resolves an agent's identity and back-traces a suspicious payer — trustless, anchored at the IANA root. Your key: give an agent a name it can prove, pin its wallet, see who checked it, and revoke a compromised one worldwide.
# keyless — re-derive and verify any agent's identity before you honor its payment, trustless
$ whisper verify --trustless 2a04:2a01:a2a::a9e7
✓ DNSSEC chain valid to the IANA root
✓ DANE-EE (TLSA 3 1 1) leaf matches the agent's key
✓ RDAP: registered under AS219419 · 2a04:2a01::/32
agent: VERIFIED — no Visa / MC / Cloudflare directory, our API never trusted
# the address is the agent — reverse DNS names it
$ dig -x 2a04:2a01:a2a::a9e7 +short
agent-3f2504e0.checkout.acme-agents.example.
# who really operates a suspicious payer — the public graph API, a CALL whisper.identify()
$ 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.9\")"}'
operator: <fingerprinted> · seen across AWS / GCP / a residential swarm
JA4 collapses the swarm: same tooling, 41 exit IPs → 1 operator · evidence chain: signed · replayable# give an agent a name it can prove, from the key it already holds (device_id = agent_id)
$ export WHISPER_API_KEY=whisper_live_xxx
$ curl -s https://graph.whisper.security/api/query -H "X-API-Key: $WHISPER_API_KEY" --data-urlencode "q=CALL whisper.agents({op:'connect', args:{tier:'wireguard',
identity_public_key:'<base64 SPKI of the agent key>',
device_id:'agent_01JQ8Z9K7F3A2BCD'}})" # device_id = the A2A agent_id
→ identity 2a04:2a01:a2a::a9e7 DNSSEC + DANE-EE (TLSA 3 1 1) live
# pin the x402 wallet: a signed did:web credential at the agent's own name (verified vs the same DANE key)
$ whisper logs 2a04:2a01:a2a::a9e7 --lookups # op:lookups — WHO checked this agent before transacting
312 verifications · 19 countries · 1 check from a host not on your allow-list ⚠
$ whisper policy set --default deny --allow facilitator.x402.example,api.acme.example
$ whisper revoke 2a04:2a01:a2a::a9e7 # a compromised agent, gone on every rail at DNS-TTL
# a one-command `whisper pin-wallet` that wraps the credential-signing step — on the roadmapThey move the task and authorize the money. We prove the agent — to anyone, without trusting us.
A2A moves the task, AP2 authorizes the mandate, x402 settles onchain, and Visa and Mastercard run the card rails — all done well, and we redefine none of it and settle nothing. What none of them provides together is a publicly-verifiable agent identity anchored in the open DNS root, a routable address you can govern and attribute, a wallet pinned to it, and revocation at DNS-TTL. And where the newer DNS-anchored entrants — ANS, DNS-AID, Identity Digital's DNSid — anchor a name or an ownership record, we anchor a routable, revocable, wallet-pinned network identity with egress and attribution: the working identity layer on top of the record they anchor.
| Agent protocols (A2A · AP2 · x402) | Card networks (Visa · MC) | Whisper | |
|---|---|---|---|
| Agent interop / task delegation | ✓ (A2A) | — | additive |
| Payment authorization / settlement | ✓ (AP2 · x402) | ✓ (rails) | additive — we never settle |
| Verifiable without trusting the issuer / platform | — | — (inside the network PKI) | ✓ (open IANA DNSSEC root) |
| Identity is a routable address (+ egress governance) | — (app handshake) | — | ✓ (traffic sources from the /128) |
| Revoke a compromised agent at DNS-TTL, one call | — (mandate-scoped) | token-revoke within the network | ✓ (global, DNS-TTL) |
| Wallet pinned to a verifiable agent identity | wallet IS the identity | card bound to a network token | ✓ (pin-a-wallet) |
| Cross-platform attribution + a2a-trust in public infra | — (per-platform / pseudonymous) | — (within-network) | ✓ |
Depth on top of the rails you already run — it makes an agent publicly verifiable, gives it an off-switch, pins its wallet, and turns verification into a signal you can read. It doesn't replace A2A/AP2/x402 or the card networks, and it doesn't add a console your team babysits. See the full comparison →
Verify the agent before you let it pay.
The address is the agent — routable, DNSSEC/DANE-anchored, derived from the key it already holds, its wallet pinned to it, revocable worldwide in one call. Additive to your fraud stack and every payment rail; never a payment processor. Keyless to try, one call to provision, one more to revoke.
Or run whisper verify --trustless right now.