# Zero trust for AI agents, as a property of the network. Whisper. > One address per agent that is its identity. An audit-grade transparency log, > a signed revocation status-list, a provable kill-switch, attribution per > connection. Your auditors verify all of it themselves, with standard tools. ## Zero trust, as a property of the network Not another middleware layer. Every agent gets one address that *is* its identity: named in reverse DNS, documented in a public registry, key-pinned in signed DNS, its issuance recorded in a tamper-evident transparency ledger, its revocation published as a signed status-list. Your auditors verify all of it themselves, with standard tools — no Whisper account, no vendor attestation taken on faith. One command, keyless — the verdict names its own trust anchor: ```sh $ whisper verify --trustless 2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478 CHECK RESULT TRUST DETAIL dnssec pass DNSSEC-root AAAA, PTR and TLSA(3 1 1) all DNSSEC-validated to the IANA root; address <-> fqdn consistent dane pass DNSSEC-root served leaf SPKI-SHA256 == TLSA pin; DNS-SAN=ae3b051ff3bf7f478...agents.whisper.online, IP-SAN=2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478; issuer "Whisper Agent Identity Issuing CA" transparency pass DNSSEC-root root signature verified; 1 event(s), root_hash bound; 1 ledger leaf/leaves included (RFC-6962) identity_doc pass DNSSEC-root JWS verified against the DNSSEC-anchored key; address/fqdn/tlsa claims match the DNSSEC-validated facts whisper: ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online is CRYPTOGRAPHICALLY PROVEN — trust anchor: DNSSEC root (IANA anchor) + DANE-EE + DNSSEC-anchored transparency/ledger keys -- Whisper API NOT trusted ``` A live agent, verified from the IANA DNSSEC root with the Whisper API explicitly untrusted. That last line is the design goal of the whole platform: we built ourselves out of our own trust path. ``` THE PROOF CHAIN — every hop DNSSEC-signed [ IANA DNSSEC root ] the trust anchor | | dig +dnssec [ .online ] | | dig +dnssec +-------------+ [ whisper.online ] x···| Whisper API | | +-------------+ | dig +dnssec not in the trust path [ agents.whisper.online ] | | dig -x · dig TLSA · curl /checkpoint [ AAAA · PTR · TLSA · ledger · JWS ] the agent's records | | openssl · key == TLSA pin [ the agent's /128 ] 2a04:2a01:… routable, yours ``` Every hop is signed; every hop is checked with a stock tool. Whisper's API is not in the trust path — `whisper verify --trustless` walks this chain from the root down. ## Eight controls, all independently verifiable The same stack, in the vocabulary your review board uses. Every row ends in a check your own team can run — none of them requires trusting us. | Control | What it is | Verify it yourself | |---|---|---| | Zero-trust network identity | Each agent is one routable IPv6 `/128` from `2a04:2a01::/32` on our own AS219419. The address is the identity: named in DNSSEC-signed reverse DNS, key-pinned via DANE, documented in RDAP. | `dig -x` · `whisper verify --trustless` | | Audit-grade transparency log | Every identity issuance lands in an RFC-6962 Merkle log — Ed25519-signed checkpoints, Bitcoin-anchored via OpenTimestamps, its keys anchored in DNSSEC-signed DNS. | `curl whisper.online/checkpoint` | | Signed revocation status-list | Revocation is published, not promised: a signed status-list served next to the log, updated when an identity is killed. | `curl whisper.online/checkpoint/status-list` | | Per-agent policy, logs, kill-switch | One control verb governs every agent: policy at the resolver, per-agent activity logs, and `op:revoke` as the kill-switch. | revoke, then `dig -x` returns nothing | | Attribution per connection | Agent traffic sources from the agent's own `/128`, so every packet carries the identity. No shared pool, no anonymous NAT. | reverse-resolve any source address | | GDPR Art. 17 crypto-shred | Ledger entries are salted commitments; erasure destroys the per-entry key material. Personal data becomes unreadable, the audit trail stays consistent. | prior inclusion proofs still verify | | Dutch data residency | Operated from Amsterdam by viaGraph B.V., the RIPE LIR holding the address space. The public registry states it per address. | RDAP returns `"country": "NL"` | | On-prem custody | The entire stack — DNS, DNSSEC keys, per-agent CA, registry, resolver, egress, control plane — runs as one binary on your infrastructure and address space. | [/under-the-hood#onprem](/under-the-hood) | **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. ## Every connection attributes to one agent 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. ## One verb governs every agent 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. ## Issuance and revocation are publicly provable 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: ```sh $ curl -s https://whisper.online/checkpoint # the signed log checkpoint whisper.online/ledger 64 B66DTSD3Eq5OYm29c8oVMuDuVjbTgsokKEk4sdyRiKU= — whisper.online/ledger ijpd8I14cmGnMp9HajPjCRadLGL8Bs+E8weqY/EiPQd3lvnxC7hT6eMyGVJFImQfCIPc1O6jyDid9cEjABz1II+7aw4= $ curl -s https://whisper.online/checkpoint/status-list # the signed revocation status-list whisper.online/status revocation 30 1782945174860 H4sIAAAAAAAA_-3BQQ0AAAgAIftndjtj-AGqHQAAAAAAAAAAAAAAAAAAAODVAcJWgp0AQAAA — whisper.online/ledger ijpd8IbxFNVh6t+d7vIuLrXn0XQcnUs2Rif/bUZX1LGxUQ8u0WNR5CkuU4vZSa7jygAt0nGE/NWsB4V0fKIPAwZmFQg= $ curl -s https://rdap.whisper.online/ip/2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478/transparency # one agent's issuance events + RFC-6962 inclusion proof $ dig +short TXT _whisper-ledger.whisper.online # the log's Ed25519 key, anchored in DNSSEC-signed DNS "v=whisper1; k=ed25519; n=whisper.online/ledger; p=MCowBQYDK2VwAyEApyTBKL3bSJO7kBbdw4FqJsjREW23jNP07HybKByIabg=" ``` 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. ## Abuse policy and revocation SLA The question behind every agent platform is blast radius: when an agent misbehaves, who is it, and how fast can it be stopped — provably? Anonymous NAT pools cannot answer either question. One address per agent answers both. 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. ## Erasure without destroying the audit trail 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. ## Dutch residency. On-prem custody, if required - **Data residency: the Netherlands.** The service is operated from Amsterdam by viaGraph B.V., the RIPE LIR that holds `2a04:2a01::/32` and AS219419 — EU jurisdiction end to end, with no third-party intermediary between the RIR record and the infrastructure answering your query. This is not a brochure claim: the public registry states it per address. `curl` any agent's RDAP record and read `"country": "NL"` for yourself. - **On-prem: custody, not a checkbox.** The entire stack — authoritative DNS, DNSSEC key custody, the per-agent certificate authority, registry, resolver, egress, and the control plane — runs as one binary on your own infrastructure and your own address space. Your BGP announcement, your keys, your registry objects, your log. See [/under-the-hood](/under-the-hood). ## Governance you can hand to mathematics Attribution per connection. An audit trail your auditors verify themselves. A kill-switch whose effect is publicly provable. All of it on address space and infrastructure we own end to end — and none of it requiring your counterparties to trust us, or you to trust ours. --- - **Bring your agents under governance:** - **Read the engineering:** [/under-the-hood](/under-the-hood) - **The registry & policy:** © viaGraph B.V. (dba Whisper Security)