# 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:

1. **A stable, registry-anchored identity.** One agent, one `/128`, for its lifetime — resolvable both ways (`dig -x` and `dig AAAA`), so "which agent" is a DNS lookup, not a lookup in your own database.
2. **Signed, per-agent activity logs**, queryable per agent via the control plane, so "what did it do" doesn't require trusting your own SIEM.
3. **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.
4. **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, typed compliance attestations (`POST /attest`) with keyless per-leaf inclusion proofs (`GET /inclusion?leaf=N`), 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

| 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

| 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](https://auto.whisper.online/docs/automotive-compliance) · [Energy](https://energy.whisper.online/docs/energy-compliance) · [Telecom / 5G core](https://telecom.whisper.online/docs/telecom-compliance) · [OT / ICS](https://ot.whisper.online/docs/ot-compliance) · [Health](https://health.whisper.online/docs/health-compliance) · [Content / provenance](https://content.whisper.online/docs/content-compliance) · [Commerce / agentic payments](https://commerce.whisper.online/docs/commerce-compliance).

## 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:**
```bash
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:**
```bash
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](/docs/verify) and [DANE & DNSSEC](/docs/dane) 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
```
```bash
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:**
```bash
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
curl -s "https://whisper.online/inclusion?leaf=<N>"   # any leaf's inclusion proof, by index: leaf_hash + path + checkpoint
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](https://nic.whisper.online/policy#transparency) and [Transparency log](/docs/transparency).

`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:

```bash
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](/docs/rdap) and [Control plane](/docs/control-plane).

## 5. Attest a control in force: typed compliance attestations

Everything above proves facts Whisper wrote into the log. `POST /attest` is the arm where **you** write: a typed statement that a named control was checked and what the verdict was, committed as a leaf in the same RFC 6962 tree and handed back as a fetchable SCITT ([RFC 9942](https://www.rfc-editor.org/rfc/rfc9942)) receipt. Attest "SOC 2 CC6.1 was checked and passed, here is the evidence hash" today; hand the auditor a proof next year that verifies with stock tools, no Whisper account, and no trust in you or in us.

Two tiers, Postel style, same as the rest of the ledger: writing takes an API key (the anti-spam gate on the shared tree), reading and verifying is keyless, always.

**With your API key** (a real, live-captured run; key redacted):

```bash
curl -X POST "https://whisper.online/attest" \
     -H "X-API-Key: whisper_live_xxx" \
     -H "content-type: application/json" \
     --data '{"control_id":"CC6.1","verdict":"pass","evidence_hash":"<sha256-hex>","framework":"soc2"}'
```

```json
{"object":"compliance-attestation",
 "id":"d0e09c8ee5e03d06afa3c2869e6bafff5a0ad57e494663474c8dd5278ee205a2",
 "leaf_index":429,
 "receipt":"/entries/d0e09c8ee5e03d06afa3c2869e6bafff5a0ad57e494663474c8dd5278ee205a2",
 "checkpoint":"whisper.online/ledger\n430\njpp4vn/0aqGamWCLeKm2v9qYphx2nslhBYZx7WN3So4=\n\n— whisper.online/ledger <ed25519-sig>\n",
 "canonical":{"owner":"t<sha256-tenant-handle>","control_id":"CC6.1","verdict":"pass",
              "framework":"soc2","evidence_hash":"<sha256-hex>","at":1784223138224}}
```

The input side is liberal, per Postel: `verdict` takes `pass`/`fail`, common synonyms, or booleans; `evidence_hash` accepts bare hex, `sha256:` or `0x` prefixes; `at` is optional and takes epoch millis, epoch seconds, or an ISO timestamp; the field names have synonyms too. No key is a `401`, bad input is a clear `400` that says what is wrong, never an opaque 500.

**Keyless, for the auditor** (or anyone): the receipt and the proof, straight from the response above:

```bash
# the RFC 9942 SCITT receipt for this attestation (200, application/cose)
curl -s "https://whisper.online/entries/d0e09c8ee5e03d06afa3c2869e6bafff5a0ad57e494663474c8dd5278ee205a2"

# its RFC 6962 inclusion proof, by the returned leaf_index
curl -s "https://whisper.online/inclusion?leaf=429"
# {"object":"ledger-inclusion","leaf":429,"tree_size":436,
#  "leaf_hash":"78102abbc7740dc2800663fde4ee76fb9d53d5cafc4984bb435617d639e03e70",
#  "proof":["433705224dd111195a53ce5564499083608c83ca3e2a9fa7ec9682827b58098e", …],
#  "checkpoint":"whisper.online/ledger\n436\n…"}
```

That `leaf_hash` is byte-identical to the `X-Whisper-Scitt-Leaf-Hash` header on the receipt, and both fold to the same checkpoint root: one attestation, two envelopes, exactly like every other leaf. Validating the COSE receipt with stock tooling is the walkthrough on [SCITT receipts](/docs/scitt-receipts); folding the proof by hand is the one on [Transparency log](/docs/transparency).

**What lands in the tree, and what an attestation proves.** The leaf is the same opaque, salted commitment as every other entry: no cleartext `control_id`, no evidence, nothing an outsider can read (see [what's actually in a leaf](/docs/transparency)). The echoed `canonical` object is your disclosure copy, and `canonical.owner` is the opaque one-way tenant handle RDAP already publishes, never your account id or email. And the honest ceiling: a logged attestation proves this exact statement was made at this point in the log's history and has not been altered since. It does not prove the control actually passed; the evidence behind `evidence_hash` stays yours to produce, and your auditor stays the judge. The log's job is to make the record impossible to quietly rewrite.

> 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](/docs/transparency) for the full ledger mechanics, or [Egress governance](/docs/egress-governance) to constrain what an already-audited agent is allowed to reach.