Install & verify

One command installs the CLI. Two more choices, each a deliberate opt-in, layer on top: an API key mints the host its own identity, and one flag turns on the calm sensor. You audit that identity in the same breath, keyless, against the internet's own root. Remember the sensor is optional: the /128 and the kill-switch cover a host with nothing installed at all.

One command

On a Linux host:

$ curl -fsSL https://get.whisper.online | sh
whisper: installing…
whisper: installed ✓  (run: whisper)
whisper: installed to /usr/local/bin/whisper - run: whisper

As root the binary lands in /usr/local/bin, which is already on PATH on Debian and RHEL, so whisper works in the same shell that installed it. An unprivileged user gets ~/.local/bin; --dir or WHISPER_DIR overrides either.

That is the whole plain path: a signed, sha256- and PGP-verified binary, put on PATH, nothing else. Conservative in what it does: minting an identity and turning on the sensor are each a separate, explicit choice, never a side effect of piping a script off the internet.

Add your API key and the same command mints the host's own routable /128, because now there is a key to mint it with. The install itself never depends on the key being any good, proven here against a deliberately wrong one:

$ curl -H "X-API-Key: whisper_live_...redacted" https://get.whisper.online | sh
whisper: installing…
whisper: installed ✓  (run: whisper)
whisper: couldn't bind a /128 identity (key refused or control plane unreachable) - whisper is installed; bind later with: whisper create --name {host}
whisper: installed to /usr/local/bin/whisper - run: whisper

A real key replaces that third line with whisper: bound <address> (<name>). Add WHISPER_SENSOR=1 to the same command and, once the /128 is in place, it also installs the sensor and starts it under a bounded systemd unit:

$ curl -H "X-API-Key: whisper_live_...redacted" https://get.whisper.online | WHISPER_SENSOR=1 sh
whisper: installed ✓  (run: whisper)
whisper: bound 2a04:2a01:f804:fd8:4b5b:1a4b:4885:9c9c  (a4b5b1a4b48859c9c.td68f56a48850edbd42b1dcd97f680e8d.agents.whisper.online)
whisper: sensor service installed + running (whisper-sensor)

Verify it the way you would verify any unit:

# systemctl status whisper-sensor
whisper-sensor: active (running)

That command is also the repair. A host where an earlier attempt installed the CLI but no sensor needs nothing removed first: whisper enroll is idempotent and re-finds the /128 the host already has rather than minting a second one.

If you would rather read the unit before it runs, install and start are separate steps, and this path needs no key on the request because it authenticates from whatever the CLI already has on disk:

$ whisper service install --sensor
$ whisper service start --sensor
# or do both at once
$ whisper service install --sensor --now

The bounded unit, and what it actually costs

The sensor runs under a systemd unit with a hard, kernel-enforced resource ceiling and an event-driven, no-polling design, so it cannot run away with the machine. The shipped unit sets:

[Service]
CPUQuota=25%
MemoryMax=250M

Those are the guardrails, not the cost. The measured footprint on a live fleet host is 1.01% of one core and 11 MB resident, and the sensor's own self-meter reads its cgroup accounting and ships that measurement with every footprint heartbeat, so calm is a measured property, not a promise. 25% is the ceiling we promise never to need; we measured 1%.

Two schedulers keep it that way. On the host, an autonomous governor admits deferrable work (deep scans, the injection sweep, posture, shipping) only when the host is measured calm, on nice-19, idle-IO workers, bursting up to tenfold only when host, network and user are all quiet, with a deadline floor so a busy box cannot starve a scan, and a circuit breaker that sheds the sensor's own work first. Off the host, an advisory fleet planner shapes per-/128 vigilance from graph history; it can only dampen or defer, never touch the hot path, and the host stays fully calm if the backend is gone. The sensor fails open: if it is slow or absent, the host keeps resolving and running, because the brain lives on our backend and network, not on the host. The full system, personas and levers included, is in Calm footprint & SLA.

