Commerce compliance: PSD2/SCA, the agent-payment protocols & the EU AI Act

PSD2 strong customer authentication, the card networks' new agent-payment rails (Visa Trusted Agent Protocol, Mastercard Agent Pay, ACP, AP2, x402), MCP and the EU AI Act all press an agent-commerce stack on one question: which agent is transacting, is it still authorised, and can you prove it and revoke it?

A checkout gated by an API key or an OAuth bearer token cannot answer that: a bearer credential grants access to whoever holds it, not to a verified agent. A routable, DANE-provable, one-call-revocable IPv6 /128 per agent can. It produces the identity, the attribution and the kill-switch these frameworks want as evidence, not as a paragraph in a policy binder. This page is the honest map of where that evidence fits, and, just as important, where it does not. Whisper is the identity layer beneath the payment; it never sits inside the payment message or the settlement rail.

What every framework is really asking

Read the agentic-commerce specs and the payments regulation side by side and the same three questions surface, phrased in a dozen vocabularies:

• Identity: which agent is on the other end of this checkout, and can a merchant, a facilitator or a peer agent verify it without trusting your word for it or registering in your private directory?
• Attribution & monitoring: what did that agent do, to which destinations, who is enumerating it, and can you show a continuous, non-repudiable record for the chargeback fight and the audit?
• Response: when an agent turns hostile or its mandate should end, can you contain it, provably and fast, across every network and domain at once?

None of these is a logging problem you fix with more log lines. They are identity problems: you cannot attribute, monitor or contain an actor that has no stable, provable identity in the first place. Here is the load-bearing finding of the whole standards survey, verified across A2A, AP2, x402, MCP, Visa TAP and Mastercard Agent Pay: none of them anchor agent identity in DNS/DNSSEC. Trust today is a signed document over web PKI (A2A, MCP), an opaque public-key reference in a verifiable credential (AP2), a pseudonymous blockchain address (x402), or a proprietary per-network directory (Visa's JWKS, Mastercard's registry). A2A, AP2, x402 and MCP have no agent revocation at all; Visa and Mastercard have revocation, but only inside their own walled garden. "Which agent, really, and can I revoke it globally" is unsolved or single-vendor everywhere. Whisper's job is to give every agent an identity that is globally addressable, publicly verifiable and universally revocable, then let each protocol and each auditor read the evidence off it.

Three verdicts, stated up front

Here is the grading rule before a single row of the map, because a commerce-compliance page that claimed to "make you PSD2-compliant" or "perform SCA" would be lying. Whisper is a network primitive. Against a given framework it does exactly one of three things, and we mark which:

The evidence: real, and shipped

Everything this page grades DIRECT-ADDITIVE rests on primitives that exist and answer today. Each is checkable with dig, curl, or one control-plane call over the public API: POST https://graph.whisper.security/api/query with your X-API-Key.

A device-derived /128 identity

An agent already holds a key: the signing key behind its A2A Agent Card, the verificationMethod that signs its AP2 mandates, a TPM, or a secure element. Whisper derives a deterministic IPv6 /128 from that key's public SubjectPublicKeyInfo, with the agent id as the domain separator, passed as the generic device_id argument. The address is tenant-bound (fleet-unlinkable to an outsider), DNSSEC-anchored, DANE-EE 3 1 1 pinned, and RDAP-registered. Re-deriving from the same key and agent id yields the same /128; nothing new to store. The agent id alone yields nothing: you cannot go agent-id → /128 without the key.

# Provision an agent identity from the key it already holds (control plane, live).
# identity_public_key is the base64 SPKI of the agent's own signing key.
CALL whisper.agents({op:'connect', args:{
  tier:'wireguard',
  identity_public_key:'<base64 SPKI of the agent key>',
  device_id:'agent_01J9Z8ER2MQK3'   // your agent id, the same id your A2A card / AP2 mandate carries
}}) YIELD op, ok, status, result, error RETURN op, ok, status, result, error
# -> deterministic /128 + a WireGuard config. Same key + agent id -> same /128 (idempotent).
#    A different agent id on the same tenant -> 409; a non-string device_id -> 400. Never a 500.

Per-/128 logs, and who checked your agent

