Whisper · Docs
Agriculture · Recipes

Agriculture recipes

Three copy-paste recipes put a forge-proof, owner-revocable network identity under a drone ground station, a prescription pipeline, and a genuine part. Each one runs today against the keyless verify surface anyone can reach.

They share one primitive: a routable IPv6 /128 that a device derives from a key it already holds, DNSSEC-signed and DANE-pinned so anyone can verify it and nobody can forge it. Everything below is built from shipped parts: the device /128, keyless verify, and one-call revoke. Where a step is a pattern you assemble rather than a single command, or a connector still on the roadmap, it says so in plain words.

▹

What's shipped, stated honestly. The machine/ECU /128 derivation, the keyless verify / RDAP surface, and one-call revoke are live. Two caveats these recipes are written around: there is no --pin CLI flag yet, so machine provisioning is shown via the control-plane API with the PIN riding in the vin argument (which is live); and the SIEM/threat-intel export roadmap items called out at the end are proposed, not shipped. Whisper anchors the cloud/IP boundary. It is not on the ISOBUS/J1939 bus, not in TIM functional safety, and not in a drone's Remote-ID broadcast. Each recipe names exactly where it stops.

The shared primitive: an identity a device derives, not one you hand it

A machine, an implement ECU, or a smart component already carries a hardware key from the factory: a secure-element or TPM key. Whisper takes only its public SubjectPublicKeyInfo (SPKI) and, together with the 17-character equipment PIN (and optionally an implement or part serial), deterministically derives a /128 under 2a04:2a01::/32 (AS219419). The private key never leaves the device.

The derivation has four properties that make it useful as an identity rather than just an address:

Provision one with your API key. The machine submits its device public key and PIN, and gets back its deterministic /128 plus a WireGuard config:

# Provision a machine's identity from the device key it already holds + its PIN.
# Re-running with the same key+PIN returns the SAME /128 (idempotent).
curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" \
  -H "content-type: application/json" \
  -d '{"query":"CALL whisper.agents({op:'"'"'connect'"'"', args:{tier:'"'"'wireguard'"'"', identity_public_key:'"'"'<base64 SPKI of the device key>'"'"', vin:'"'"'1AGCM82633A004352'"'"'}}) YIELD op, ok, status, result, error RETURN op, ok, status, result, error"}' | jq .

# For a specific implement or part, add ecu_serial as the domain separator for a distinct /128:
#   args:{tier:'wireguard', identity_public_key:'…', vin:'1AGCM82633A004352', ecu_serial:'RC-7F31'}
i

A supplied PIN is checked against a reused identity: the same device key with a different PIN on your tenant is a 409, and a non-string identifier is a clear 400. Liberal in what it accepts, strict and unambiguous in what it commits. The server only ever derives a public address; it never sees or reconstructs the device's private key.

Once provisioned, every check in the three recipes below is keyless: no account, no API key, just DNS and TLS that any counterparty already has.

Recipe 1: Drone ground-station & fleet-backend verification

An agricultural drone broadcasts its identity on the air under FAA Remote ID (Part 89); the internet side of the operation, the ground control station, the fleet backend, the spray-log upload, the USS/UTM endpoints, has no such identity. Give each one a /128 and either side confirms the other with a stock DNS lookup, no shared CA list.

▹

Boundary. Whisper is not in the Part-89 broadcast and issues no Remote-ID credentials. This complements Remote ID: it authenticates the IP-facing peers (ground station↔fleet backend, the mission upload, the USS endpoint a fleet dials) that the broadcast was never designed to cover. It does not touch the air interface.

The two directions are the same one-line check, run by each side. A ground station confirms the fleet backend before trusting a mission from it:

# The client side: prove the fleet backend is who it claims, trustless and
# re-derived against the IANA DNSSEC root, no Whisper API trusted as an authority.
whisper verify --trustless fleet-backend.demo.agents.whisper.online

