Compliance & audit
When an auditor asks "which agent touched this data, from where, and can you prove it wasn't back-dated?", a fleet behind ephemeral keys and rotating NAT'd IPs has no good answer.
And neither does an issuer who controls the very log they're asking you to trust.
The pain: identity that can't survive an audit
Most agent fleets are audited on artifacts that weren't built to be audited:
- A short-lived bearer token proves a request had some valid credential — not which agent, on which machine, in which jurisdiction, made it.
- A NAT'd or rotating egress IP is shared across dozens of workloads, so "the agent that hit this endpoint at 14:02 UTC" is a guess reconstructed from logs you also control. The auditor has to trust you, not the evidence.
- Data-residency claims ("this agent's data stays in the EU") are usually a paragraph in a DPA, not something a regulator can check from outside.
- Issuance is opaque. If you can silently mint, backdate, or revoke an identity in a private database, no external party can tell an honest incident report from a cover-up.
None of this is a logging problem you fix with more log lines — it's an identity problem. You can't produce an audit trail for an actor with no stable, provable identity in the first place.
The fix: identity you don't have to be trusted to prove
Whisper gives every agent a real, routable IPv6 /128 from 2a04:2a01::/32 (announced by AS219419) as its identity — not a key, not a NAT'd shared address. That address is the join key across every compliance artifact: DNS (forward + reverse), RDAP/WHOIS, a DANE TLS pin, and a public transparency log, all keyed on the same /128, all independently checkable by a stranger with stock tools. Four pieces do the actual work:
- A stable, registry-anchored identity. One agent, one
/128, for its lifetime — resolvable both ways (dig -xanddig AAAA), so "which agent" is a DNS lookup, not a lookup in your own database. - Signed, per-agent activity logs, queryable per agent via the control plane, so "what did it do" doesn't require trusting your own SIEM.
- A Bitcoin-anchored transparency log (RFC 6962) of every issuance and revocation event — append-only, so "was this identity really created/revoked when we say it was" doesn't require trusting Whisper either.
- Historical RDAP + jurisdiction-aware addressing (RFC 9092 geofeed), so "where does this agent's traffic originate" is a public record, not a policy document.
Coverage map: which frameworks you can tick
How to read this page. We grade every control into one of three verdicts and never blur them. DIRECT-ADDITIVE: Whisper produces evidence that maps to the control (one input to your package, never the whole standard). COMPLEMENTARY: the framework mandates the sector's own PKI, certificate or process; Whisper sits alongside it and can DANE-pin it, but does not satisfy that requirement. DO-NOT-CLAIM: controls Whisper is honestly the wrong tool for; we list them so nobody over-claims. Each row also carries a fit symbol: ● strong · ◐ partial · ○ stretch · ✗ not-addressed. Whisper is a control and evidence layer; it never makes you compliant or certified — your auditor does that.
Shipped & live. The key-derived, RDAP-registered /128 identity, DANE-EE 3 1 1 pin, DNSSEC-signed forward + reverse zones, per-/128 signed logs (op:logs), reverse-lookup observability (op:lookups), one-call op:revoke, the RFC 6962 Merkle transparency log with SCITT (RFC 9942/9943) receipts, and the attribution graph are all in production and checkable today with dig, curl, or one control-plane call over POST https://graph.whisper.security/api/query with your X-API-Key. The Splunk, Microsoft Sentinel and OpenCTI SIEM connectors ship.
Honest status. The transparency log is tamper-evident, Ed25519-signed, Bitcoin-anchored via OpenTimestamps, and independently witnessed by MarkovianProtocol (any party can co-sign the same open checkpoint format; the live X-Whisper-Ledger-Claim header is the source of truth). Point-in-time RDAP (?history / ?time=) is Whisper's own extension: it is an observation of what we saw, never the registry's ground truth. SCITT COSE receipts ship; the SCRAPI HTTP API (draft-ietf-scitt-scrapi) is still an IETF draft. SIEM: Splunk, Microsoft Sentinel and OpenCTI shipped; STIX/TAXII is on the roadmap. Sector items marked roadmap (STIX/TAXII export, typed CLI flags, C2PA Conformance submission) and pending regulations (HIPAA Security Rule NPRM, NCCS control lists ~2027, PSD3/PSR RTS) are labelled as such; nothing on this page is described as working unless you can reproduce it.
Which frameworks you can tick
Read the Verdict and Fit columns first: they are the load-bearing part. Each row is one control; grouped by framework. Whisper is one input to your package, never the whole standard.
| Framework · control | What it asks for | Verdict | Fit | Whisper evidence (shipped) |
|---|---|---|---|---|
| SOC 2 CC6.1 · logical access | Restrict logical access to authorized identities | DIRECT-ADDITIVE | ◐ | DANE-pinned per-agent /128 + FCrDNS/verify name-based inbound authz: one control inside your access program |
| SOC 2 CC6.2 · registration & deprovision | Register/authorize before issuing credentials; remove on offboarding | DIRECT-ADDITIVE | ● | register provisions, revoke deprovisions a machine/agent identity; both land in the signed transparency log |
| SOC 2 CC6.6 · external boundary | Protect against threats from outside the boundary | DIRECT-ADDITIVE | ● | Default-deny egress governance bound to the /128; graph-first resolver denies known-C2 per query |
| SOC 2 CC6.7 · transmission | Restrict & protect information in transmission | DIRECT-ADDITIVE | ◐ | Encrypted DNS (DoH/DoT) + source-bound /128 egress transit; complements your TLS |
| SOC 2 CC7.2 · monitoring | Monitor components for anomalies | DIRECT-ADDITIVE | ◐ | Per-/128 signed logs (dns/conn/alloc) + JA3/JA4; Splunk export shipped, SIEM correlation stays yours |
| SOC 2 CC7.3/7.4 · incident response | Evaluate, respond to & contain security events | DIRECT-ADDITIVE | ◐ | One-call revoke = provable DNS-TTL containment (the network-containment half; you own evaluation & response), checkable with dig -x / verify-identity |
| ISO/IEC 27001:2022 A.5.16 · identity mgmt | Manage the full identity lifecycle | DIRECT-ADDITIVE | ● | /128 as a lifecycle-managed asset: register → keyless verify → revoke; RDAP-registered, transparency-logged |
| ISO/IEC 27001:2022 A.5.17 · authentication information | Manage allocation/use of authentication secrets | COMPLEMENTARY | ◐ | Key-derived identity removes a shared bearer secret; you still run your own credential store |
| ISO/IEC 27001:2022 A.8.5 · secure authentication | Secure authentication technologies | DIRECT-ADDITIVE | ● | DANE/DNSSEC-verifiable, cert-pinnable machine authentication |
| ISO/IEC 27001:2022 A.8.15/8.16 · logging & monitoring | Log events; monitor anomalous behaviour | DIRECT-ADDITIVE | ◐ | Per-/128 attributable logs; the attribution graph turns a destination into a verdict |
| ISO/IEC 27001:2022 A.8.20/8.21 · network security | Secure networks & network services | DIRECT-ADDITIVE | ◐ | DNSSEC-signed resolution + DANE-pinned channel + per-tenant resolver; complements your firewall/SASE |
| ISO/IEC 27001:2022 A.8.24 · use of cryptography | Policy on & effective use of cryptography | DIRECT-ADDITIVE | ◐ | DNSSEC (ECDSA-P256/CSK) signing, DANE, key-derived identity, encrypted transit: concrete crypto inputs to your policy, not the policy itself |
| NIST CSF 2.0 PR.AA · identity, auth & access | Identities/credentials managed; access authorized | DIRECT-ADDITIVE | ● | Per-/128 identity + DANE auth + default-deny egress |
| NIST CSF 2.0 PR.DS-02 · data-in-transit | Protect confidentiality/integrity in transit | DIRECT-ADDITIVE | ◐ | Encrypted DNS + DNSSEC integrity + /128-bound transport |
| NIST CSF 2.0 DE.CM · continuous monitoring | Monitor assets to find adverse events | DIRECT-ADDITIVE | ◐ | Per-/128 logs + attribution; reverse-DNS → identity on every line |
| NIST CSF 2.0 ID.AM · asset management | Inventory assets with address + owner | DIRECT-ADDITIVE | ◐ | /128 registry keyed to network address + owner per agent/device |
| NIST CSF 2.0 GV.SC · supply-chain risk | Manage third-party / system-to-system access risk | DIRECT-ADDITIVE | ◐ | Per-vendor/agent identity + revoke + transparency-log grant/removal record |
| NIST SP 800-53 IA-3 · device I&A | Uniquely identify/authenticate devices | DIRECT-ADDITIVE | ● | /128 device identity derived from the device's own key |
| NIST SP 800-53 IA-9 · service I&A | Identify/authenticate services before comms | DIRECT-ADDITIVE | ● | DANE/DNSSEC-verifiable per-service /128 identity |
| NIST SP 800-53 AC-4 · information-flow enforcement | Control information flows (egress) | DIRECT-ADDITIVE | ● | Source-bound /128 egress, default-deny allowlist |
| NIST SP 800-53 AU-9 · protection of audit info | Protect logs from unauthorized alteration | DIRECT-ADDITIVE | ● | Append-only Merkle ledger; OpenTimestamps/Bitcoin anchor; independent witness cosign¹ |
| NIST SP 800-53 AU-10 · non-repudiation | Prove an actor performed an action | DIRECT-ADDITIVE | ● | SCITT (RFC 9942/9943) receipts + transparency-log inclusion; issuance/revocation non-repudiable² |
| NIST SP 800-53 SC-8 · transmission conf./integrity | Protect data in transit | DIRECT-ADDITIVE | ◐ | Encrypted DNS (DoH/DoT) + /128-bound egress |
| NIST SP 800-53 SC-20/21/22 · secure name resolution | Authoritative + resolver DNSSEC origin-auth | DIRECT-ADDITIVE | ● | Whisper IS a DNSSEC-signing authoritative (SC-20) + validating resolver (SC-21): the strongest 800-53 fit |
| NIST SP 800-53 SC-23 · session authenticity | Protect session authenticity | COMPLEMENTARY | ◐ | DANE-pinned TLS hardens session trust; your app owns the session |
| PCI DSS 4.0 Req 1 · network security controls | Restrict connections to/from the CDE | DIRECT-ADDITIVE | ◐ | /128 default-deny egress = one network security control at the IP layer, not your whole NSC ruleset |
| PCI DSS 4.0 Req 8 · identify & authenticate | Unique ID + strong auth for components | DIRECT-ADDITIVE | ◐ | Per-/128 cryptographic identity for non-human system components (not the human-user IDs / MFA the requirement also mandates) |
| PCI DSS 4.0 Req 4 · strong crypto for PAN in transit | Encrypt PAN over open/public networks | COMPLEMENTARY | ○ | Encrypts the DNS/egress path, not the PAN payload itself |
| PCI DSS 4.0 Req 10 (+10.5) · log & protect | Log all access; protect audit trails | DIRECT-ADDITIVE | ◐ | Per-/128 logs (10.2/10.3); tamper-evident ledger protects integrity (10.5) |
| HIPAA §164.312(a)(2)(i)/(d) · unique ID + entity auth | Unique identifier; verify the entity | DIRECT-ADDITIVE | ◐ | Per-/128 unique identifier + DANE/DNSSEC-verifiable machine-entity auth (not human MFA) |
| HIPAA §164.312(b) · audit controls | Record & examine system activity | DIRECT-ADDITIVE | ◐ | Per-/128 activity logs record the DNS/egress boundary: one input to your audit controls, not the ePHI-system audit trail |
| HIPAA §164.312(e) · transmission security | Guard & encrypt ePHI in transit | DIRECT-ADDITIVE | ◐ | Encrypted DNS + /128-bound transit on the identity/resolution path; your ePHI store stays yours |
| HIPAA §164.312(c)(1) · integrity | Corroborate ePHI not altered | COMPLEMENTARY | ◐ | DNSSEC/DANE integrity on resolution; the ledger corroborates its own records |
| GDPR Art. 32(1)(a) · encryption of processing | Pseudonymisation + encryption | DIRECT-ADDITIVE | ◐ | Encrypted DNS/transit; per-record crypto-shred keys (scope: Whisper's records, not your store) |
| GDPR Art. 5(1)(f) · integrity & confidentiality | Process securely against unauthorised access | DIRECT-ADDITIVE | ◐ | Identity + egress governance + logs as the demonstrable measure |
| GDPR Art. 25 · data protection by design | Build DP in from the start | COMPLEMENTARY | ◐ | Identity-derived-from-key + default-deny egress = a by-design building block |
| GDPR Art. 17 · right to erasure | Erase personal data on request | DIRECT-ADDITIVE | ● | Ledger leaves are salted opaque commitments: crypto-shred the salt → meaning unrecoverable, prior proofs stay valid |
| GDPR Art. 30 / Art. 44+ · records & residency | Records of processing; know & constrain where data goes | DIRECT-ADDITIVE | ◐ | Bitcoin-anchored, independently-witnessed issuance ledger + point-in-time RDAP¹ ³; RFC 9092 geofeed publishes jurisdiction, egress policy can geo-scope |
| DORA Art. 9 · protection & prevention | Authenticity/integrity/confidentiality in transit; network mgmt | DIRECT-ADDITIVE | ◐ | Identity + DNSSEC integrity + encrypted transport + egress control |
| DORA RTS (2024/1774) Art. 6 · encryption & crypto | Policy + use of cryptography | DIRECT-ADDITIVE | ◐ | DNSSEC/DANE/transit crypto as concrete inputs to the crypto policy |
| NIS2 Art. 21(2)(d) · supply-chain security | Manage supplier / service-provider risk | DIRECT-ADDITIVE | ◐ | Per-vendor identity + revoke + transparency-log grant/removal |
| NIS2 Art. 21(2)(i) · access control & asset mgmt | Access-control policies; asset management | DIRECT-ADDITIVE | ◐ | Per-/128 machine access + /128 asset registry |
| NIS2 Art. 21(2)(j) · continuous auth / secured comms | Continuous auth; secured communications | DIRECT-ADDITIVE | ◐ | Continuously-checkable DANE credential + instant revoke + encrypted DNS: the continuous-auth/secured-comms half, not MFA |
| EU CRA Annex I (2)(d) · protection from unauthorised access | Auth / identity / access-mgmt mechanisms | DIRECT-ADDITIVE | ● | Embedded /128 identity for the product-with-digital-elements |
| EU CRA Annex I (2)(f) · integrity protection | Protect data/command integrity | DIRECT-ADDITIVE | ● | DNSSEC/DANE integrity on resolution + identity |
| EU CRA Annex I (2)(l) · record & monitor | Log security-relevant activity | DIRECT-ADDITIVE | ◐ | Per-/128 security-relevant activity logs |
| EU CRA Annex I Part II · SBOM | A machine-readable software bill of materials | DO-NOT-CLAIM | ✗ | Not provided: Whisper is not an SBOM tool |
| EU AI Act Art. 12 · record-keeping | Automatically log events over the lifecycle | DIRECT-ADDITIVE | ◐ | Per-agent egress/resolution logs + tamper-evident ledger = traceability records |
| EU AI Act Art. 15 · robustness & cybersecurity | Resist manipulation / confidentiality attacks | COMPLEMENTARY | ◐ | Verifiable agent identity + DANE + egress governance = one concrete cybersecurity measure, not a conformity route |
| ISO/IEC 42001 A.6 / NIST AI RMF MANAGE · AI lifecycle & traceability | Manage AI system lifecycle; traceability & records | DIRECT-ADDITIVE | ◐ | Identity issuance/rotation/revoke + transparency log + per-agent logs supply technical evidence; you run the management system |
| CIS Controls v8 1 · asset inventory | Inventory by network address + owner | DIRECT-ADDITIVE | ◐ | /128 registry: network address + owner per agent/device |
| CIS Controls v8 6 · access control mgmt | Grant/revoke by least privilege | DIRECT-ADDITIVE | ● | Per-/128 identity + register/revoke lifecycle |
| CIS Controls v8 8 · audit log mgmt | Collect, protect, retain audit logs | DIRECT-ADDITIVE | ◐ | Per-/128 logs, tamper-evident, retained |
| CIS Controls v8 13 · network monitoring & defense | Monitor + defend the network | DIRECT-ADDITIVE | ◐ | Egress logs + attribution + default-deny defense |
| OWASP LLM06:2025 · excessive agency | Bound the actions/reach an agent can take | DIRECT-ADDITIVE | ● | Default-deny /128 egress allowlist + one-call revoke (kill switch) bound the agent's network reach |
| OWASP Agentic · agent identity & non-repudiation | Unique agent identity; accountable, containable actions | DIRECT-ADDITIVE | ● | Per-agent cryptographic /128 + tamper-evident action log + instant revoke |
| OWASP LLM02/LLM03 · info disclosure / supply chain | Narrow exfil paths; verify dependency endpoints | COMPLEMENTARY | ◐ | Encrypted DNS + egress governance narrow exfil; DANE-pin dependency endpoints — you own dependency vetting |
| MITRE ATLAS · exfiltration / impact tactics | Detect-limit exfil; contain adversary impact | COMPLEMENTARY | ◐ | /128 egress logs + default-deny detect/limit exfil; revoke = containment; attribution maps the actor (ATLAS is a threat model, not a control catalog) |
| MFA / human authentication | Multi-factor authentication for human access | DO-NOT-CLAIM | ✗ | Whisper does device/entity identity, not a human login factor |
| Encryption at rest | Protect stored data at rest | DO-NOT-CLAIM | ✗ | Out of scope: Whisper anchors the network/IP boundary, not storage |
| Certification / "makes you compliant" | Any audit, attestation or conformity decision | DO-NOT-CLAIM | ✗ | Whisper is a control + evidence layer within your program; an auditor certifies, we never do |
By industry
Whisper anchors one boundary — the cloud/IP interface between a sector device or endpoint and its backend. It complements each sector's own PKI and processes; it never satisfies a certification. Each vertical has its own deep page.
| Vertical · standard | What it asks for | Verdict | Fit | Whisper evidence (shipped) |
|---|---|---|---|---|
| Automotive · UN R155 CSMS (monitor-detect-respond) | Detect, monitor & respond to vehicle cyber-threats across the fleet lifecycle | DIRECT-ADDITIVE | ◐ | Device-derived /128 from IDevID/TPM + VIN(+ECU serial); per-/128 logs → attribution graph → one-call revoke supply a monitor-detect-respond loop at the cloud/IP boundary — one control inside the CSMS, not the whole management system |
| Automotive · UN R156 SUMS (software updates) | Secure the software-update process to the vehicle | COMPLEMENTARY | ◐ | DANE-pins the update endpoint (transport identity only); it does not sign the update package |
| Automotive · ISO/SAE 21434 (TARA lifecycle) | Cybersecurity engineering across the vehicle lifecycle | DIRECT-ADDITIVE | ◐ | One TARA control in the operations/IR phase; not the whole engineering process |
| Automotive · Auto-ISAC ATM (threat matrix) | Map & share adversary tactics (Initial Access/C2/Exfil/Containment) | COMPLEMENTARY | ◐ | Per-/128 logs + attribution map to ATM tactics; analyst-driven, STIX/TAXII export on roadmap |
| Automotive · SecOC / V2X-SCMS / ISO 15118 | In-vehicle & V2X message security | DO-NOT-CLAIM | ✗ | Whisper never sits inside these handshakes; it anchors the cloud/IP boundary only |
| Energy · NERC CIP-005-7 R3 (vendor remote access) | Determine & disable active vendor remote-access sessions | DIRECT-ADDITIVE | ● | /128 identity + op:list/op:lookups (determine) + revoke (disable) for vendor remote access |
| Energy · NERC CIP-013-2 R1.2 (supply chain) | Vendor-risk controls incl. coordinated remote-access & disclosure | DIRECT-ADDITIVE | ◐ | Transparency log = non-repudiable vendor grant/removal record; per-vendor identity: one control within the R1.2 supply-chain plan |
| Energy · EU NIS2 Art.21 / NCCS 2024/1366 Art.33 | Risk-management measures for the electricity sector | DIRECT-ADDITIVE | ◐ | Identity + per-/128 logs + revoke cover part of the risk-management measures; NCCS technical control lists finalise ~2027 |
| Energy · IEEE 2030.5 CSIP (LFDI) · SunSpec/Kyrio PKI · IEC 62351-9 | DER cryptographic identity via the sector PKI | COMPLEMENTARY | ◐ | /128 keyed to LFDI; DANE-pins the CSIP/SunSpec cert — it never issues the CSIP certificate |
| Energy · NERC CIP-010 / CIP-005 R2 IRA-MFA / CIP-007 R5 | Config change mgmt · interactive-remote-access MFA · account mgmt | DO-NOT-CLAIM | ✗ | Out of scope (BES-scope caveat); Whisper does not do config-mgmt or human MFA |
| Telecom / 5G core · 3GPP TS 33.501 (SBA; rogue-NRF / DNS-spoof) | Secure NF discovery & the service-based architecture | DIRECT-ADDITIVE | ● | DNSSEC + DANE close the DNS-spoof / rogue-NRF gap; drops into NFProfile.ipv6Addresses, no NRF change |
| Telecom / 5G core · GSMA FS.36 (N32/SEPP) | Secure the inter-PLMN N32 interface | COMPLEMENTARY | ◐ | DANE-pinned N32/SEPP peer identity alongside the SEPP's own TLS/PRINS; it does not replace them |
| Telecom / 5G core · NIS2 Art.21/23 · NSA/CISA ESF · ZTMM | Risk mgmt, incident timelines, zero-trust for 5G cloud | DIRECT-ADDITIVE | ◐ | Per-NF logs/lookups on the NIS2 clock; default-deny micro-segmentation vs lateral movement |
| Telecom / 5G core · 3GPP TS 33.310 NF cert (mTLS + OAuth2/NRF) | Per-NF certificate + mutual-TLS + token auth | COMPLEMENTARY | ◐ | /128 from the NF's existing SBI mTLS key; a second independent DNS layer, never replaces mTLS |
| Telecom / 5G core · GSMA NESAS/SCAS · FCC Covered List | Network-equipment security assurance / certification | DO-NOT-CLAIM | ✗ | Not a certification; a boundary control, not the deep intra-SBI mesh |
| OT / ICS · EU CRA Annex I (2)(d)/(i)/(j) | Identity, access control & data-flow control for products | DIRECT-ADDITIVE | ● | Embedded /128 from OPC UA cert / 802.1AR IDevID / TPM; default-deny egress = MUD-style conduit at asset granularity |
| OT / ICS · IEC 62443-3-3 SR 5.1 · NIST 800-82r3 · CSF ID.AM/PR.AA · CISA CPG 2.0 · RFC 8520 MUD | Zone/conduit segmentation & asset inventory | DIRECT-ADDITIVE | ● | Asset-granularity conduit + an asset register straight from DNS/RDAP |
| OT / ICS · IEC 62443-4-2 CR 1.2 (software-process I&A) | Identification & authentication of software processes | COMPLEMENTARY | ● identity / ◐ auth | Provides the identity (●); the authentication handshake stays the asset's own (◐) |
| OT / ICS · CRA Annex I Part II SBOM · 62443-4-2 CR 1.1 human I&A · 62443-4-1 SDLA | SBOM · human user I&A · secure-development lifecycle | DO-NOT-CLAIM | ✗ / ○ | No SBOM (✗), no human I&A (✗); SDLA is a development process, not a product control (○) |
| Health · FDA §524B(b)(1)/(2) + cyber-device UDI | Postmarket monitoring, secure design, UDI-keyed traceability | DIRECT-ADDITIVE | ◐ | Device-derived /128 keyed to the UDI; per-device revoke; one control inside the SPDF, not the whole secure-development framework |
| Health · HIPAA Security Rule NPRM + §164.312(b)/(d) | Asset inventory, network map, segmentation, audit, entity auth | DIRECT-ADDITIVE | ◐ | /128 inventory anchor + live network map (attribution) + entity auth (not human MFA); audit is the DNS/egress boundary, not the ePHI-system trail; NPRM still proposed |
| Health · FHIR UDAP/SMART · TEFCA/QHIN · IEC 62443-4-2 · IEC 81001-5-1 · EU MDR 17.4 | Community-CA endpoint trust & secure device lifecycle | COMPLEMENTARY | ◐ | DANE-anchors the community cert keyed to Endpoint.identifier; never the community CA/clearance |
| Health · FDA §524B(b)(3) SBOM · MFA · encryption-at-rest · clearance route | SBOM · human MFA · at-rest crypto · market clearance | DO-NOT-CLAIM | ✗ | No SBOM/MFA/at-rest; never a §524B/MDR clearance shortcut |
| Content / provenance · EU AI Act Art.50(2)/(4) + Recital 133 | Mark & disclose AI-generated content via cryptographic provenance | DIRECT-ADDITIVE | ◐ | /128 from the C2PA claim-signer key + cert serial; DANE-anchors the signer (an enumerated cryptographic-provenance technique — it anchors the signer, not the content mark itself) + op:lookups verification analytics |
| Content / provenance · C2PA claim signer (COSE_Sign1/x5chain) | A trusted cryptographic signer for the manifest | COMPLEMENTARY | ◐ | A pluggable, DANE-anchored C2PA trust source, keyed to the signer cert serial |
| Content / provenance · C2PA Trust List / Conformance · CAWG Identity 1.2 · ISO 22144 | Trust-list membership & identity assertions | COMPLEMENTARY | ○ | A pluggable source, not gate-kept membership; op:lookups = "who verified my content" |
| Content / provenance · deepfake detection · survives manifest-strip · "this is AI" | Detect synthetic media / survive re-encode | DO-NOT-CLAIM | ✗ | Provenance ≠ truth; Whisper never asserts "this is AI" (that's the manifest's) and does not survive a manifest-stripping re-encode |
| Commerce / agentic payments · PSD2 SCA delegation + dispute attribution | Strong customer auth anchoring & dispute evidence | DIRECT-ADDITIVE | ◐ | /128 anchor for SCA delegation (an anchor, not SCA itself) + a dispute-attribution subject |
| Commerce / agentic payments · KYA · NIST NCCoE agent identity · OWASP ASI03 | Know-Your-Agent identity, universal revocation | DIRECT-ADDITIVE | ● | Universal (not per-network) revocation + a public DNSSEC/DANE key directory for agents |
| Commerce / agentic payments · A2A · AP2→FIDO · x402 · MCP · Visa TAP · Mastercard Agent Pay | Anchor agent identifiers across the payment rails | COMPLEMENTARY | ◐ | DANE-pins the identifier (A2A url, AP2 verificationMethod, x402 wallet, Visa keyid, Mastercard cert); no protocol change, never settles |
| Commerce / agentic payments · PSD2/SCA conformity · PSP/settlement · PCI-DSS · VASP-grade KYC | Payment-institution conformity & KYC | DO-NOT-CLAIM | ✗ | Not a PSP, not settlement, not PCI-DSS conformity; identity ≠ intent, and this is not VASP-grade KYC |
¹ The transparency log is independently witnessed (MarkovianProtocol) and OpenTimestamps/Bitcoin-anchored today; the witness set is open and self-reverting, and the live X-Whisper-Ledger-Claim header is the source of truth.
² SCITT COSE receipts (RFC 9942/9943) are shipped and fold to the same checkpoint root; the SCRAPI HTTP API (draft-ietf-scitt-scrapi) is still an IETF draft.
³ Point-in-time RDAP is Whisper's own extension: an observation of what we saw at time T, not a claim about the registry's own ground truth.
Deeper per-industry detail: Automotive · Energy · Telecom / 5G core · OT / ICS · Health · Content / provenance · Commerce / agentic payments.
1. Stable identity: the join key for everything else
The demo resident, 2a04:2a01:eb5a:ca74:cef2:2a:323d:40d4, resolves forward and backward, and its friendly name is its FQDN in agents.whisper.online:
With stock tools:
dig -x 2a04:2a01:eb5a:ca74:cef2:2a:323d:40d4 +short
# acef2002a323d40d4.demo.agents.whisper.online.
dig +short AAAA acef2002a323d40d4.demo.agents.whisper.online
# 2a04:2a01:eb5a:ca74:cef2:2a:323d:40d4
dig +short TLSA _443._tcp.acef2002a323d40d4.demo.agents.whisper.online
# 3 1 1 b653a4ef...fcb82d1d
Every answer above carries AD=1 under DNSSEC validation (RFC 4035) against any recursive resolver, including 1.1.1.1 or 8.8.8.8 — the identity binding isn't asserted by an API response, it's signed by the zone itself.
With Whisper:
whisper verify --trustless 2a04:2a01:eb5a:ca74:cef2:2a:323d:40d4
# re-derives PTR + AAAA + TLSA + RDAP itself, chains to the IANA root — Whisper's API isn't trusted, only DNSSEC is
See Verify an agent and DANE & DNSSEC for the full chain.
2. Signed, per-agent logs
Attribution only matters if you can pull the trail for one agent, not grep a shared access log for an IP that six other workloads also touched.
With stock tools: there is no stock-tool path here — that's the point. A shared IP or a bearer token has no per-actor log by construction; you'd be reconstructing attribution from application-level correlation, which is exactly the unprovable state this page exists to fix.
With Whisper:
CALL whisper.agents({op:'logs', args:{agent:'my-agent', from:'2026-06-01'}})
-> per-event records: timestamp, kind (dns/conn/alloc), destination, decision, bytes
whisper logs --agent my-agent --from 2026-06-01 --kind conn
Because the identity is a dedicated /128, every record is unambiguously one agent's — no shared-IP noise to filter out.
3. The transparency log: RFC 6962, anchored to Bitcoin
Every identity issuance and revocation is appended as a leaf to a Merkle tree, served as signed checkpoints (C2SP tlog-tiles) with the leaf/interior construction straight from RFC 6962:
leaf = sha256(0x00 || sha256(salt || event))
interior = sha256(0x01 || left || right)
Because entries are salted, opaque commitments, a record can be crypto-shredded for GDPR Article 17 without invalidating the tree or any previously issued inclusion proof — the hash stays, the personal data behind the salt doesn't.
With stock tools:
curl -s https://whisper.online/checkpoint # origin, tree_size, root_hash, Ed25519 signature
curl -s https://whisper.online/checkpoint/ots # the checkpoint's OpenTimestamps Bitcoin proof
curl -s https://rdap.whisper.online/ip/2a04:2a01:eb5a:ca74:cef2:2a:323d:40d4/transparency
# this agent's issuance/revocation events + RFC-6962 inclusion proof
dig +short TXT _whisper-ledger.whisper.online # the log's Ed25519 key, DNSSEC-anchored
Honest status: tamper-evident and Ed25519-signed today, Bitcoin-anchored via OpenTimestamps, and independently witnessed by MarkovianProtocol (additional witnesses welcome, any party can co-sign the same open checkpoint format). Full policy at nic.whisper.online/policy#transparency and Transparency log.
op:revoke is provable the same way: after it runs, dig -x <addr> returns nothing, /verify-identity flips to is_whisper_agent: false, and the event lands in the signed checkpoint — the same tools that proved the identity prove the kill.
4. Historical RDAP and jurisdiction-aware addresses
RDAP (RFC 9083) gives you the registry record for any address or name today; the /transparency sibling above gives you its history. For data residency, 2a04:2a01::/32 publishes a standard geofeed (RFC 9092) mapping prefixes to jurisdiction, so "this agent's address is EU-registered" is a fetchable fact, not a claim in a DPA:
curl -s https://rdap.whisper.online/ip/2a04:2a01:eb5a:ca74:cef2:2a:323d:40d4
curl -s https://whisper.online/.well-known/geofeed | grep 2a04:2a01
# 2a04:2a01::/32,NL,NL-NH,Amsterdam
whois -h whois.whisper.online 2a04:2a01:eb5a:ca74:cef2:2a:323d:40d4
With Whisper: whisper create --register returns the same registry facts (address, fqdn, ptr) at mint time, and whisper.agents({op:'policy', ...}) can constrain an agent's egress to a geography-scoped set of destinations, so residency is enforced, not just documented. See RDAP & WHOIS and Control plane.
For: crypto-compliance platforms, fintech, regulated AI deployments, and anyone with EU data-residency or SOC2/audit obligations for autonomous workloads. A production crypto-compliance platform runs its agent fleet on this today.
Next: Transparency log for the full ledger mechanics, or Egress governance to constrain what an already-audited agent is allowed to reach.