Zero trust,
as a property of the network.

Running a v4-only estate? Verification is transport-independent: the RDAP and /verify-identity checks run over plain HTTPS to us — over IPv4 — and dig asks whatever resolver you already operate. Every check on this page works from a v4-only network today; only the agents themselves live on IPv6.

An agent's traffic leaves from its own /128 — over a routed WireGuard tunnel or the egress proxy, either way the packets source from the identity itself. Whoever is on the other end of a connection can reverse-resolve the source address and get a DNSSEC-signed name, a registry record with the responsible tenant, and a behavioral posture — before deciding to serve the request. Identity is provable per packet, not per session claim.

Compare the prevailing alternative: fleets of agents behind shared NAT pools, where attribution ends at "one of our customers" and the only remedy is to block the pool — innocents included. Here, one agent is one address; the accountable party is one RDAP query away.

For estates that want the credential itself key-bound rather than bearer-based: mTLS egress auth is live (default-off, e2e-proven); DPoP is implemented but dormant (not enabled). The API-key path remains the zero-configuration default.

Provisioning, policy, activity logs, and revocation are one authenticated call — no console spelunking between an incident and its containment:

# policy, logs, kill-switch — same verb, different op
CALL whisper.agents({op:'policy', ...})   — what this agent may resolve and reach
CALL whisper.agents({op:'logs', ...})     — what it actually did, per agent
CALL whisper.agents({op:'revoke', ...})   — the kill-switch, effect publicly provable

Policy is enforced at the network layer the agent cannot route around: its own resolver, which consults a live security graph before answering. Logs attribute to the /128, so the audit trail and the network identity are the same object. And op:revoke is not a soft-delete — it tears down the address, its DNS, its DANE pin, and its egress in one step.

Every issuance is a leaf in an RFC-6962 Merkle log; every revocation lands in a signed status-list beside it. Both are keyless, public endpoints — this is the record your auditors pull, live, without asking us:

The signature on both notes verifies against the Ed25519 key published in signed DNS — so the log's own trust anchor is the DNSSEC root, not a Whisper endpoint. Checkpoints are periodically anchored to Bitcoin via OpenTimestamps for an independent timestamp. The log is tamper-evident and signed today; independent witnesses are being recruited.

1. One agent, one address. Every agent egresses from its own /128, registered in RDAP to the responsible tenant. There is no shared pool: attribution never ends at "one of our customers."
2. Report. The abuse contact is published where operators look for it — in the RIPE database record for 2a04:2a01::/32 and in our security.txt. Reports are acknowledged within one business day.
3. Act. Confirmed abuse is revoked, not rate-limited. One op:revoke tears down the agent's egress immediately and removes its forward DNS, PTR, DANE pin, and active registry status in the same step. Agent records carry 60-second TTLs — you can read that on any dig answer — so the identity decays from global DNS caches within a minute of revocation.
4. Prove it. Revocation is not a promise in a ticket. The event lands in the signed status-list and the transparency record; dig -x returns nothing; /verify-identity returns is_whisper_agent: false. The reporter — or your auditor — verifies the kill with the same stock tools that verified the identity.
5. Blast radius: one. Revoking an agent affects exactly that /128. No shared IP reputation to burn, no innocent tenants behind the same address.

Why this beats a NAT pool. A shared egress pool makes abuse cheap for the abuser and expensive for everyone else: attribution stops at the pool, and the remedy punishes the pool. Per-/128 attribution inverts that — misbehavior is attributable to one identity, revocable in one step, and the revocation itself is publicly checkable.

Transparency logs and the right to erasure usually collide: an immutable log looks like a GDPR problem. Ours was designed around it. Ledger entries are opaque, salted commitments with per-entry key material — a GDPR Art. 17 erasure crypto-shreds that key material, so the personal data becomes permanently unreadable while the Merkle tree stays consistent and every prior inclusion proof still verifies. Your privacy office gets erasure; your audit committee keeps the trail. You do not choose between them.