Platform integrations

Whisper sits beside the agent-commerce stack you already run and anchors exactly one thing: a routable, verifiable identity at the agent↔counterparty boundary. That's the layer where a forged Agent Card, a stolen bearer, or a bare wallet key looks identical to the real agent today.

Everything below is a proposed integration pattern: our design, not a vendor endorsement. Every one is written the same way: Whisper complements the mechanism you have; it never replaces it. We do not redefine A2A's transport, we do not authorize an AP2 mandate, and we do not settle an x402 payment or tokenize a PAN. Those live in the protocol and on the rail, and they are already someone's job. Whisper's job is the network identity of whatever is transacting: the Shopping Agent, the mandate signer, the paying wallet, the MCP server. That identity is an IPv6 /128 that DNSSEC, DANE and RDAP can prove and one call can revoke.

Anchor the identity, not the payment

An AI purchase carries several trust mechanisms, each correct for its own layer. The mistake is to imagine a new identity system has to displace one of them. It doesn't. Whisper is deliberately confined to the one place none of them cover: the moment a network endpoint claims to be a particular agent acting for a particular principal, and the counterparty has only a self-asserted Agent Card, a portable bearer token, or a pseudonymous wallet address to go on. The ecosystem concedes the gap in its own words: the card networks launched an open framework in 2025 explicitly to help merchants “distinguish malicious bots from legitimate AI agents”, and an April 2026 industry survey named trust the number-one barrier to agentic-commerce deployment, ahead of every technical concern.

Read the last row as the whole thesis. At the counterparty boundary, agent identity today is a claim: a JSON card the transport is left to verify, a bearer whoever-holds-it can present, or a bare address that proves control of funds and nothing about who. Whisper turns it into a network fact: the source address itself, forward-confirmed in DNS, pinned in DANE, registered in RDAP.

A2A: DANE-anchor the Agent Card, the keystone

Under Google's A2A protocol an agent publishes an Agent Card at /.well-known/agent-card.json: its name, skills, interfaces, declared securitySchemes, and, since v1.0, an optional AgentCardSignature (a JWS over the card, “issued by the domain owner”). Two structural gaps follow. The signature is recommended, not mandated, and A2A deliberately does not mandate how a card is verified. It delegates that to the transport, so a forged or shadow-cloned card at a plausible domain reads as legitimate. And there is no per-agent revocation and no cross-platform anchor for “is this really that agent, and can it be turned off everywhere at once?” The community's answer to the first gap is a central registry proposal: getagentid.dev, tracked as a2aproject/A2A#1672. Whisper is the decentralized alternative to that registry, and it needs no A2A change.

The integration is to publish the Agent Card's signing key as a DANE TLSA record, an _a2a label over DNSSEC, under the agent's own Whisper name. A counterparty resolves the agent's /128, checks the DNSSEC-validated TLSA, and confirms “this card belongs to this agent”, a strictly stronger statement than a CA's “this key belongs to the domain.” Same profile the rest of Whisper uses: DANE-EE 3 1 1, SPKI/SHA-256. A2A's task transport, its card schema, and its securitySchemes are untouched; you are only making the card's signer a name a third party can prove, with a DNS-TTL off-switch A2A never had.

# Publish the Agent Card's signing key as a DANE TLSA under the agent's own name:
# the decentralized alternative to a central registry (getagentid.dev / A2A#1672).
dig +dnssec TLSA _a2a._tcp.7f3ad4e0.<tenant>.agents.whisper.online
;; flags: qr rd ra ad          ← ad = DNSSEC-authenticated
;; _a2a._tcp....agents.whisper.online. 300 IN TLSA 3 1 1 b653a4ef...fcb82d1d

# The address IS the agent: reverse DNS names it, forward-confirmed (FCrDNS).
dig -x 2a04:2a01:a2a::7f3a +short
7f3ad4e0.<tenant>.agents.whisper.online.

