WhisperDocs
Concepts

How Whisper works, step by step

One customer, one agent, start to finish: sign up, delegate a domain, mint an agent under it, send its traffic out, have a stranger verify it with stock tools, block something, and revoke it. Then the assumptions the whole thing rests on, written down in one place.

The other pages explain Whisper in pieces. This one is the linear story. The customer is called example.com, and every command uses that name so you can paste it with your own. The outputs are real: the keyless steps were captured from production on 2026-11-02, from a live agent under everwatch.io, a domain we delegated ourselves exactly as example.com would. Steps that need the customer's API key show the command and link to the page that carries a live capture of it.

The unit of identity

Everything below is about one thing, so it gets one name.

An agent is the holder of one IPv6 /128. That address is bound to a name under DNSSEC and to a key under DANE. The holder can be an AI process, a container, a host, a router or a phone; Whisper does not care which. One agent, one address, one name, one key.

We do not call the unit a "machine". A host can hold one agent or many, and one agent can move between hosts. The address is what is identified, not the box it runs on.

The walkthrough

1. Sign up

The customer gets an API key from the console (email and a six-digit code, no card). The key is what the control-plane calls below carry; nothing a third party does in step 5 needs one.

2. Delegate the domain

example.com points its NS records at our two servers and publishes our DS at its registrar. There is no TXT challenge: only the holder of a domain can change its delegation at the parent, so a signed delegation seen in the public DNS is the authorization. That check fails closed. See Bring your own domain for the submit call and the full record set.

dig +short NS example.com

Captured for the demo domain:

$ dig +short NS everwatch.io @1.1.1.1
ns1.whisper.online.
ns2.whisper.online.

3. Mint an agent under it

whisper create --register --name demo

The same call over the control plane is CALL whisper.agents({op:'register', args:{label:'demo'}}); Control plane lists what it returns. One call allocates the /128 and publishes its reverse name, its forward name, its TLSA pin and its registry record together, so none exists without the others. The agent's name is derived from its address: a plus the low 64 bits, under the customer's domain.

The live result for the demo agent, read back with stock tools:

$ delv @1.1.1.1 AAAA a4f988041b1326d8a.everwatch.io
; fully validated
a4f988041b1326d8a.everwatch.io. 60 IN AAAA 2a04:2a01:9b6d:23e8:4f98:8041:b132:6d8a

$ curl -s https://rdap.whisper.online/ip/2a04:2a01:9b6d:23e8:4f98:8041:b132:6d8a | jq -c '{handle,name,status,events,registrant:[.entities[]?.handle]}'
{"handle":"a4f988041b1326d8a","name":"demo","status":["active"],"events":[{"eventAction":"registration","eventDate":"2026-10-20T13:39:58.773Z"}],"registrant":["everwatch.io."]}

4. Run the agent through egress

whisper run -- python agent.py

whisper run connects the agent and starts the program with its proxy settings pointing at the agent's own /128, so the sites it reaches see that address as the source. Where the /128 actually lives depends on the tier; the table in the next section says exactly where. Connect & egress has the captured runs for each tier.

5. A third party verifies it, with stock tools

The site the agent reached has a source address and nothing else. It needs no account and no Whisper software to turn that into a name.

Reverse, then forward, each validated in the verifier's own process:

$ delv @1.1.1.1 -x 2a04:2a01:9b6d:23e8:4f98:8041:b132:6d8a
; fully validated
a.8.d.6.2.3.1.b.1.4.0.8.8.9.f.4.8.e.3.2.d.6.b.9.1.0.a.2.4.0.a.2.ip6.arpa. 60 IN PTR a4f988041b1326d8a.everwatch.io.

$ delv @1.1.1.1 AAAA a4f988041b1326d8a.everwatch.io
; fully validated
a4f988041b1326d8a.everwatch.io. 60 IN AAAA 2a04:2a01:9b6d:23e8:4f98:8041:b132:6d8a

The key, checked in a live TLS handshake against the DNSSEC-signed pin, with no certificate authority involved. Shown on a hosted demo agent, because on 2026-11-02 the everwatch.io agent's address answered port 443 with the gateway's certificate instead of its own leaf, a fault we are fixing:

$ openssl s_client -connect [2a04:2a01:eb5a:ca74:cef2:2a:323d:40d4]:443 \
    -servername acef2002a323d40d4.t7af9242c44554e0f8e183ac8e6fbf645.agents.whisper.online \
    -dane_tlsa_domain acef2002a323d40d4.t7af9242c44554e0f8e183ac8e6fbf645.agents.whisper.online \
    -dane_tlsa_rrdata "3 1 1 B653A4EF11618B6604D5E0A4BC1CCF2D68A7E5C269CD2AE890743C52FCB82D1D"
# (trimmed to the verification lines)
subject=CN = acef2002a323d40d4
Verification: OK
DANE TLSA 3 1 1 ...69cd2ae890743c52fcb82d1d matched EE certificate at depth 0
Verify return code: 0 (ok)

And the registry record, which refers up to the RIR that holds the block:

curl -s https://rdap.whisper.online/ip/{agent-128} | jq '{handle, name, status}'