Because each agent owns a dedicated /128, every DNS lookup and connection it makes is unambiguously its: no shared-IP noise to reconstruct for the dispute file. And because the identity resolves through Whisper's own authoritative DNS and RDAP, you can also ask who is checking you: a merchant or facilitator resolving your agent's PTR/AAAA/TLSA before honouring a request is exactly the "is this a real, still-authorised agent?" lookup the card networks launched their frameworks to enable. Now it is a verification-analytics stream and a reconnaissance tripwire, not a post-mortem.

# The agent's OWN outbound activity, per-event: timestamp, kind, destination, decision, bytes
CALL whisper.agents({op:'logs',    args:{agent:'2a04:2a01:c0::a9e7', kind:'conn', from:'-24h'}})

# Reverse observability: WHO resolved this agent's PTR/AAAA/TLSA or hit its RDAP object, and when
CALL whisper.agents({op:'lookups', args:{agent:'2a04:2a01:c0::a9e7', window:'24h'}})
curl -s https://whisper.online/ip/2a04:2a01:c0::a9e7/lookups | jq   # same view, keyless

Govern the mandate: policy, firewall, budget

A verifiable identity is also a governable one. The same control plane that mints the /128 bounds what it may talk to, caps it, and kills it: the enforcement surface that turns a written mandate scope into a control that actually holds at the network boundary.

# Default-deny egress; allow only the merchant + the facilitator this agent is mandated to reach
CALL whisper.agents({op:'policy',   args:{agent:'2a04:2a01:c0::a9e7', default:'deny',
                                    allow:['checkout.example-shop.com', 'facilitator.example-psp.com']}})
CALL whisper.agents({op:'firewall', args:{agent:'2a04:2a01:c0::a9e7', deny:['0.0.0.0/0'], allow_port:[443]}})
CALL whisper.agents({op:'budget',   args:{agent:'2a04:2a01:c0::a9e7', cap:'250MB/day', on_exceed:'revoke'}})

One-call revoke: universal, not per-network

Containment, and the end of a mandate, is a single call. It tears down the /128, its PTR and its DANE record worldwide at DNS-TTL speed. This is the primitive the whole ecosystem is missing: today, when one domain revokes a compromised agent, connected domains have no standard mechanism to receive that signal. A public class of incident saw a compromised agent integration spread across 700+ trust domains in roughly ten days on stolen OAuth tokens, because revocation didn't propagate. Whisper's revocation is a property of the identity itself, so it is universal by construction.

CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:c0::a9e7'}})
# after the TTL:
dig -x 2a04:2a01:c0::a9e7 +short                          # -> empty
curl -s https://whisper.online/verify-identity/2a04:2a01:c0::a9e7   # -> {"is_whisper_agent": false}

The attribution graph

Turning a raw destination, or a suspicious counterparty in your logs, into "known-bad" or "clean" is a read-only query against the public graph API. Attribution survives IP rotation because it fingerprints the operator and the tooling (ASN and hosting genealogy for cloud rotation, a JA4/JA3 client fingerprint for a residential-proxy swarm), not the ephemeral egress IP, which is exactly what an impersonating agent rotates to evade correlation across sessions and platforms.

curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" \
  --data-urlencode "q=CALL whisper.identify('185.220.101.1')"
# -> what the address is, who operates it, threat-intel reputation, relationships:
#    a reproducible, replayable JSON evidence chain your fraud team and a regulator can replay.

The read-only verbs (identify, origins, walk, variants, history) run the same way, over an infrastructure-and-threat-intelligence graph of billions of nodes. That is the enrichment that turns a per-agent egress log into a detection.

The map, at a glance

Each row is a framework, what it asks for, how tight the technical mapping is (● full · ◐ partial · ○ marginal / forward-looking · ✗ none), our verdict, and the shipped evidence behind it. Read the verdict column first: it is the load-bearing part.

^¹ COMPLEMENTARY against the EU AI Act's traceability/logging/oversight obligations for agents-as-AI-systems; Whisper supplies evidence, never a conformity assessment. PSD3/PSR final text was agreed 23 April 2026 and hands the EBA a mandate for a new SCA RTS. The RTS is not yet published, so any mapping to delegated-agent authentication under PSD3 is forward-looking, not a current certification.