# A counterparty confirms the card belongs to THIS agent: no registry, no CA on faith.
whisper verify --trustless 7f3ad4e0.<tenant>.agents.whisper.online
dnssec   pass   DNSSEC-root   AAAA, PTR and TLSA(3 1 1) all DNSSEC-validated to the IANA root
dane     pass   DNSSEC-root   the Agent Card signing key == the TLSA pin
CRYPTOGRAPHICALLY PROVEN, trust anchor: DNSSEC root (IANA) + DANE-EE

Because A2A sits above the payment layers (MCP → A2A → AP2 → x402), anchoring the Agent Card at the top flows a verifiable, revocable identity down into the mandate signer and the paying wallet. One op:'revoke' and the card's identity is gone at DNS-TTL: the per-agent revocation A2A lacks, and the signal a documented 2025 incident class needed when a compromised agent integration spread across 700+ trust domains in days on stolen OAuth tokens because a revocation had no way to propagate:

# Turn one compromised Agent Card off everywhere at once, at DNS-TTL speed.
CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:a2a::7f3a'}})
   YIELD op, ok, status, error RETURN op, ok, status, error

AP2: a verifiable identity for the mandate signer

Google's AP2 (Agent Payments Protocol) is the strongest thing in the stack at what it does: it chains cryptographically-signed Mandates as W3C Verifiable Credentials, an IntentMandate (what the user authorized), a CartMandate (merchant-signed, embedding a W3C PaymentRequest), and a derived PaymentMandate, using ECDSA P-256. It is deliberately not a settlement rail but a trust-and-authorization layer. We do not compete with any of that; we never authorize or sign a mandate.

