# For merchants, payment platforms & agent builders — verify the agent before you let it pay > commerce.whisper.online · for merchants, payment platforms & agent builders ## 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. **We make it a lookup.** The address **is** the agent — a routable, DNSSEC/DANE-anchored **/128** derived from the key the agent already holds, that anyone verifies with `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. **Verify your agents →** https://console.whisper.security/sign-up ### The proof strip - **>1,300%** — agent web-traffic growth in 9 months; trust is now the #1 barrier to agentic commerce (Juniper, Apr 2026). - **~165M** — x402 payments settled on Base across 480,000+ agents; the rails are live and moving money. - **~109:1** — non-human identities now outnumber humans, most authenticated by a bearer secret, not a verifiable identity. - **700+** — trust domains reached in ~10 days on stolen OAuth tokens, and the revocation never propagated. - **25%** — of data breaches could involve AI-agent exploitation by 2028 (WEF). - **0** — cross-platform revocation protocol; a "revoked" agent often keeps transacting elsewhere. --- ## The rails authorize the payment. None anchor the agent. 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. - **SELF-ASSERTED — 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. - **BEARER — 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. - **NO REVOCATION — 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. --- ## Two gaps. Every agent-commerce program has both. 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. ### Gap 1 · you can't prove which agent you're dealing with 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. **Diagram — agent key / agent_id → verifiable, revocable agent name.** An agent's public key — the key behind its A2A Agent Card signature, its Visa TAP RFC 9421 `keyid`, or its AP2 mandate signer — named by its `agent_id`, derives a routable `/128` (`2a04:2a01:a2a::a9e7`); DNSSEC and a DANE-EE `3 1 1` TLSA record anchor it into a name any merchant can verify with `dig` and `openssl`, no Visa / Mastercard / Cloudflare directory; `op:revoke` tears a compromised agent down worldwide at DNS-TTL — the cross-platform revocation the rails leave missing. > **"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. ### Gap 2 · a compromised agent survives revocation and rotates across platforms 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 — billions of nodes and 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. **Diagram — pin-a-wallet / x402: verify the paying agent before /settle.** An x402 payment arrives with a bare `from` wallet address. Before the facilitator settles, it resolves that wallet's pinned `/128` identity — a `did:web` verifiable credential signed by the agent's key, DANE-EE `3 1 1` pinned in DNS — and confirms the agent is real and not revoked, turning pseudonymous money into a known, revocable agent. `op:lookups` records who checked the agent, and `op:revoke` makes a known-bad agent gone on every rail at DNS-TTL. No change to the onchain flow. > **"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. --- ## Four people carry this problem — and each 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. --- ## Where we fit — stated plainly 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. | 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. --- ## 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. - **Agent identity** — agent /128 · DNSSEC · DANE-EE · bound to the `agent_id` + its own key. *Which agent, provably.* Exits into the Agent Card · DID · keyid your rails already read. - **Attribution & analytics** — operator fingerprint across rotating egress, plus `op:lookups` (who checked your agent). Backed by billions of graph nodes over BGP · DNS · TLS · JA4. - **Egress governance** — per-agent /128 · policy · firewall · budget · revoke. *What may talk to what, and one off-switch.* Default-deny, at DNS-TTL. All three exit into the commerce stack you already run: **the payment rails** (A2A · AP2 · x402 · Visa TAP · Mastercard Agent Pay), **your fraud / risk stack** (allow/deny · chargeback evidence), and the tamper-evident, Bitcoin-anchored **transparency log** — not a new silo. Whisper never defines the interop protocol or settles the payment; it anchors the agent they reference and adds the attribution, analytics and revocation they lack. - **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. --- ## Prove it in 60 seconds — 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. ```bash # 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: · seen across AWS / GCP / a residential swarm JA4 collapses the swarm: same tooling, 41 exit IPs → 1 operator · evidence chain: signed · replayable ``` ```bash # 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:'', 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 roadmap ``` **Verify your agents →** https://console.whisper.security/sign-up --- ## They 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 →](/compare) --- ## 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. **Verify your agents →** https://console.whisper.security/sign-up · [See the comparison →](/compare) Or run `whisper verify --trustless` right now. --- *Identity on the wire for autonomous commerce. AS219419 · 2a04:2a01::/32. © 2026 viaGraph B.V. (dba Whisper Security).*