dnssec   pass   DNSSEC-root   AAAA, PTR and TLSA(3 1 1) all DNSSEC-validated to the IANA root
dane     pass   DNSSEC-root   served leaf SPKI-SHA256 == TLSA pin
ledger   pass   DNSSEC-root   entry present, signature verifies
CRYPTOGRAPHICALLY PROVEN. Trust anchor: DNSSEC root (IANA) + DANE-EE. Whisper API NOT trusted

The backend, in turn, verifies the ground station a spray log claims to come from. It's one keyless HTTPS call, no software to install:

# The server side: is this address a real, DANE-anchored ground-station identity?
curl -s https://whisper.online/verify-identity/2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8
{"is_whisper_agent":true,"dane_ok":true,"jws_ok":true,
 "evidence":{"address":"2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8",
   "ptr":"…","forward_aaaa":"2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8"}}

Because the reverse is forward-confirmed (PTR ⇄ AAAA), the same fact is checkable with nothing but dig, the tool already in every ops toolbox:

dig +short -x 2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8
a6f1007b9e2d30c8.demo.agents.whisper.online.

That is mutual, forge-proof peer verification at the layer Remote ID leaves open: neither side depends on a token that could be replayed from another host, and the spray log the traceability chain will later cite arrives from an identity anyone can re-check.

Recipe 2: Bidirectional prescription & task-file verification

A prescription map is two trust questions, not one: is this really the FMIS endpoint the machine should fetch its task file from, and is this really the machine that's allowed to receive, and later report against, that prescription. Whisper answers both at the transport layer, keyless, before a single rate map moves, and both answers are forge-proof.

▹

Boundary. The task file's content and format stay with your FMIS and the ISOBUS task-controller workflow (ISO 11783 task data): Whisper does not parse, sign or alter prescriptions. It authenticates the two endpoints, so "who am I talking to" becomes as strong as the agronomy behind the map. It complements the FMIS's own auth; it is not a substitute for it.

Direction A: the machine verifies the FMIS endpoint. Before it downloads, the telematics gateway trustlessly confirms the task-file host's DANE-pinned identity, so a spoofed or MITM'd server answering on that name fails immediately. It cannot present the platform's pinned key:

# On the gateway, before fetching the task file: is this the genuine FMIS endpoint?
whisper verify --trustless taskfiles.demo.agents.whisper.online
dane   pass   DNSSEC-root   served leaf SPKI-SHA256 == TLSA pin

# Same check with stock tools, comparing the live SPKI hash to the DNSSEC-signed TLSA pin:
dig +short TLSA _443._tcp.taskfiles.demo.agents.whisper.online
3 1 1 b653a4ef…fcb82d1d
openssl s_client -connect taskfiles.demo.agents.whisper.online:443 </dev/null 2>/dev/null \
  | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der \
  | openssl dgst -sha256        # must equal the TLSA pin above

Direction B: the FMIS verifies the machine. Before it releases a prescription, or accepts the as-applied record that comes back, the platform confirms the requesting machine's derived /128 is real and DANE-anchored. A spoofed gateway can neither source packets from the genuine /128 nor DANE-prove it:

# On the FMIS side, before serving or accepting: is this the machine we allocated?
curl -s https://whisper.online/verify-identity/2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8
{"is_whisper_agent":true,"dane_ok":true,"jws_ok":true, …}

Two keyless checks, one in each direction, and the prescription only moves when both pass. A harvested platform token buys an attacker nothing: the identity is a network fact, not a bearer string, and the as-applied record that feeds the farmer's own books arrives from a machine that proved itself.

Recipe 3: The anti-counterfeit part

A genuine component holds a secure-element key from the factory; a counterfeit doesn't hold the one that was registered. Bind the genuine key to a Whisper /128 at manufacture and that difference collapses into a one-line network check anyone in the supply chain, a dealer, a service centre, a co-op workshop, can run, plus a single revoke that blacklists a burned key worldwide.

▹

Boundary. This complements the secure element already in the part. It does not replace the chip. It makes the chip's identity network-verifiable and instantly revocable, with no bus and no air interface involved.

