Solutions

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 -x and dig 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.

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

← Egress governance Agent-to-agent trust →