A harvested token and a guessable serial shouldn't be able to reach every machine on the land.
The abuser logs in with a real grower's OAuth grant, so they pass every auth check, then rotate across Amazon, Google and Azure until all your SOC has logged is a meaningless last IP. The yield maps, field boundaries and as-applied records leave quietly, and the farmer who owns that data never learns it happened. It works for one reason: your machines have no identity they can prove.
whisper verify --trustless · anchored at the IANA DNS root. Our own API is not in the trust path.
This is how a whole co-op's data gets harvested by someone who was never a customer.
No zero-day. No malware. Just authorization logic used exactly as built, at farm scale.
The PIN is a public index
An equipment PIN is a structured, guessable 17-character string stamped on the frame and printed in every auction listing. A grower's email address is enough to begin.
Harvest a valid grant
Phish an FMIS login, or reuse an OAuth grant whose refresh token stays valid for a year. Now they hold a real, valid session, portable to any IP on earth.
The platform says yes
The farm-data backend authorizes it; nothing is broken, the token is genuine. One BOLA/IDOR flaw turns one grower's account into any grower's fields. A researched disclosure once reached owner name, home address, equipment ID and VIN from a guessable identifier alone.
One IP, a whole co-op
Enumerate organizations and fields; pull yield maps, boundaries, as-applied and input records, low-and-slow, under every rate limit.
Every last IP is disposable
Egress hops Amazon → Google → Azure, or a residential-proxy swarm, every few requests. Your SOC sees a fresh last IP and correlates nothing.
Agronomic data, resold
Field boundaries, yields and input plans traded with no consent and no contract: commodity-scale intelligence lifted off the people who grew it. A data-sovereignty incident, not only a security one.
Invisible at the network layer by design: a real grower is one IP to one farm; the abuser is one operator to thousands, and every IP they ever show you is disposable. The stakes are not hypothetical: attacks on food and agriculture roughly doubled in 2025, a ransomware attack halted an equipment maker's production in planting season 2022, and one processor paid $11M to restart plants that handle about a fifth of US meat.
Strip the incident down and it isn't a hundred bugs. It's two.
Every step in that chain leans on exactly two structural gaps that every connected-agriculture program shares. Close both and the attack has nowhere left to stand.
Rate-limit an IP and they spin up a fresh one. The egress is disposable; the last IP was never the attacker. So you block noise while the operator keeps working.
The answer: the graph. A live internet-infrastructure graph, 7.44B nodes and 39.3B relationships of fused BGP, DNS, WHOIS, TLS, hosting and threat intelligence, answering in under 300 ms, fingerprints the operator, not the IP. Two levers, kept honestly separate: for cloud rotation the graph clusters shared ASN, hosting and certificate lineage into one infrastructure genealogy; for a residential-proxy swarm, where a subscriber IP gives an infra graph nothing to grab, a JA4/JA3 client fingerprint travels with the tooling regardless of the exit and collapses the swarm to one operator. Every answer returns a reproducible evidence chain your SOC, your auditors and a regulator can replay.
The verbs your analysts run, or your agent runs for them: identify(ip) (who really operates a host, even behind a CDN) · origins(prefix) + walk(node,depth) (cluster rotating IPs into one genealogy) · history / watch (a timeline and a standing sentinel) · arbitrary read-only Cypher (express "one source touching N distinct machine-identities in a window" as a query, not a ticket).
"When they rotate residential proxies and fresh cloud IPs, can you actually attribute them, or just rate-limit an IP and move on?"
Track them. Infrastructure genealogy collapses the cloud rotation; a JA4 client fingerprint collapses the residential swarm. The egress IP is the one thing we don't rely on.
A harvested grant or a leaked partner-API key is a valid credential. Behaviorally it's a grower. Nothing at the perimeter separates it, because the credential is a bearer secret: whoever holds it can present it. And on the wire below the cloud, an ISOBUS NAME is a self-declared claim, not a cryptographic proof.
The answer: identity. Bind the session to the machine's own forge-proof /128, an address derived from the key already sitting in the machine's secure element, one the machine can prove and no broker can. A harvested token without the machine's leaf key simply fails, and every access that does happen leaves a per-identity trail the farmer can be shown.
"A leaked API key or a valid partner session looks legitimate; how do you catch abuse that passes auth?"
You bind authority to the machine, not the bearer. State-changing commands terminate mutually-authenticated to the target machine's /128, the machine co-signs, so a platform or partner session can't reach a serial it can't cryptographically address. A request that passes auth but can't prove the identity never had authority in the first place.
Gap 1 is detection made durable. Gap 2 is the root cause. Here's the root-cause cure.
Give every machine an identity it can prove, and no one can forge.
Stop treating equipment-API abuse as a detection problem and make it an identity problem: strictly stronger. Whisper has one primitive: the address is the identity.
A routable IPv6 /128 out of 2a04:2a01::/32 (announced by AS219419), deterministically derived from a key, DNSSEC-anchored, DANE-EE pinned, RDAP/WHOIS-registered: re-derivable and verifiable by anyone with dig. whisper verify --trustless checks it against the IANA root; our own API is not in the trust path.
Point it at machines. Derive each tractor's, implement's or ECU's /128 from the hardware key it already holds: the secure element or TPM, with the 17-character equipment PIN or an implement/ECU serial as the domain separator. The private key never leaves the secure element; the address is a one-way function of its public half and the PIN. The platform then authorizes on the machine's pinned identity, not a stealable token. And where ISOBUS (ISO 11783 over J1939/CAN) gives a device a NAME that is only a claim, the /128 is the cryptographic counterpart at the machine↔cloud boundary.
"1 IP → a whole co-op" becomes physically impossible
You cannot present thousands of machine-identities whose keys you don't hold. Every forgery is a DNSSEC/DANE inconsistency any verifier catches.
IP rotation becomes irrelevant
Identity is not the source IP. The "last IP" was never the credential, so rotating it, across clouds or residential proxies, changes nothing.
Harvested grants fail
The broker's server doesn't hold the machine's per-/128 leaf key. A valid-looking token with no key behind it authenticates to nothing.
One revoke, thrown by the owner, verifiable by anyone
At DNS-TTL speed: dig -x returns nothing; verify returns false. Public DNS shows who retired the identity and when. A kill-switch with a paper trail, never a covert lockout.
NAME and AEF Guideline 040's ISOBUS security principles, the secure element or TPM in the telematics gateway, and the X.509 device-cert mTLS your OEM cloud already runs. It is the publicly verifiable, DNSSEC/DANE-anchored layer on top: no bespoke CA trust store to push to every machine, and revocation at DNS-TTL speed instead of CRL/OCSP soft-fail. It never reaches into the ISOBUS/J1939 bus itself or the tractor-implement (TIM) safety functions.revoke. Farm equipment changes hands more than cars do: a trade-in or auction sale is one revoke and a re-register to the new owner, so the data trail transfers with the title instead of leaking past it. An ECU or telematics-gateway swap re-keys to a new /128 and revokes the old one. Compromise one ECU and you've compromised that ECU, not the fleet: the shared-root failure mode is structurally removed.revoke is the accountable version: thrown by the registered owner, visible in public DNS, checkable by anyone with dig. Explicitly not a covert OEM lockout; a farmer can prove their machine's identity is live just as easily as an OEM can prove a stolen one is dead.Maps to ISO 24882 (agricultural-machinery cybersecurity, DIS registered October 2025 in ISO/TC 23/SC 19, carrying the UN R155 lineage into agriculture), AEF Guideline 040 (ISOBUS security principles), the EU Data Act (in force since 12 Sep 2025 and reaching connected farm machinery), Ag Data Transparent (farmers own their farm data; consent-based use becomes a checkable network fact) and the FSMA 204 / EUDR traceability wave. Know, attribute and revoke every machine, delivered as a network primitive, not a compliance binder.
The same primitive governs the autonomous machines and AI agents your fields are about to run.
Autonomous 9RX-class tractors are already working fields without a person in the cab; ag drones fly under FAA Remote ID; agronomy copilots read and write farm data on a grower's behalf. Every one of them is an agent making network calls, and today the answer to "which one did this" is a shrug at a shared NAT address. Whisper does it with identity instead of trust.
Which agent did this is the source address
Every autonomous machine, drone controller and agronomy agent egresses from its own routable /128: attribution, not a guess.
Every query and connection is logged per-agent
Queryable live via op:logs: a per-agent record, not a shared firehose. The trail the farmer can be shown.
Policy on every query
A graph-first resolver and bound egress enforce category, geography, ownership and routing: default deny, allow or block by name or subdomain. An autonomous tractor that should only ever talk to its OEM's ops endpoints simply can't talk to anything else.
Inbound agents are verifiable
FCrDNS, RDAP, whisper verify: "trust the bearer token / the description field" becomes a checkable fact. Per-agent budgets, a kill-switch, one revoke.
The autonomy, farm-API, MCP and LLM surface the incumbents are only now reaching for, governed by the same address-is-identity primitive, from day one.
Don't take our word for it; our API isn't in the trust path.
Two tiers, by design. No key: anyone can verify a machine's identity, resolve it, and back-trace a suspicious host, trustless, anchored at the IANA root. Your key: register a machine, govern its agents, revoke it worldwide.
# keyless: re-derive and verify any machine's identity, trustless
$ whisper verify --trustless 2a04:2a01:1c0::a6f1
✓ DNSSEC chain valid to the IANA root
✓ DANE-EE (TLSA) leaf matches the identity's key
✓ RDAP: registered under AS219419 · 2a04:2a01::/32
identity: VERIFIED, and our own API was never trusted
# the address is the machine: reverse DNS names it
$ dig -x 2a04:2a01:1c0::a6f1 +short
pin-1agcm82633a.farm.example-oem.whisper.online.
# who really operates a suspicious host: the real graph API, a CALL whisper.identify()
$ 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(\"34.90.x.x\")"}'
operator: <fingerprinted> · seen across AWS / GCP / Azure
residential swarm collapsed by JA4: same tooling, 41 exit IPs → 1 operator# give a machine a name it can prove, and govern its agents
$ export WHISPER_API_KEY=whisper_live_xxx
# --pin/--from-secure-element are on the roadmap; today the 17-char PIN rides the live control-plane vin arg (see docs)
$ whisper register --pin 1AGC… --from-secure-element
→ identity 2a04:2a01:1c0::a6f1 DNSSEC + DANE live
$ whisper policy set --default deny --allow ops.example-oem.com,updates.example-oem.com
$ whisper revoke 2a04:2a01:1c0::a6f1 # owner-thrown, publicly verifiable, at DNS-TTLYour SOC sees that an API is abused. Whisper tells you who, and proves it's really the machine.
The best behavioral vehicle SOC on the market, Upstream, is extending into agricultural OEMs and engaging publicly on ISO 24882; it detects abuse at the app layer, inside your own cloud, and its digital twin is good at it. That's necessary, and it's where the picture stops. Whisper adds the two layers no one else owns: an internet-infrastructure attribution graph that fingerprints the adversary across rotating clouds and residential proxies, and an equipment/agent identity plane that tells a legitimate machine from an impostor after auth, checkable with stock dig and revocable worldwide in one call. Exactly the two gaps the equipment-API attacks exploit.
| Upstream | Whisper | |
|---|---|---|
| Detect API abuse in your cloud (BOLA, business-logic) | ✓ | additive feed |
| Attribute the operator across rotating clouds / residential proxies | – | ✓ |
| Forge-proof per-machine / per-agent identity after auth | – | ✓ |
It's depth on top of the stack you already run: it rides on the same X.509 device-cert mTLS your equipment cloud already speaks and maps straight to your ISO 24882 and Data Act evidence, landing as a machine-readable feed into your SIEM (the Splunk and Microsoft Sentinel connectors ship today), enrichment that makes Recorded Future, Mandiant and Sentinel sharper. It doesn't replace them, and it doesn't add a console your analysts babysit.
Additive to your stack. Mapped to your standards. Priced so you can say yes.
Feeds your SIEM, not another console
The Splunk, Microsoft Sentinel and OpenCTI connectors ship today. Findings map to CEF and ECS fields, with STIX 2.1 over TAXII export on the roadmap; a sample Sentinel analytics rule and a Splunk CIM mapping ship in the docs. The evidence chain is signed, replayable JSON you can hand a regulator, or a farmer.
Speaks your compliance language
Maps to ISO 24882 (DIS, October 2025) and AEF Guideline 040 evidence, to the EU Data Act's authorized-party line, and to Ag Data Transparent's core promise: farmers own their data, and now you can show them the trail. Usable in your risk assessment and your certification file, not just a dashboard.
In your auth path, and safe there
It rides on top of the X.509 device-cert mTLS your equipment cloud already runs, anchoring that same identity in public DNSSEC/DANE rather than replacing your vendor's mTLS. If your backend authorizes against the DANE/verify path, that plane is built to fail open: a Whisper outage never parks a tractor mid-harvest; checks degrade to your existing anchors and connectivity is preserved. Anycast on AS219419, no single node in the path.
Flat, predictable pricing
Per-machine/year and flat: not per-transaction, not usage-metered, not per-acre. Against always-on telematics economics that's a line item you can forecast, not a metered cloud bill you can't. Clear ROI: analyst-hours saved correlating disposable IPs, one revoke instead of a fleet lockout, a data-sovereignty audit that answers itself. See pricing →
On-prem or your own tenant
Data residency and GDPR by construction: the graph and the per-agent logs stay where your regulator, and your growers, need them. Data sovereignty for the platform is what you already promise the farmer; this is the version you can prove.
A vendor that will still be here
Real routable address space (AS219419), run by people who ran the internet's regional address registry and operated one of its root DNS servers. Agtech startups fold and strand their fleets; we built infrastructure to outlast that question. POC → pilot → enterprise, keyless to start.
Give every machine an identity it can prove.
The address is the machine: routable, DNSSEC-anchored, revocable by the owner in one publicly verifiable call. Keyless to try, one call to provision, one more to revoke.
Or run whisper verify --trustless right now.