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

## 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
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; independent witnesses (any party can co-sign the same open checkpoint format) are being recruited but not yet in place — see the 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).

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