One line gives an agent a home.
Here is everything underneath it.

Allocating a single agent identity is not one operation. It is several, and the address is not handed out until they are all live and self-consistent:

• A routable /128 carved from 2a04:2a01::/32, announced over BGP from AS219419 — real, RIPE-allocated address space, not a private range.
• A forward record in the authoritative zone, DNSSEC-signed.
• A synthesized PTR in the reverse ip6.arpa tree, so the address spells its own name back — forward-confirmed reverse DNS (FCrDNS).
• A DANE/TLSA pin (3 1 1) for the agent's key, written into signed DNS, and a per-agent certificate minted to match it.
• A per-/128 RDAP object (RFC 9083) and an inet6num entry, so the registry has a record the moment the address exists.
• A graph node, so the agent's own resolver and policy plane know it.
• A policy binding, tying the address to its tenant.

All of it, from one binary, in one step. A reader who has stood up even one of these by hand knows what it costs to keep all of them live at once — byte-identical across two nameservers, every time an agent is born, while the zone never stops mutating.

You can watch the seams hold. Four different protocols, four different tools, one agent — and they all agree:

We are conservative in what we emit and liberal in what we accept, in Postel's sense, and that discipline is built out of named standards rather than house conventions.

DNS core. The classic wire protocol, with EDNS(0) (RFC 6891) for larger messages and flags; DNS-over-HTTPS (RFC 8484) for the resolver path; UDP with proper TCP fallback on truncation (RFC 7766); QNAME minimisation and 0x20 mixed-case encoding for query privacy and resilience; and correct NXDOMAIN / NODATA semantics with negative caching (RFC 2308). Each is the well-trodden answer to a problem you would otherwise re-solve badly.

DNSSEC. Every zone is signed: RRSIG / DNSKEY / DS (RFC 4033–4035), authenticated denial via NSEC3 with conservative parameters (RFC 5155, RFC 9276), and CDS / CDNSKEY (RFC 7344, RFC 8078) so the delegation can maintain itself. Algorithm 13 (ECDSA-P256-SHA256) throughout — small signatures, fast validation. The trust anchor is the DNS root, not a certificate authority: an independent resolver returns the ad (authenticated-data) flag on 1.1.1.1 and 8.8.8.8 alike.

The address is the identity, and that claim is made entirely out of records anyone can read:

• Reverse DNS / PTR over ip6.arpa, forward-confirmed (FCrDNS) — the address resolves to its name, the name resolves back to the address.
• DANE / TLSA (RFC 6698), usage 3 1 1: the agent's TLS key is pinned in signed DNS and anchored to the public root through the customer's own DS record. No certificate authority can be fooled, because none is asked.
• SSHFP (RFC 4255) for SSH key material, signed in the same chain.
• A per-agent CA: each agent's certificate is minted to match its own DANE pin, selected by SNI, rotated make-before-break — so there is no per-agent issuance delay and nothing long-lived to leak.

One DNS query from agent A verifies agent B's key and name binding, with stock dig and openssl. The proof lives on the wire, not in an API we have to keep up.

Everything above is cryptographically proven — DNSSEC signs it, DANE pins it, the per-agent CA mints it, the transparency log records it. One thing in the chain was not: how the agent authenticates to the egress. The standard, default way is an API key, and the egress token (et_…) it mints — a bearer. A bearer is a shared secret: steal it, replay it, and you are the agent. Simple, and by design we cruise on it — but it is the one link that is not key-bound.

For agents that want it, the egress at egress.whisper.online:443 offers a cryptographic alternative that sender-constrains the credential — it becomes a proof you can only make if you hold the agent's private key, not a string you can copy. Two standards, reusing the identity the agent already has — one live today, one implemented and waiting:

• mTLS with a certificate-bound token (RFC 8705) — live today: default-off, proven end-to-end. The egress optionally requests the agent's client certificate: the very same per-agent leaf the DANE chain already pins. It is accepted only when it (1) chains to our per-agent CA, (2) carries an iPAddress SAN equal to the /128 the packets actually source from, and (3) matches the DANE pin the zone publishes for that address. Three independent checks, the same identity the rest of the wire proves — so the agent is authenticated by possession of its key, no bearer required. When a token is minted under mTLS it is bound to the certificate thumbprint (cnf.x5t#S256), so even that token is useless off its key.
• DPoP (RFC 9449) — implemented, not yet enabled. Where TLS cannot be terminated end-to-end, the agent attaches a tiny proof-JWT signed by its key, binding the request method, the target, a fresh timestamp, a single-use identifier and the token's own hash. The bearer stops being a bare secret: without the matching private key, no valid proof can be made, and a captured proof cannot be replayed. The code is in the tree; the switch stays off until it has been proven end-to-end on the live network — the same bar everything else on this page had to clear. This sentence changes when it does.

