The /128 identity

Every host and every agent gets a real, routable IPv6 address that is its identity. A stranger can verify it with stock tools, and our API is never in the trust decision.

Most EDRs hand an endpoint an opaque vendor GUID that only their console can interpret. Whisper hands it a public internet identity instead: a routable IPv6 /128 out of 2a04:2a01::/32, announced by AS219419 (viaGraph B.V., a RIPE resource holder). The address is not a token you rent from us. It is an identity you hold, named in the public DNS, registered in public RDAP, and checkable by anyone. That single fact is the anchor for everything else: reverse-DNS attribution, per-/128 egress and policy, the off-host kill-switch, the graph verdict, and agent governance all hang off it. In the seven-layer architecture this is layer one, and every other layer keys off it.

Two tiers, one primitive

The identity is not a feature of the sensor. It is the other way around: the identity is the product, and the sensor is an optional layer you add where you want per-process depth. Everything on the keyless side works with no agent installed and no API key, for anything that can hold an address, a server, a laptop, a printer, an ephemeral AI agent.

Verify it yourself, keyless

The whole point is that you do not take our word for it. Here is the live identity of a real agent, scout, checked with nothing but dig, delv and curl, against the IANA root. No account, no API key.

The address names itself. Reverse DNS resolves the /128 to its identity:

$ dig +noall +answer -x 2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478 @1.1.1.1
8.7.4.f...ip6.arpa. 60 IN PTR ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online.

The name is signed: delv re-derives the chain to the IANA root, and the record carries an RRSIG under algorithm 13 (ECDSA P-256), validated to the root:

$ dig +dnssec -x 2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478 @9.9.9.9
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2      # ad is the resolver's claim; delv re-derives the chain
8.7.4.f...ip6.arpa. 60 IN PTR   ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online.
8.7.4.f...ip6.arpa. 60 IN RRSIG PTR 13 34 60 20260826210000 20260824200000 58485 1.0.a.2.4.0.a.2.ip6.arpa. kXm7KL2mBVn...

The loop closes. The forward AAAA of that name returns the same /128, so the reverse-DNS binding is forward-confirmed, the standard internet trust primitive an operator can authorize on:

$ dig +noall +answer AAAA ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online @1.1.1.1
...agents.whisper.online. 0 IN AAAA 2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478

The TLS leaf is pinned. A DANE-EE record (usage 3, selector 1, matching 1) pins the agent's certificate key in DNSSEC, so its mTLS identity is verifiable with no public CA in the path:

$ dig +noall +answer TLSA _443._tcp.ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online @1.1.1.1
_443._tcp...agents.whisper.online. 0 IN TLSA 3 1 1 9EC1EF18A1F15E5480A0FC3C8D6E9690B2CCF1A7FA7146201940F28C422BB47D

One keyless call, the whole bundle

If you would rather have every proof in a single response, the keyless verify endpoint returns the whole evidence object at once: is this a Whisper agent, does the DANE pin match the served leaf, is the signed identity document valid, and the supporting records to re-check each claim by hand.

$ curl -s 'https://rdap.whisper.online/verify-identity?ip=2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478'
{
  "is_whisper_agent": true,
  "fqdn": "ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online",
  "tenant": "tdc38e7c55bad3306a92b830f9bb1e4f9",
  "dane_ok": true,
  "jws_ok": true,
  "evidence": {
    "posture": "tier1.5",
    "dane": { "usage": 3, "selector": 1, "matching": 1,
              "profile": "DANE-EE 3 1 1 (DNSSEC-anchored TLSA; no public CA needed)",
              "strong_pin": true, "served_leaf_matches": true },
    "rdap": "https://rdap.whisper.online/ip/2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478",
    "identity_doc": "https://ae3b0...agents.whisper.online/.well-known/whisper-identity"
  }
}

And the identity is a first-class object in a public registry. The RDAP record is an RFC 9083 IP-network object: who holds the address, when it was registered, and a chain up to the RIPE aggregate:

$ curl -s https://rdap.whisper.online/ip/2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478
{ "objectClassName": "ip network", "handle": "ae3b051ff3bf7f478",
  "startAddress": "2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478",
  "name": "scout", "type": "Whisper agent identity", "status": ["active"], "country": "NL",
  "entities": [{ "handle": "tdc38e7c55bad3306a92b830f9bb1e4f9", "roles": ["registrant"] }],
  "events": [{ "eventAction": "registration", "eventDate": "2026-06-26T23:31:14.390Z" }],
  "links": [{ "rel": "rdap-up", "title": "RIR (RIPE) aggregate 2a04:2a01::/32",
              "href": "https://rdap.db.ripe.net/ip/..." }] }