At manufacture, the part's secure-element public SPKI plus its part serial (the ecu_serial slot) derive its /128, DANE-pinned and RDAP-registered, using the same shared primitive above. From then on, the genuine part proves its identity and the counterfeit simply can't:

# Genuine part: a registered, DANE-anchored identity. It proves itself:
curl -s https://whisper.online/verify-identity/2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8
{"is_whisper_agent":true,"dane_ok":true,"jws_ok":true, …}

# Counterfeit: no registered /128 for its key, no DANE pin it can present.
# The public surface says so plainly, no account required:
curl -s https://whisper.online/verify-identity/2a04:2a01::1
{"is_whisper_agent":false,
 "detail":"no Whisper agent identity anchors this address"}

A distributor, a dealer workshop, or a downstream integrator confirms genuineness with that one call (or an RDAP lookup for the assignment record), and never has to phone home to the OEM or hold a shared secret:

curl -s https://whisper.online/ip/2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8
# RDAP: the DNSSEC-anchored assignment record for the genuine part's /128

One revoke, blacklisted worldwide, thrown by the owner

When a part is flagged counterfeit, a key is burned, or a machine is traded in, stolen, or decommissioned, a single control-plane call tears down its /128, its PTR, and its DANE pin everywhere at once, bounded only by DNS TTL. No CRL to distribute, no per-vendor blocklist to push, no fleet-wide firmware flash. And unlike the covert kill-switches agriculture has already seen exercised, this one leaves a public trail: anyone can check, with dig, that the identity is gone and when it went.

# Retire an identity worldwide. Every keyless check above starts returning "not a
# Whisper identity" within the DNS TTL. No coordination, no distribution list.
curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" \
  -H "content-type: application/json" \
  -d '{"query":"CALL whisper.agents({op:'"'"'revoke'"'"', args:{agent:'"'"'2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8'"'"'}})"}'

# With the CLI, the same teardown is one verb:
whisper kill --revoke 2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8

After that, Recipe 3's genuine-part check flips to is_whisper_agent:false for that address everywhere on the planet: the same negative result a counterfeit gets. Revocation and counterfeit-detection are, deliberately, the same mechanism. On a legitimate resale, revoke and re-register under the new owner: the data trail moves with the title.

Attribution: which fleet, which destinations (keyed)

The three recipes above need no key. If you hold one, the same public API answers a deeper question: the attribution graph. Passing an address to whisper.identify over POST https://graph.whisper.security/api/query returns what the graph knows about it (tenant/fleet, origins, history) as read-only Cypher:

curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" \
  -H "content-type: application/json" \
  -d '{"query":"CALL whisper.identify(\"2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8\")"}' | jq .

This is the graph API, not a CLI subcommand: there is no whisper identify verb; the call above is the interface. It feeds an equipment-security SOC: which destinations a fleet's telematics units resolve, task-file-CDN reputation, a gateway beaconing somewhere it shouldn't.

Where each recipe stops (and what's roadmap)

Honest scoping, one row per recipe. Whisper anchors the cloud/IP boundary; the air interface, the task-file format, and the silicon stay exactly where they are.

RecipeComplementsDoes not touch / replace
Drone ground & backend FAA Remote ID (Part 89) on the air interface the Part-89 broadcast; no Remote-ID credentials issued
Prescription & task files the FMIS's own auth, the ISOBUS task-controller workflow task-file content, format and signing, which stay with the FMIS
Anti-counterfeit part the secure element in the part the chip itself, the ISOBUS/J1939 bus, and TIM functional safety
▹

Roadmap, clearly labelled. Streaming this evidence into a SIEM ships today for Splunk, Microsoft Sentinel and OpenCTI. A STIX/TAXII feed and sector-ISAC sharing formats for food & agriculture are proposed, not yet available. And the --pin CLI flag is roadmap: provision machines via the control-plane API shown above, which is live. Nothing on this list is required for the three recipes; they run on shipped primitives alone.

Next

← Agriculture complianceEquipment & ECU identity →