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

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.

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.

^¹ 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
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 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.

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

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"}'

{"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:

# 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; folding the proof by hand is the one on Transparency log.

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). 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.

Next: Transparency log for the full ledger mechanics, or Egress governance to constrain what an already-audited agent is allowed to reach.