# 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. > **One spine under all of them.** Each integration below reuses the same shipped primitive: a deterministic `/128` derived from the agent's *public* key plus its agent id, passed as `device_id` ([Agent identity](/docs/industries/commerce/agent-identity)), published with a DANE-EE `3 1 1` pin and an RDAP record, verifiable by anyone with no account. The integrations differ only in *which identifier* in your stack that identity is bound to and checked at. ## 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. | Layer | Owner / mechanism | Whisper's role | |---|---|---| | The agent's own reasoning / prompt | injection defense: content provenance, plan/act separation, input sanitization | **none**: never touches the model's reasoning | | Payment authorization (the mandate) | AP2: VC-signed Intent / Cart / Payment mandates | **none**: never authorizes or signs a mandate | | Settlement rail | x402 onchain (EIP-3009) · card-network token (MDES) | **none**: never moves funds or tokenizes a PAN | | Agent ↔ counterparty (identity / IP boundary) | Agent Card / OAuth bearer / wallet key | **anchors here**: an out-of-registry `/128` the caller *is*, provable without any platform, network or registry | 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. ``` owned by AP2 / the rails / injection defense: Whisper never here │ the one layer Whisper anchors │ ┌─────────────────────────────────────────────────────────┐ │ ┌──────────────────────────────────────┐ │ The agent's reasoning / prompt · provenance/sanitize ✕│ │ │ Agent ↔ counterparty: identity bound │ │ Payment authorization: mandate · AP2 VC-signed ✕│ the │ │ Agent Card · OAuth bearer · wallet key│ │ Settlement rail · x402 EIP-3009 / MDES token ✕│ fence │ │ │ derive + publish │ └─────────────────────────────────────────────────────────┘ │ │ agent /128 · DNSSEC · DANE-EE 3 1 1 │ │ │ bound to the agent id ✓ anchors │ │ └──────────────────────────────────────┘ ``` *The reasoning, the mandate and the rail stay theirs. Whisper never crosses the fence; it anchors one layer: the identity of the agent on the network, provable without any platform, network or registry.* > **Necessary, not sufficient. We say so plainly.** A verifiable identity does *not* stop a legitimately-authenticated agent from making a bad purchase, it does not prevent prompt-injection of the agent's own reasoning, it does not undo a confused-deputy trick *within* granted scope, and it does not stop a thief who has stolen the signing key itself. What it does is close the gaps the payment protocols left open: *which* agent, acting *for whom*, prove it, attribute it, revoke it. And it makes every *other* control (mandate scope, spend caps, injection defense, human approval) enforceable against a durable subject and auditable after the fact. Identity is the missing anchor the rails were built without; it is not a substitute for the guardrails on top. ## 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..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..agents.whisper.online. # A counterparty confirms the card belongs to THIS agent: no registry, no CA on faith. whisper verify --trustless 7f3ad4e0..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 ``` ``` the stack: MCP → A2A → AP2 → x402, each with its own identifier ┌──────────────────────────────────────────────────────────┐ │ MCP canonical resource URI (9728)│──┐ │ A2A: the keystone AgentCardSignature key (JWS) │──┤ ┌───────────────────────┐ │ AP2 VC verificationMethod (P-256)│──┼──▶ │ One agent /128 │ │ x402 from: the paying wallet (EOA)│─┘ │ 2a04:2a01:a2a::7f3a │ └──────────────────────────────────────────────────────────┘ │ DNSSEC · DANE · revoke │ anchor the top → trust flows down the stack └───────────────────────┘ ``` *A2A is the strongest wedge because it sits at the top of the stack and has the weakest current anchor. Bind the Agent Card's signer to one DNSSEC/DANE `/128`, and the same verifiable, revocable identity becomes available to the AP2 mandate and the x402 wallet below it, without redefining any of them.* > **Complements A2A, does not replace it.** Whisper does not define your skills, your task lifecycle, or your `securitySchemes`. That stays A2A's. It only makes the Agent Card's *signer* a resolvable, DNSSEC-anchored, revocable identity instead of a self-asserted key a counterparty is left to trust. See [Agent-to-agent trust](/docs/a2a-trust) for the mutual verify-the-counterparty handshake, and [DANE & TLSA](/docs/dane) for the byte-for-byte record. ## 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](/docs/sign-outputs) 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. > **Complements AP2, does not replace it.** The mandate chain, its VC schema, and its authorization semantics stay AP2's. Whisper never signs or authorizes a mandate. It supplies the one thing AP2 defers to FIDO: a publicly-verifiable, DNSSEC-anchored, revocable identity for the agent *principal* behind the `verificationMethod`. See [PSD2 · agent-payment protocols](/docs/industries/commerce/commerce-compliance) for how this maps to delegated-authority and dispute-attribution requirements. ## 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 x402 onchain flow: unchanged ┌──────────────┐ PAYMENT-SIGNATURE ┌────────────┐ ┌──────────────┐ │ Agent wallet │ ──────────────────▶ │ Facilitator│ ─────▶ │ USDC on Base │ │ from · EIP-3009 │ /verify /settle │ eip155:8453 │ └──────┬───────┘ └─────┬──────┘ └──────────────┘ │ pin-a-wallet │ resolve before /settle ▼ ▼ ┌──────────────────────────────┐ ┌────────────────────────────────┐ │ Agent /128 · DNSSEC · DANE-EE │ │ "which real agent is paying?" │ │ 2a04:2a01:a2a::7f3a: revocable│ │ verified + not revoked → allow │ │ the from wallet is bound here │ │ revoked → binding fails → deny │ └──────────────────────────────┘ └────────────────────────────────┘ no accounts reintroduced · no change to the onchain flow ``` *Pin-a-wallet layers accountability onto x402 without touching settlement: the `from` address is bound to a verifiable, revocable `/128`, and the facilitator resolves it before `/settle`. The EOA still can't be revoked. The agent behind it can.* ``` # 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 ``` > **Beyond identity, govern it.** The same agent `/128` is a control point: `op:'policy'` sets **default-deny** egress so the agent reaches only the merchant and facilitator you allow; `op:'firewall'` allows/denies by host, CIDR or port; `op:'budget'` caps the agent's traffic and is a kill-switch; `op:'revoke'` ends it worldwide at DNS-TTL. Governing *what an agent may talk to*, and capping it, is the layer x402's bare wallet has no place to put. See [Egress governance](/docs/egress-governance). > **Complements x402, does not replace it.** The `402` handshake, the EIP-3009 authorization, the `nonce`, and the facilitator's `/verify` and `/settle` stay exactly as they are. Whisper never moves the funds. It adds the accountability layer x402 deliberately left out: *which* agent is behind the paying wallet, and one call to revoke it. ## 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..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..agents.whisper.online ``` > **Complements MCP's OAuth model, does not replace it.** The canonical resource URI, the discovery documents, the PKCE flow and the audience-bound tokens stay MCP's. Whisper anchors the *server's transport identity* to the DNSSEC root and gives it a DNS-TTL off-switch that complements short-lived tokens. The mutual verify-the-counterparty step that blunts confused-deputy is on [Agent-to-agent trust](/docs/a2a-trust). ## 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..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..agents.whisper.online. whisper verify --trustless 7f3ad4e0..agents.whisper.online ``` > **Complements ANS / AID / DNSid, does not replace them.** Where they anchor a *name* or an *ownership record*, Whisper anchors a *routable, revocable, wallet-pinnable* network identity: the address *is* the agent, so it also carries egress governance and reverse-DNS attribution. The two compose: their discovery record resolves to our verifiable `/128`. ## 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) ``` > **Nothing issued in the dark.** Every identity mint and every revoke is written to a public, append-only [Merkle transparency log](/docs/transparency) (RFC 6962 `tlog-tiles`, Ed25519-signed, anchored to Bitcoin via OpenTimestamps): an auditable, non-repudiable issuance-and-revocation trail your risk team and a dispute reviewer can replay. *Honest status:* the log is tamper-evident, signed and Bitcoin-anchored today, but it is **not yet independently witnessed**. Our two authoritative nodes co-signing is availability, not independence. It already speaks the C2SP `tlog-witness` protocol, so any external witness can co-sign; that step is on the roadmap and we label it as such rather than overclaim. 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](#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. | Building block | Status | |---|---| | Deterministic `/128` from an agent's public key + agent id (as `device_id`) | **shipped, live** | | Provision via the control plane (`op:'connect'`, WireGuard tier) | **shipped, live** | | Keyless verify: `whisper verify --trustless`, `/verify-identity`, `dig -x`, RDAP | **shipped, live** | | DANE-pin an existing endpoint's / signer's key (Agent Card, MCP server) over DNSSEC | **shipped, live** | | Pin-a-wallet (bind a wallet to the DANE identity) · a2a-trust | Assemble today via the control plane; turnkey `whisper pin-wallet` / `whisper sign` verbs are **roadmap** | | Revoke: `/128` + PTR + DANE torn down at DNS-TTL speed | **shipped, live** | | Egress governance: `op:'lookups'`, `op:'firewall'`, `op:'budget'`, `op:'policy'` | **shipped, live** | | Attribution graph over the public API (`CALL whisper.identify(…)`) | **shipped, live** | | **Splunk** connector: signed findings mapped to CEF / ECS | **shipped, live** | | The five integration *guides* on this page (A2A, AP2, x402, MCP, ANS/AID) | **proposed**: our design, not a vendor endorsement | > A dedicated `--agent-id` CLI flag is **on the roadmap, not shipped**. Agent provisioning today goes through the control-plane call below, which *is* live, with the agent id passed as the generic `device_id`. The CLI verbs that exist are `whisper verify --trustless`, `whisper create --register`, `whisper kill --revoke`, `whisper policy` and `whisper logs`. ``` # 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: '', 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](/docs/industries/commerce/agent-identity): the shipped derivation these integrations all build on - [Agent-fraud cure](/docs/industries/commerce/agent-fraud-cure): the primary wedge, verifiable identity at the counterparty boundary - [PSD2 · agent-payment protocols](/docs/industries/commerce/commerce-compliance): where the evidence lands for delegated authority and disputes --- ← [Agent-fraud cure](/docs/industries/commerce/agent-fraud-cure) · [PSD2 · agent-payment protocols](/docs/industries/commerce/commerce-compliance) →