AP2 has one explicit hole, and it names it: agent identity and key management are deferred to standards bodies (the FIDO Alliance's Agentic Authentication working group) and are not specified in-protocol. So the verificationMethod on a mandate is an opaque public-key or DID reference: it proves a key signed the mandate, not which real agent holds that key or whether it is still authorized. Whisper binds that verificationMethod to a DNSSEC/DANE-anchored /128, so the Credentials Provider and the Merchant can independently confirm “this Shopping Agent key = verifiable agent X, still live”. That closes AP2's stated Authenticity and Accountability gaps, and gives the FIDO working group exactly the durable, publicly-verifiable, revocable agent identity it needs as input.

# The mandate's signer key is bound to a verifiable, revocable /128.
# A Credentials Provider confirms the Shopping Agent before honoring the mandate:
# keyless, trustless, Whisper's own API NOT in the trust path.
curl -s https://whisper.online/verify-identity/2a04:2a01:a2a::7f3a
{"is_whisper_agent": true, "dane_ok": true, "jws_ok": true,
 "revoked": false, "evidence": { "dnssec": "pass", "tlsa": "3 1 1 …", "rdap": "AS219419" }}

See who checked a mandate signer before the payment clears. Because every agent's name resolves through Whisper's own authoritative DNS and RDAP, the owner can ask who looked. op:'lookups' returns who resolved or RDAP-queried an agent's identity: a verification-analytics stream and an early tripwire that someone is enumerating your agents in recon, not a post-mortem after a disputed charge:

# who has been resolving / RDAP-querying this agent's identity, and when
CALL whisper.agents({op:'lookups', args:{agent:'2a04:2a01:a2a::7f3a', window:'24h'}})

And because a mandate (or the receipt an agent hands back) can be signed under the agent's forge-proof /128, the merchant, the PSP, and a dispute reviewer can trust the artifact came from the real agent: non-repudiable provenance bound to a name, not a portable secret.

x402: pin-a-wallet, which real agent is paying

Coinbase's x402 turns an HTTP 402 Payment Required into a settled transaction: the resource server answers with accepts[] (scheme, network as CAIP-2, e.g. eip155:8453 for Base, asset, amount, payTo), the agent's wallet signs an EIP-3009 transferWithAuthorization payload in the PAYMENT-SIGNATURE header (with a nonce to stop replay), and a facilitator's /verify + /settle moves USDC onchain. It has passed 100M+ cumulative transactions on Base through Q1 2026. It is also, by design, identity-light: the agent's identity is the from wallet address, an EOA that is pseudonymous, unattributable, and non-revocable (you cannot revoke an externally-owned account).

Whisper's pin-a-wallet closes exactly that gap without reintroducing accounts and without changing the onchain flow. It binds the from wallet to a DNSSEC/DANE-anchored /128, so a facilitator or resource server can resolve the paying address to a verifiable, revocable agent identity before honoring the 402. That turns “anonymous money” into “a known, revocable agent is paying, allow or deny.” The wallet key can't be revoked; the agent's ability to transact behind it can: op:'revoke' the /128 and the binding fails, so the EOA still signs but no accountable agent stands behind it.

# The pin-a-wallet recipe binds the x402 `from` wallet to the agent's DANE identity.
# See /docs/pin-a-wallet for the signed binding; the result is checkable by any facilitator:
whisper verify --trustless 2a04:2a01:a2a::7f3a
  ✓ identity VERIFIED (DNSSEC + DANE-EE, IANA root); the bound `from` wallet re-checks offline
  → allow the 402

# One call ends the agent's ability to transact: the EOA still signs, but the binding is gone.
CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:a2a::7f3a'}})   // facilitator now denies

MCP: a DANE-anchored server identity for the canonical URI

The Model Context Protocol identifies a server by its canonical resource URI: the OAuth resource parameter (RFC 8707), discovered via /.well-known/oauth-protected-resource (RFC 9728) and enforced with audience-bound tokens under OAuth 2.1 + PKCE. That establishes where a server is and which token is valid for it, but the server's identity still rests on Web-PKI TLS plus a bearer: there is no per-server cryptographic identity beyond the CA bundle, and no revocation beyond token expiry. A stolen bearer therefore appears legitimate, and the token-passthrough / confused-deputy risks the spec warns about have no identity to check against.

The integration is to give the canonical resource URI a Whisper /128 and DANE-pin its TLS endpoint, so a client validates the MCP server against the DNSSEC root rather than any-CA-will-do, and the token's audience (RFC 8707) is bound to a name the client can independently prove. Nothing in the OAuth flow or the MCP transport changes.

# DANE-pin the /128 that serves the RFC 9728 canonical resource URI: no shared-CA trust.
dig +dnssec TLSA _443._tcp.mcp.7f3ad4e0.<tenant>.agents.whisper.online
;; flags: qr rd ra ad
;; _443._tcp.mcp....agents.whisper.online. 300 IN TLSA 3 1 1 b653a4ef...fcb82d1d

# A client proves the MCP server against the DNSSEC root before trusting the bearer's audience.
whisper verify --trustless mcp.7f3ad4e0.<tenant>.agents.whisper.online

ANS, AID & the DNS-anchored peers: interoperate, don't compete

Honesty first: Whisper is not the only project anchoring agent identity in DNS anymore. A cohort of neighbors arrived through 2026: Identity Digital's DNSid, the Agent Name Service (ANS), and DNS-AID / AID, anchoring an agent's name or ownership record to a domain via DNSSEC-signed SVCB records (an _agent / _ag label) alongside the Cloudflare Web Bot Auth ecosystem (Ed25519 request signatures, RFC 9421). We do not claim to have invented or to own the category, and these are not vendor endorsements.

The right posture is to interoperate. Those peers anchor a name or an ownership record; by their own descriptions they do not deliver a routable address, egress governance, wallet binding, or DNS-TTL revocation. A Whisper /128 is exactly the working identity that sits on top of the record they anchor: point an AID _agent record (or an ANS entry) at the Whisper name, and a resolver following either scheme hands back an identity a verifier can then prove trustlessly and attribute by reverse DNS.

# Interoperate: point an AID _agent record (or an ANS entry) at the Whisper /128.
# The name / ownership record stays theirs; the routable, revocable identity is ours.
_agent.acme-agents.example.com.  300  IN  SVCB  1  7f3ad4e0.<tenant>.agents.whisper.online. (
        alpn=h2  ipv6hint=2a04:2a01:a2a::7f3a )

# A resolver following AID/ANS returns the Whisper name; the verifier then proves it trustlessly.
dig -x 2a04:2a01:a2a::7f3a +short
7f3ad4e0.<tenant>.agents.whisper.online.
whisper verify --trustless 7f3ad4e0.<tenant>.agents.whisper.online

The SIEM feed: Splunk, Sentinel & OpenCTI today

Identity and attribution are only useful to a fraud or risk team if they land in the tools it already runs. Whisper emits every finding as a signed JSON evidence chain: a whisper.identify attribution result, an op:'lookups' enumeration alert, an identity mint or revoke from the transparency log. That's machine-readable enrichment for your fraud stack and threat-intel, not another console an analyst babysits.

The Splunk connector is shipped today. It maps each signed finding onto CEF and ECS fields and forwards it into Splunk, so “an agent we never verified is enumerating our checkout identities” or “this paying wallet's agent was revoked” becomes a correlatable event beside your existing bot-management and payment-fraud telemetry:

# The signed finding the Splunk connector maps to CEF / ECS and forwards.
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(\"2a04:2a01:a2a::7f3a\")"}' | jq '.result.evidence'
# -> a replayable, signed evidence chain -> CEF: deviceVendor=Whisper cs1=agentIdentity …
#    (the connector emits one event per finding; the chain re-verifies offline)

The Microsoft Sentinel connector and OpenCTI threat-intelligence integration ship today, mapped onto Sentinel's connector framework and OpenCTI's knowledge graph for continuous-monitoring workflows. STIX 2.1 over TAXII export is on the roadmap, not shipped. It is listed honestly under On the roadmap below.

Shipped today vs proposed

Honesty about what runs matters more here than anywhere. The identity primitive under every integration is live and provable right now; the integration guides themselves are proposed patterns for wiring that primitive into each protocol.

# The spine every integration builds on: derive the agent's /128 from the key it already
# holds + its agent id. identity_public_key is the agent's PUBLIC SPKI: the private key
# never leaves the agent; the derivation is deterministic and tenant-bound (fleet-unlinkable).
CALL whisper.agents({op:'connect', args:{
  tier:                'wireguard',
  identity_public_key: '<base64 SPKI of the agent signing key>',
  device_id:           '7f3ad4e0-a2a1-4b6c-9e2f-c0ffeecafe01'   // the agent id
}}) YIELD op, ok, status, result, error
   RETURN op, ok, status, result, error
{"ok": true, "status": 200, "result": {
   "address": "2a04:2a01:a2a::7f3a",
   "wireguard": { "…": "…" }}}          // -> the deterministic /128 + a WireGuard config

On the roadmap

These feed agent-identity evidence into the tools a fraud, risk, or trust-and-safety team already runs. They are roadmap, not yet shipped, listed here so you can see where this goes:

• Microsoft Sentinel connector: shipped today, alongside the Splunk connector.
• OpenCTI threat-intelligence integration: shipped today.
• STIX 2.1 over TAXII export: roadmap. Maps identity and egress evidence onto standard TI transports for continuous-monitoring and dispute-attribution workflows.
• First-class typed --agent-id argument: roadmap. Today the generic device_id already accepts an agent id, an Agent Card id, or an AP2 verificationMethod reference.
• Independent witnessing of the transparency log: roadmap. Tamper-evident and Bitcoin-anchored today; external co-signing via C2SP tlog-witness is the next step.

Next

• Agent identity: the shipped derivation these integrations all build on
• Agent-fraud cure: the primary wedge, verifiable identity at the counterparty boundary
• PSD2 · agent-payment protocols: where the evidence lands for delegated authority and disputes