The same chain, in the console

Operators see that chain rendered on the host page: the /128, its verification state, a copy-the-evidence button that hands you the exact dig to re-run, and the live feed of who has been resolving that identity.

It persists across upgrade and restart

An identity is only useful if it is stable. A host's /128 is durable: it survives a sensor upgrade and a reboot, so reverse-DNS attribution, RDAP, policy and the kill-switch all keep pointing at the same identity across the machine's life. You do not re-earn trust every time the agent restarts.

Three ways to carry it on the wire

How the /128 shows up in your traffic is your choice. All three source from the same routable, reverse-DNS-attributable identity.

You do not have to choose by hand. One command, whisper connect, negotiates the best tier the platform and network can give: it tries Tier 1 first, a routed /128 over userspace WireGuard, under a short bound, and on any failure downgrades automatically to Tier 1.5, which needs nothing but outbound :443. The one-line success message names the tier it landed on; an explicit --tier forces that tier, with no downgrade. And a connection installed as a service carries the observe sensor by default (opt out with --no-sensor; enforcement stays a separate opt-in), so the zero-config path is also the best-protected one.

See connectivity tiers for the setup of each.

Nested identity for AI agents and sub-agents

The agent era needs more than one identity per machine. When an agent spawns a sub-agent, the child gets its own /128 nested under its parent, so an agent tree is governed node by node: each node has its own reputation, its own egress, its own logs and its own revoke. The tree forms two ways, and only one of them carries authority. A parent can be declared at spawn, which is display metadata. The load-bearing edge is measured: the egress plane observes the child's connections physically arriving from the parent's /128 and records that transit, to a depth of 32.

The tree does real work:

• Policy composes down the measured chain, most-restrictive-wins. A child's effective egress is its own rule-set intersected with every live ancestor's; a deny at any layer wins, and a parent can never widen what a child is allowed to do. Past the depth bound the check fails closed.
• One kill cuts the branch. A kill-switched or revoked ancestor cuts every descendant transiting behind it on its next connection, with zero collateral to sibling branches. The mechanics live in Containment.
• The fleet reports the tree. The fleet views carry each identity's parent, children, and depth, with per-owner rollups that deduct same-tenant children into their root so "how many agents does this owner run" has one answer. Very wide fan-outs are counted rather than silently truncated.
• Public disclosure is per-identity opt-out. Nesting edges are published in RDAP and WHOIS by default so an outsider can see that an identity is a sub-agent; a per-identity policy flag suppresses those public edges when a tree's shape is itself sensitive. Attestations are generation-bound, so a restarted child is a new fact, not an inherited one.

Why the identity is the anchor

Because the identity is a real, verifiable network object rather than a console record, it does load-bearing work a vendor GUID cannot:

• Attribution - reverse DNS answers "which agent made this connection" straight from the wire. And because Whisper also serves the identity's DNS, the sensor can tie a lookup to the exact process that made it, so the trail reads process, name, answer, peer, on one identity. See Telemetry collectors.
• The graph verdict - the name a process resolves is the same canonical key the 7.52B-node, 38.6B-relationship security graph scores, so the destination's owner, ASN, prevalence and threat band ride back onto the identity's own activity. The graph enriches and never gates: the local answer returns even when the graph is unreachable.
• Policy - the per-identity egress firewall, trust-graded egress, byte budgets, run scopes, geography and per-device rules are all keyed by the /128 and enforced off-host. See policy on the same handle.
• Egress - traffic is metered and policed per /128, so accountability rides the same primitive as identity.
• Containment - revoking the identity ends its resolution and egress worldwide, even when the host is owned, and a nested tree is cut at its parent. See the off-host kill-switch.
• Governance - agents are governed as first-class principals with an owner, an expiry and an attestable state.
• Jurisdiction, opt-in - the address itself can encode its jurisdiction by being allocated inside a country-tagged block, published in RDAP and a geofeed, so a regulator can read an agent's jurisdiction off its /128. Disabled by default; nothing changes until you turn it on.