DIRECT-ADDITIVE: the evidence and the anchor we produce

Where a framework asks a question the shipped primitives answer, Whisper is a concrete input to your compliance and fraud package. Never the whole standard: one verifiable control, with reproducible artifacts.

PSD2 / SCA: the delegation anchor, stated carefully

Start with the sharpest honesty on the page, because it is the one most tempting to fudge. PSD2 strong customer authentication assumes a human strongly authenticates; an autonomous agent is not the customer, and the EBA has ruled that the responsibility for SCA compliance "cannot be outsourced: issuers remain fully responsible" (Q&A 6141). Whisper does not, and cannot, perform SCA. What it supplies is the piece the delegated-authority and mandate models are missing: a durable, verifiable identity for the agent that acted under a mandate, so the SCA/mandate evidence chain has an attributable subject: who the agent is, that it is still authorised, and an instant, provable off-switch, all without shifting any SCA liability. The issuer keeps the responsibility; Whisper hands the delegated agent a cryptographic anchor.

PSD2 dispute & liability: a subject for the chargeback fight

The merchant eats the chargeback when an agent purchase is disputed, and the liability chain across merchant, PSP, model developer and deploying business is, in the industry's own words, "entirely unclear." Every one of those parties needs the same thing to allocate liability: a stable, attributable answer to which agent did this. Because every request carries a revocable, publicly-verifiable /128 and its egress is source-bound to that identity, "which agent, from where, still authorised?" is a lookup rather than a guess, and the attribution graph names the operator behind a session even after the egress IP rotates. This is DIRECT-ADDITIVE to the dispute file, not a replacement for the scheme's dispute process.

KYA: Know Your Agent, two pillars delivered

The emerging Know-Your-Agent model names four pillars: a cryptographic agent identity, an agent passport, machine-enforceable authorization, and continuous accountability. Whisper delivers two outright: pillar 1 is the device-derived /128, and pillar 4 is the per-/128 logs, op:lookups, the signed graph evidence chains and the append-only transparency log. It anchors the other two (the passport binds to the /128; machine-enforceable authorization rides op:policy/op:firewall). The honest line: Whisper is the identity substrate KYA is missing, not a KYA or KYC provider. It binds a technical identity; it does not make the KYC judgment about the human or legal entity behind the agent.

NIST NCCoE & OWASP: a deployed "agent passport"

NIST's NCCoE project on Software & AI-Agent Identity (Feb 2026) and the OWASP Agentic Top-10 (2026) both describe, in the abstract, exactly the primitive this page ships: a verifiable agent identity that closes the "attribution gap" OWASP files under ASI03, Identity & Privilege Abuse. The NCCoE work frames it against MCP, NGAC and SP 800-207 Zero Trust; the agent id → /128 is a concrete, deployed, DNSSEC-anchored instance of the "agent passport" those documents sketch. This is guidance-additive: a shipped implementation of an advisory primitive, not a conformance claim against a control number.

COMPLEMENTARY: one identity under every protocol

The agent-payment protocols and the card networks each carry their own identity or trust model, and each leaves the same hole. Whisper does not redefine or replace any of them. It anchors the identifier they already use to a DNSSEC/DANE /128, and adds the revocation they lack. The load-bearing fact that makes this possible is that the identifier fields to DANE-pin already exist and are stable: A2A's url and AgentCardSignature, AP2's VC verificationMethod, x402's from/payTo, MCP's resource URI, Visa's keyid, Mastercard's agent certificate. So the /128 slots under each without any protocol change.

A2A: the Agent Card, made verifiable and revocable

The A2A Agent Card lives at /.well-known/agent-card.json and, since v1.0, can carry an AgentCardSignature: a JWS over the card whose trust root is the domain owner via web PKI. That proves the card "belongs to the domain," never that it belongs to this specific agent, and A2A does not mandate how a card is verified. That's the gap behind Agent-Card shadowing and impersonation. There is no per-agent revocation. Whisper DANE/TLSA-pins the card's url and signing key to the agent's /128, so a verifier resolves the /128, checks the DNSSEC-anchored TLSA record, and gets "this card belongs to this agent," stronger than "belongs to the domain," and revocation becomes pulling the DNS/RDAP record. A2A is the strongest wedge precisely because it sits at the top of the stack (MCP → A2A → AP2), so anchoring it flows trust downward into the payment legs.