Verify an agent runs all eight proofs, including the one that does not trust our API at all. For site owners is the same check written for the people who run websites.

6. A policy blocks something

CALL whisper.agents({op:'policy', args:{block:['bad-actor.example']}})

From then on the customer's resolver answers NXDOMAIN for that name to every agent in the tenant, and the decision lands in op:logs as blocked. Egress governance and Control plane carry the full policy language.

7. Revoke, and watch it go

whisper kill --revoke demo

Revocation is not a flag you have to take our word for. Once it runs, the reverse name is gone and the keyless verdict turns:

dig -x {agent-128} +short
curl -s https://rdap.whisper.online/verify-identity/{agent-128} | jq .is_whisper_agent

What a /128 with no agent behind it answers, captured on 2026-11-02:

$ dig -x 2a04:2a01:9::50 @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN

$ curl -s https://rdap.whisper.online/verify-identity/2a04:2a01:9::50 | jq .is_whisper_agent
false

The revocation is also published in the transparency log's signed status list, GET https://whisper.online/checkpoint/status-list.

Where the /128 lives in each mode

"The address is the identity" is true in all three tiers, but the address sits in a different place in each. This is the part readers from the DNS world ask about first.

Tier Where the /128 is What a site sees Who holds the key
1, routed On the agent's own host, routed to it over WireGuard. The host's tunnel interface carries the address. Packets from the /128, inbound and outbound The agent: whisper connect generates the WireGuard key on the host
1.5, egress proxy On our egress servers, bound with AnyIP and IP_FREEBIND. We open the connection from that address on the agent's behalf after it authenticates to the proxy. Connections from the /128 Us: the hosted leaf key is derived from the address on our side
2, resolver only Nowhere on the wire. The agent keeps its own address and uses us for resolution and control. The agent's own address, not the /128 n/a

How many identities does one host get? One per agent. whisper run gives the program it starts the identity of the agent it names. An agent behind another agent is a separate identity with its own /128, and the parent to child edge is recorded; see Nested identity. Minting a separate identity for every process on a host is a proposal, not a shipped feature.

How does the endpoint sensor tie a process to a name? It joins the name a process resolved to the connection it opened next, so a flow is attributed to the process and the agent together.

The assumptions

Every security property on our pages rests on these. They are the ones a careful reviewer should check.

  1. Postel. Conservative in what we send, liberal in what we accept.
  2. Resolution fails open. If the graph is slow or down, the resolver answers from real DNS rather than refusing. A policy outage never becomes a DNS outage.
  3. Domain proof fails closed. No agent is minted under a customer's domain until its signed delegation is seen live.
  4. The identity is IPv6. Agents hold /128s out of 2a04:2a01::/32. Verification itself works from an IPv4-only network, because DNS, RDAP and HTTPS do.
  5. DNSSEC is validated by the verifier. Do the validation in your own process (delv, or a validating stub you control) and do not rely on the AD bit from a public resolver over UDP (RFC 4035 section 4.9.3).
  6. Revocation is bounded by TTL for honest caches, and by the signature window for replay. Agent PTR, AAAA and TLSA records carry a 60 second TTL. Their RRSIGs run for about two days (captured: inception 20261102040000, expiration 20261104050000), so a replayed pre-revocation answer stays cryptographically valid until it expires. A verifier that needs a tighter bound checks the status list or asks the servers directly.
  7. Key custody depends on the tier. On the hosted tier the agent's TLS key is derived on our side from the address, so the operator can reproduce it. On the routed tier the WireGuard key is generated and held on the agent's host.
  8. Witness independence is one cosigner today. The log's signed checkpoint carries our signature and one external witness, markovianprotocol.com/witness. More witnesses are being enrolled.
  9. Routing integrity. 2a04:2a01::/32 is RPKI-valid for AS219419, and AS219419 has a single upstream today (RIPEstat lists one neighbour, AS20473). A route hijack is detectable by RPKI-validating networks, not prevented everywhere.
  10. A source address is trusted only where our own kernel filled it in. On paths we terminate, the address is identity. On any public path a claimed source address, or a forwarded-for header, is just a claim.
  11. DANE proves key control, not who someone is. A matching TLSA proves the peer holds the key pinned at that name. It says nothing about the person or company behind it; RDAP and the registrant record are where that lives.
  12. Two anchors. Everything is checkable against the IANA DNSSEC root, and the transparency log is anchored in Bitcoin through OpenTimestamps.

Glossary

Term Meaning here
agent The holder of one /128, bound to a name under DNSSEC and a key under DANE
identity That address with its name, key pin and registry record, all published together
keyless Usable with no API key and no account: every verification call on this page
trustless Checkable without trusting our API: the client re-derives the chain from the IANA root itself (whisper verify --trustless)
tier How an agent's traffic reaches the internet: 1 routed, 1.5 egress proxy, 2 resolver only

Where Whisper sits in the path, next to a CDN

A CDN sits in front of a website, on the server's side. Whisper sits on the agent's side.

Next: For site owners · Identity · Connect & egress · Verify an agent