Your SOC, your PSIRT, your SIEM, and the equipment-API attack still harvests your growers' data.
It never breaks anything. It logs in with a real grower's harvested grant, so behavioral detection sees a grower; it rotates across Amazon, Google and Azure, so your SIEM correlates a meaningless last IP; and by the time PSIRT has an advisory, the agronomic data is already resold and the "farmers own their data" promise is already broken. Two capabilities are missing from every connected-agriculture program, and neither of them is a new console.
whisper verify --trustless · anchored at the IANA DNS root. Our own API is not in the trust path.
No layer of your program is wrong. The attack is engineered to fall in the seams between them.
You specced security into every sourced component, stood up a SOC, ran a PSIRT, and route it all into the SIEM. Here is what each layer sees when an equipment-API abuse campaign runs, and why the growers' data still leaks.
A valid grant, behaving like a grower
The credential is genuine and the requests are low-and-slow, under every rate limit. Behaviorally it is one of your growers or partners; there is nothing anomalous to alert on until the enumeration is already done.
A last IP that means nothing
Egress hops Amazon → Google → Azure, or a residential-proxy swarm, every few requests. Each event carries a fresh source IP, so correlation across them yields a rotating fog, and a block on noise.
An advisory after the harvest
By the time the pattern is understood and triaged, whole-platform agronomic data is harvested and resold with no consent trail. A data-sovereignty and Data-Act incident, not only a security one.
Two structural gaps live in that seam, and every connected-agriculture program shares both. Close them and the attack has nowhere left to stand.
Strip the incident down and it isn't a hundred bugs. It's two.
Both are the kind a red-teamer names on sight, not a compliance checkbox. Here they are, and here's exactly how each closes.
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.
"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, and every finding lands in your SIEM as a reproducible, replayable evidence chain, not a hunch.
A harvested grant or a leaked partner 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.
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 the failure is a first-class, loggable event your PSIRT can act on.
"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. Both arrive where your analysts already work; read on for the wiring.
Three planes on one primitive, and all three exit into the stack you already run.
The primitive is one line: the address is the identity: a routable IPv6 /128 out of 2a04:2a01::/32 (announced by AS219419), DNSSEC-anchored, DANE-EE pinned, verifiable by anyone with dig. Point it at your fleet and you get three planes, no new silo.
Identity
Each machine's or ECU's /128 is derived from the key it already holds in its secure element or TPM, with the 17-character equipment PIN or an implement/ECU serial as the domain separator. The backend authorizes on the machine's pinned identity, not a stealable token. Who is this, provably.
Attribution graph
The operator fingerprint across rotating clouds and residential proxies, infrastructure genealogy plus JA4/JA3, with a reproducible evidence chain on every answer. Who's really behind this, when the IP rotates.
Agent governance
Every autonomous machine and AI agent egresses from its own /128; every query and connection logged per-agent; a graph-first resolver enforces default-deny policy per query; one revoke and a kill-switch. What may talk to what, on the autonomy surface you're about to run.
NAME and AEF Guideline 040's security principles. 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 rides on top of the mTLS your cloud already runs and never replaces the vendor CA: it adds an identity a regulator, a peer, or a farmer's advocate can verify outside that cloud's tenancy, without the vendor's account, plus per-machine egress attribution from the machine's own /128. One leaf key per identity, never a shared root: compromise one ECU and you've compromised that ECU, not the fleet.Findings arrive where your analysts already work, as evidence, not another alert to babysit.
Every attribution and identity finding is a reproducible, replayable JSON evidence chain. It fans out into your SIEM, into a form your peers and the Food & Ag-ISAC channel can ingest, and into the artifacts your certification file needs, from the same object.
# STIX 2.1 sighting: one operator behind a rotating egress
{
"type": "sighting", "spec_version": "2.1",
"sighting_of_ref": "indicator--farm-api-enumeration",
"count": 41, # 41 exit IPs → 1 operator
"x_whisper_operator": "<fingerprinted>",
"x_whisper_ja4": "t13d1516h2_8daaf6152771_…", # tooling, not exit
"x_whisper_scope": { "distinct_machines": 2187,
"window": "15m" },
"x_whisper_evidence": "https://verify… (signed, replayable)"
}
# the matching Microsoft Sentinel analytics rule: one line of KQL
# WhisperFindings | where OperatorConfidence > 0.9 | where DistinctMachines > 25The Splunk, Microsoft Sentinel and OpenCTI connectors ship today. Findings map cleanly onto CEF and ECS fields, with STIX 2.1 over TAXII export on the roadmap; a Splunk CIM mapping and a sample Sentinel analytics rule ship in the docs. For PSIRT, a finding is not a raw alert: it is an attributed operator plus a signed evidence chain your triage can act on, and hand to a regulator, or to a grower association asking hard questions, unchanged.
And the raw material is already on your side of the wire: the per-/128 egress logs, every query and connection a machine or its agents made, keyed to its own address, together with the attribution graph are ready-made continuous-monitoring and forensics evidence for the ISO 24882 lifecycle the sector is standardizing right now, and the who-accessed-what record the EU Data Act and Ag Data Transparent both presuppose. Continuous monitoring and post-incident forensics come out of the same signed object your SIEM already ingests, not a second collection you have to stand up.
In your auth path, and safe there
If your backend authorizes against the DANE/verify path, that plane is built to fail open. A Whisper outage never parks a machine: the check degrades to the anchors you already ship, and connectivity is preserved. Conservative in what we emit, liberal in what we accept: a machine is never denied because we were unreachable, and harvest doesn't wait for anyone's uptime.
Mapped to ISO 24882, AEF 040, the Data Act and Ag Data Transparent, as evidence you can file, not a dashboard you screenshot.
Every capability lands on a clause and produces an artifact. The timing matters: ISO 24882 (DIS registered October 2025, ISO/TC 23/SC 19) is carrying the UN R155 / ISO 21434 lineage into agricultural machinery right now, and the EU Data Act already reaches connected farm equipment. The program you evidence today is the certification you file tomorrow.
| Capability | Framework / clause | Evidence artifact |
|---|---|---|
| Attributed operator across rotating infrastructure | ISO 24882 (DIS): monitoring, detection & response for ag machinery | Signed, replayable evidence chain · STIX 2.1 sighting export (roadmap) |
| Post-auth identity binding (the machine co-signs) | ISO 24882 (DIS) cybersecurity controls · AEF Guideline 040 ISOBUS security principles | DANE-EE pin · verify transcript |
| Per-component identity + one-call, owner-thrown revoke | ISO 24882 (DIS) lifecycle & risk assessment | Identity register · revoke log, publicly checkable in DNS |
| Authorized-user vs unauthorized-aggregator line | EU Data Act (in force 12 Sep 2025; connected machinery in scope) · GDPR | Verifiable per-party identity · per-agent logs |
| "Farmers own their farm data," provable | Ag Data Transparent core principles: ownership, consent-based ATP use | Per-identity who-accessed-what record the farmer can be shown |
| Trustworthy origin behind traceability records | FSMA 204 (records due 20 Jul 2028) · EUDR geolocated plots | Harvest and telemetry events attributable to a verified machine identity |
# ROADMAP: STIX 2.1 (JSON) export · the shape a finding will take
{
"framework": "stix-2.1",
"findings": [
{ "pattern": "farm-api-enumeration",
"operator": "<fingerprinted>", "distinct_machines": 2187,
"evidence": "signed · replayable",
"iso24882_ref": "risk assessment / threat scenario",
"data_act_ref": "authorized-party access record" }
]
}
# hand it to your peers and your sector ISAC unchanged: machine-readable, not a PDFUsable in your risk assessment and your certification file, and shareable in the cross-industry channel you already sit in, not a bespoke report a peer has to re-key. Note the honest labels: ISO 24882 is at DIS stage, and we say so; the connectors that ship today are Splunk, Sentinel and OpenCTI; STIX/TAXII is roadmap. See the full mapping in the docs →
On-prem or your own tenant, and a vendor whose own posture survives your review.
Data residency & sovereignty by construction
Run the graph and the per-agent logs on-prem or in your own tenant, in the jurisdiction your regulator requires. Nothing about your growers leaves where you put it; there is no shared multi-tenant lake your data lands in by default. The sovereignty you promise farmers is the sovereignty you get.
No external dependency on the hot path
Resolution, identity verification and RDAP are answered by self-contained nodes: no chatty third-party call at serve time. If an upstream is slow or down, we fail open and keep serving. That's an availability property your assessors can test, not a promise.
A minimal, published attack surface
Standard ports, standard tooling (dig, kdig, curl), an SBOM you can diff, and a wire format that is strict on what it emits and liberal in what it accepts. The identity primitive is verifiable without trusting us: whisper verify --trustless anchors at the IANA root.
Real address space, operated as such
The identities live in production IPv6 (2a04:2a01::/32, AS219419) that we announce and run. This isn't a lab allocation: it's registry-anchored, RDAP-resolvable space, treated with the discipline that implies.
Priced so you can forecast it, from a vendor built to outlast the question.
And the timing isn't yours to choose. The EU Data Act, in force since 12 September 2025, obliges you to open machine data to the third parties a user chooses, multiplying the parties calling your equipment APIs at the exact moment ISO 24882 asks you to monitor and control them, and while ransomware against food and agriculture roughly doubles year over year. That is the procurement forcing function: the Data Act makes you open the doors; Whisper is the doorway that knows who walked through, and can shut it on one.
Flat, predictable pricing
Per-machine per-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, and not a rigid module bundle you have to justify. See pricing →
ROI your CFO can read
Analyst-hours saved not correlating disposable IPs. Incident blast radius cut when a compromised component is one revoke, not a fleet lockout in planting season. A Data-Act or data-sovereignty incident avoided is the whole year's budget.
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 point solutions fold and strand their fleets; we built infrastructure to outlast that question, not a feature to sell into it.
Feeds the SIEM you already run
Depth on top of the stack you own: a machine-readable feed that makes Recorded Future, Mandiant and Sentinel sharper. It doesn't replace them, and it doesn't add a console your analysts babysit. See the full comparison →
Spec it into your supply chain
Write Whisper identity into your supplier interface agreements so every sourced telematics gateway and ECU ships identity-ready from the supplier: the defense-in-depth you already require, extended to the network layer.
A procurement path with an off-ramp
Keyless POC today: verify and attribute with no account, no contract, no risk. Then a paid pilot on one machine line, then enterprise across the fleet. Every stage is verifiable before the next, because our API is never in the trust path.
Don't take our word for it; our API isn't in the trust path.
Two tiers, by design. No key: anyone on your team can verify a machine's identity, trustless, anchored at the IANA root. Your key: back-trace a suspicious host through the graph API, provision a machine, govern its agents, feed the findings into your SIEM, and 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
# who really operates a suspicious host: the public graph API (with your key)
$ 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 wire the findings into your stack
$ 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 logs 2a04:2a01:1c0::a6f1 # per-/128 evidence for your SOC
# STIX/TAXII → your SIEM: on the roadmap; Splunk/Sentinel/OpenCTI ship today
$ whisper revoke 2a04:2a01:1c0::a6f1 # owner-thrown, publicly verifiableAdditive to your stack. Mapped to your standards. Priced so you can say yes.
Durable attribution and post-auth identity, fed into the SOC, PSIRT and SIEM you already run: on-prem, mapped to ISO 24882 / AEF 040 / the Data Act / Ag Data Transparent, from a vendor built to outlast the question. Keyless to try, one call to provision, one more to revoke.
Or run whisper verify --trustless right now.