AP2: the identity layer it defers to FIDO

AP2 chains cryptographically-signed Mandates as W3C Verifiable Credentials (JSON-LD, ECDSA P-256): an Intent Mandate (what the user authorised), a Cart Mandate (merchant-signed), and a Payment Mandate the network sees. The mandate machinery is well specified, and AP2 explicitly defers agent identity and key management to a standards body (the FIDO Alliance's Agentic Authentication effort); it is not specified in-protocol, and AP2's own guidance says to "validate agent_id via allowlist registries." That deferred layer is exactly Whisper's lane: bind the VC's verificationMethod to a DNSSEC/DANE-anchored /128 so the Credentials Provider and the merchant independently confirm "this Shopping Agent key = verifiable agent X," which closes AP2's stated Authenticity and Accountability goals. A publicly-verifiable, DNSSEC-anchored allowlist for agent_id is the registry AP2 points at. AP2's terminology is still evolving (the live spec now speaks of a Checkout Mandate and a Payment Mandate); we track the identifier field, which is stable, not the field names.

x402: pin the wallet, keep the rail

x402 answers HTTP 402 with an onchain payment: the resource server advertises what it accepts (an exact scheme, a CAIP-2 network such as eip155:8453 Base, a USDC asset, a payTo), and the agent signs an EIP-3009 transferWithAuthorization. Settlement is trust-minimised, but the payer's identity is a bare from EOA: pseudonymous, unattributable, and non-revocable, because you cannot revoke an externally-owned account. The pin-a-wallet recipe binds that from wallet to the agent's verifiable /128, so a facilitator or resource server resolves the address to a known, non-revoked agent before honouring the 402, with no change to the onchain flow. Revoking the /128 revokes the agent's ability to transact, even though the key itself cannot be revoked. Whisper adds the identity; it never touches the settlement.

MCP: DNSSEC identity beside the OAuth

MCP identifies a server by its canonical URI (the OAuth resource parameter, RFC 8707) and authenticates with OAuth 2.1 + PKCE bearer tokens. Identity is web-PKI/TLS plus a bearer: there is no per-agent cryptographic identity, and no revocation beyond token expiry, so a stolen bearer "appears legitimate." Whisper DANE-anchors the server's /128 for identity beyond CA-trust, and the a2a-trust pattern gives the mutual verify-the-counterparty step MCP lacks, a real mitigation for the confused-deputy and token-passthrough threats that make agents dangerous identity-aggregation points. DNS revocation complements short-lived tokens; it does not replace the OAuth flow.

Visa & Mastercard: the neutral anchor beside the walled garden

The card networks shipped the strongest agent-identity requirements of anyone, and each built a proprietary directory. Visa's Trusted Agent Protocol has agents sign requests with HTTP Message Signatures (RFC 9421) carrying a keyid, with public keys at a Visa-operated well-known JWKS; revocation is key removal from Visa's directory. Mastercard's Agent Pay issues an MDES Agentic Token binding cardholder, registered agent and mandate scope, verifies the agent's certificate at checkout against a Mastercard trusted-agent registry, and revokes by deactivating the registry entry. Both are excellent, and both are single-network: an agent must register in each, and revocation reaches only that network. Whisper is the complement neither is: DNSSEC/DANE is literally a well-known, publicly-verifiable public-key directory anchored in DNS, so the Visa keyid or the Mastercard agent cert can be DANE-pinned to one globally-resolvable /128 the agent presents across every protocol and to any merchant, not only the Visa- or Mastercard-registered ones, and revocation becomes universal (pull the DNS/RDAP record) rather than per-network. It interoperates with their directories; it does not replace MDES or tokenize the PAN.

ACP & the EU AI Act

OpenAI/Stripe's Agentic Commerce Protocol encodes agent identity inside a single-use, constrained Delegated Payment token for dispute attribution. Whisper is the durable identity that token and record point at, so attribution outlives any one token. The EU AI Act treats agents as AI systems subject to traceability, logging, human-oversight and accountability obligations; a per-agent identity, attributable egress logs, and an auditable issuance/revocation trail are natural evidence for those obligations. Both are COMPLEMENTARY: Whisper supplies the identity and attribution substrate, never a conformity assessment against the Act or a replacement for the ACP flow.

The DNS-anchored-identity standards track: we implement and interoperate

Whisper is not inventing DNS-anchored agent identity in a vacuum; it is a deployed implementation on an emerging, largely draft-stage standards track, and it interoperates with the primitives that track is built on:

• IETF DANCE: DANE Authentication for Named Entities extends DANE/TLSA from servers to client and entity certificates. The per-agent DANE-EE 3 1 1 pin is exactly this pattern, applied to an agent's /128. See DANE & TLSA.
• IETF WIMSE: Workload Identity in Multi-System Environments is standardising how a workload proves identity across trust domains; a DNSSEC/DANE-anchored, globally-resolvable agent /128 is a concrete workload-identity anchor that composes with that work.
• DNS-AID: the DNS-anchored agent-identity proposal: use the DNS itself as the resolution and trust root for an agent identifier, which is the architecture Whisper already runs in production.
• OWASP ANS: the Agent Name Service proposal for naming and discovering agents; a Whisper name is a DNSSEC-signed, DANE-pinned instance of exactly such a record.
• agentcommunity AID: Agent Identity & Discovery, a community spec resolving agent metadata through DNS; the Whisper /128 and its RDAP object slot under it as the verifiable-identity layer.

DO-NOT-CLAIM: stated plainly

The most useful rows on a compliance page are the ones a vendor omits. These are real, they matter, and Whisper is honestly not them. We list them so nobody plans against an over-claim:

• Not a payment processor or PSP. Whisper does not settle payments, move funds, tokenize the PAN, or issue Agentic Tokens. It is the identity layer beneath the tokens and the rails, never a replacement for either.
• Not PSD2/SCA compliance, and not an SCA factor. SCA authenticates a human; per the EBA, the responsibility "cannot be outsourced." Whisper supplies evidence and attribution of which agent acted under a mandate; it complements the delegated-authority model, it does not satisfy SCA. Every SCA sentence on this page is framed as evidentiary.
• Not PCI-DSS. Whisper never sees, stores or transmits cardholder data and is not part of the cardholder-data environment.
• Identity is not intent. A verifiable identity proves who acted and for whom, not whether the decision was good. It does not stop a legitimately-authenticated agent making a bad purchase, prevent prompt-injection of the agent's own reasoning, stop a confused-deputy trick within granted scope, or defend against theft of the signing or wallet key itself. It makes those actions attributable and revocable and lets you bound authority. The guardrails on top (mandate scoping, spend caps, injection defence, human approval, key custody) remain necessary.
• Not the sole DNS agent-identity scheme. Whisper interoperates with the standards track above; it is one deployed implementation in an emerging field, not the only way to anchor an agent in DNS.
• Not VASP-grade KYC. For the FATF Travel Rule, pin-a-wallet supplies the wallet↔identity attribution primitive the originator question is missing; it does not perform VASP-grade verification of the human or legal person, and "pin-a-wallet solves the Travel Rule" would overstate it. The VASP still owns collect/verify/transmit.

The honest caveat, and where the fit is strongest

Buyer trust is built by naming the limits before the sales call does. Two things to hold onto:

• DANE/DNSSEC agent identity is strongest as an additive layer at the transaction boundary: a verify + kill-switch + pin-a-wallet control that a merchant, facilitator or peer agent runs before honouring a request, and an attribution + revocation record they hold after. It is not a settlement rail and it never sits inside the payment message. Used there, it is the missing anchor the rails were built without; used anywhere else, it is over-claimed.
• The rails are in motion. AP2 terminology is evolving, the PSD3/PSR SCA RTS is not yet published, and the schemes have not formally classified agent transactions as MITs. Where a mapping depends on text that does not yet exist, we mark it forward-looking (○) rather than current. Verifiable identity is necessary but not sufficient: it makes every other control (spend caps, mandate scope, injection defence, human approval) enforceable and auditable.

Nothing issued in the dark: the transparency-log audit trail

Every identity mint and every revocation lands in a public, append-only Merkle transparency log (RFC 6962 tlog-tiles), with Ed25519-signed C2SP checkpoints, each root anchored to Bitcoin via OpenTimestamps. That gives an agent-commerce operator something a database row cannot: a non-repudiable answer to "when was this agent's identity issued, and when was it revoked," provably not back-dated, provably in order. For a chargeback dispute, a liability allocation, or an EU AI Act traceability review, that is the difference between an assertion and evidence.

# An agent identity's ordered lifecycle (issuance, any rotations, revocation), keyless
curl -s https://whisper.online/ip/2a04:2a01:c0::a9e7/transparency | jq

# The signed log checkpoint + its Bitcoin anchor: the tamper-evidence root
curl -s https://whisper.online/checkpoint
# -> a C2SP signed note; the root is OpenTimestamps-anchored to Bitcoin

Evidence you can hand a risk or fraud reviewer

The point of every primitive above is that the reviewer does not have to trust Whisper. Each artifact is reproducible from the internet's own records with stock tools: the same --trustless walk any resolver could run. A per-agent evidence bundle for a dispute file, a KYA review, or an EU AI Act traceability request looks like this, and every line is checkable without an account:

# IDENTITY (KYA P1 / agent passport): the identity is genuine and current, verified to the IANA root
whisper verify --trustless 2a04:2a01:c0::a9e7
✓ DNSSEC chain valid to the IANA root   ✓ DANE-EE (TLSA 3 1 1) matches the key
✓ RDAP: registered under AS219419 · 2a04:2a01::/32   identity: VERIFIED (our API never trusted)

# ATTRIBUTION (PSD2 dispute / KYA P4): the per-agent record and who enumerated it
CALL whisper.agents({op:'logs',    args:{agent:'2a04:2a01:c0::a9e7', kind:'conn', from:'-30d'}})
CALL whisper.agents({op:'lookups', args:{agent:'2a04:2a01:c0::a9e7', window:'30d'}})

# CONTAIN + NON-REPUDIATION (EBA Q&A 6141): the offboarding, provable and timestamped
CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:c0::a9e7'}})
curl -s https://whisper.online/ip/2a04:2a01:c0::a9e7/transparency   # the timestamped lifecycle leaf

Because an agent's outputs (a mandate acknowledgement, a receipt, a settlement reference) can be signed under its forge-proof /128, the merchant, the PSP and a regulator can trust the record came from the real agent, which is the non-repudiation a dispute or an audit ultimately wants.

SIEM & threat-intel export

The evidence above is pullable now via op:logs, op:lookups and the graph API, and it exports to Splunk today as signed, replayable JSON mapped to CEF / ECS fields. Broader connectors are on the roadmap, labelled honestly so nobody plans against vapour:

Until the roadmap items land, the same records are already reachable. The exports are a convenience layer over evidence you can pull today.

What this is (and is not)

Whisper anchors one boundary: the transport/IP interface where an agent presents itself to a merchant, a facilitator, or a peer agent. It is deliberate about what it does not touch.

• It is not a PSP, an acquirer, a card network, or a settlement rail. It is the identity-and-attribution layer those systems consume. It complements them; it does not replace them.
• It does not sit inside the payment message, the SCA factor, the MDES token, the AP2 mandate signature, or the x402 onchain settlement. Those keep their own trust models; a Whisper DANE-anchored identity complements them at the network layer without redefining the protocol.
• These protocol mappings are proposed, not vendor-endorsed, and no company is named as a breach victim. The failure classes on this page are drawn from public research and advisories at the class level only.

Everything described as working is checkable, today, with dig, curl and one control-plane call. Everything on the roadmap is labelled as such. That is the whole contract of this page.

Next

• Agent identity: how the device-derived /128 is computed from the key an agent already holds, and why the agent id is the natural domain separator.
• A2A · AP2 · x402: the same identity, wired under each agent-payment protocol at the identifier field it already exposes.
• Pin-a-wallet · A2A-trust · verify: runnable recipes that generate exactly the artifacts this page maps to a framework.