The one command ships a signed, checksum-verified binary straight from our own /dl, not a distro package: no apt, no dnf, no apk, nothing added to your package manager's sources. That is deliberate, and it is what keeps the binary current (/dl is built from the exact tree we run in production, so it cannot lag behind what the box you are talking to is doing). To remove it: curl -fsSL https://get.whisper.online/uninstall | sh, or whisper service uninstall --sensor followed by deleting the binary yourself.

Verify it yourself, keyless

The identity the installer mints is a real object in the public record. Anyone can check it with stock tools, against the IANA root, with our API nowhere in the trust decision. The example below is a live identity, the agent scout, so you can run every line yourself:

# reverse DNS names the address - the identity, in public
$ dig -x 2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478 +short
ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online.

# the name is DNSSEC-validated to the IANA root - our API is not in the trust path.
# point delv at a validating resolver; a local stub that strips DNSSEC data
# will report a broken chain that is its own, not the zone's.
$ delv @1.1.1.1 -x 2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478
; fully validated

# the DANE-EE key pin (usage 3, selector 1, matching 1) - no public CA needed
$ dig +short TLSA _443._tcp.ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online
3 1 1 9EC1EF18A1F15E5480A0FC3C8D6E9690B2CCF1A7FA7146201940F28C422BB47D

# the public registry object - holder + allocation under AS219419
$ curl -s https://rdap.whisper.online/ip/2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478 | jq
{
  "objectClassName": "ip network",
  "name": "scout",
  "type": "Whisper agent identity",
  "status": ["active"],
  "country": "NL",
  "entities": [{ "roles": ["registrant"] }],
  "events": [{ "eventAction": "registration", "eventDate": "2026-06-26T23:31:14.390Z" }]
}

The /128 comes out of 2a04:2a01::/32, announced by AS219419, with DNSSEC-anchored reverse DNS, a DANE-EE key pin (TLSA 3 1 1), and a public RDAP registration. It is not a token you rent; it is an identity you hold and anyone can check. For the one-call bundle that returns is_whisper_agent, dane_ok and jws_ok together, see the Quickstart, and the deeper /128 identity page for the connectivity tiers and nested sub-agent identity.

Opt-in flags

The install is deliberately boring: the sensor itself is off by default, and once you turn it on, its detection engines are on by default under it, with only whatever could sit in your path staying off. The opt-ins:

• WHISPER_SENSOR: off by default. The bare one-liner mints identity and nothing more; observing a host is never a side effect of minting a /128. Set WHISPER_SENSOR=1 (or yes/true/on) to also install, enable and start the sensor service. A machine that wants only the /128 and the kill-switch, with no on-host telemetry, needs no flag at all: that is the default.
• eBPF build (-tags ebpf): the default is the pure-Go NETLINK collector. The eBPF build adds a per-connect net-tap; it links a GPL object and ships only in that opt-in build, never in the public MIT tree.
• YARA-X build (-tags yara): the shipped packages carry the YARA-X scanner; a plain from-source build without the tag compiles a clean stub with zero YARA linked. Sigma is always in, pure Go.
• Bring your own rules: drop Sigma .yml files under .whisper/sigma/ and YARA .yar files under .whisper/yara/ and they load beside the embedded set, overriding by rule id, capped at 512 Sigma rules. Every finding carries the rule's own author, license and ATT&CK technique metadata; a rule that names no technique emits unmapped, never an invented id.
• Local enforce (opt-in, observe-first): by default the sensor observes and never sits in the critical path. A host can opt into a local-policy exec guard that closes observe, then verdict, then block. Opting into telemetry is not opting into blocking; enforcement is a separate, deliberate choice, and the on-host respond tier (quarantine, a reversible process-tree freeze) is armed only behind its own dedicated scope. Both are covered in Containment.

What you get, and what is on the roadmap