This is strictly additive, and we hold the line on Postel: the API-key bearer stays the standard, default, no-configuration path — an agent that sends only its key authenticates exactly as before. A missing or invalid certificate or proof never blocks a valid bearer; it simply is not the stronger path. mTLS is there today for those who ask — without complicating the one line everyone else runs.

• RDAP (RFC 7480–7484, 9082, 9083) and WHOIS (RFC 3912) — our own servers, answering live for 2a04:2a01::/32, every agent address a real registration object that refers up to the RIR.
• inet6num / AGGREGATED-BY-LIR objects in the RIPE database, with a domain: object delegating 1.0.a.2.4.0.a.2.ip6.arpa and a matching DS.
• RPKI / ROA (RFC 6480, 6482) authorising the origin, MANRS-compliant routing, dual-homed BGP, a published geofeed and security.txt, listed on PeeringDB and bgp.tools.
• AnyIP plus IP_FREEBIND so egress can source-bind to an agent's /128 across the whole /32.

We hold the AS and the address space as the LIR ourselves, so the registry chain ends with the operator who runs the service — there is no third party between the RIR record and the box answering the query.

Two nameservers, both active/active, both authoritative, answering identically. They are kept consistent with the one mechanism the internet already has for this: TSIG-authenticated (RFC 8945) zone transfer — AXFR/IXFR driven by NOTIFY. No second replication system, no shared cache on the serve path. If the graph is slow or unreachable, resolution fails open to a real upstream answer — never a fabricated NXDOMAIN.

Identity claims are committed to a tamper-evident log so a record cannot be changed after the fact without detection:

• A Merkle transparency log in the RFC 6962 lineage, served as C2SP tlog-tiles, with C2SP signed-note checkpoints, speaking the open tlog-witness protocol. Tamper-evident and signed today; independent witnesses are being recruited — a witness cosigns our checkpoints, we cosign back, and the log becomes independently — not just tamper-evidently — verifiable.
• Periodic anchoring via OpenTimestamps to Bitcoin, so checkpoints carry an independent timestamp.
• did:web identity documents signed with Ed25519 (RFC 8032).
• Entries are opaque, salted commitments with per-entry key material, so a record can be crypto-shredded — the log stays verifiable while the underlying data can be made unreadable. That is how data-subject rights work here: a tenant's Art. 17 erasure (and a subject-targeted purge of the activity trail) crypto-shreds the per-entry salt and purges the warm-store trail, so the personal data becomes unreadable while the Merkle tree stays consistent and every prior proof still verifies. Privacy and tamper-evidence at the same time.

One honest line on where the log stands today: every checkpoint is Ed25519-signed and Bitcoin-anchored, and no independent witness cosigns yet — we are recruiting them, openly. Run a witness →

And the client is not a black box: the whisper CLI is open source under MIT at github.com/whisper-sec/whisper-cli — read it, build it, and verify every proof on this page for yourself.

The whole stack can run on your own infrastructure: authoritative DNS, graph-first resolver, identity allocator, RDAP, reverse DNS, egress proxy, policy and logging plane — one binary. "On-prem" here is not a deployment checkbox. It means you hold, in your own custody:

• Your own BGP announcement of the address space.
• Your own RIPE database objects — inet6num, domain:, the delegation.
• Your own DNSSEC key custody — a deterministic CSK derived per domain, never transported.
• Your own per-agent certificate authority and root.
• Your own RDAP and WHOIS servers, answering live for your space.
• Your own auth store and the same control verb, pointed at a box you operate.
• Two nameservers, active/active, answering identically, kept in step over signed transfers.

Each line is something an operator can run on its own. The hard part — and the real work — is running all of them together, integrated, correct at the same instant, with no external call on the hot path.

We mapped the field before building. Every brick here has precedent; the comparable approaches each cover one part of the picture.

The combination on this page — address-as-identity on our own AS, registry-verifiable, checkable with dig / curl / whois / openssl, with the same address governing who an agent is, where it may go, and what is safe to touch — is the part that has to be assembled whole. Each row above is a slice; this is the integrated stack.