Agriculture

The equipment-API-abuse cure

A reverse-engineered farm-data API plus an OAuth grant that is portable to any IP is the entire data-harvesting problem. It has an OWASP name, BOLA, because the token authenticates a claim, never the machine on the other end.

Whisper closes it by making the address be the machine: a routable IPv6 /128 derived from the key already sitting in the machine, DNSSEC-anchored and DANE-pinned, that no broker can forge and one owner-thrown call can revoke worldwide. A harvested grant with no device key behind it authenticates to nothing, and the farmer finally gets a data trail with a network fact behind it. This page walks the abuse end-to-end, the reframe, and the exact live calls: keyless to verify, one keyed call to provision.

The abuse, at class level

It is not a breach. Your farm-data API is used exactly as it was built, at platform scale, by an operator who was never your customer.

The mechanics repeat across the industry. A third party reverse-engineers the platform's apps and partner docs, increasingly with the help of an LLM, until it holds the exact calls the sanctioned integrations make. It then authenticates the same ways they do: a phished grower login, a static partner key, or an OAuth bearer token that travels to any IP, with an access token that lives about twelve hours and a refresh token that lives a year. From there it is contract-less, low-and-slow polling: a request every few minutes, indistinguishable from a real integration because it is the integration's protocol. And the reach is enormous: a single major farm-data platform touches 400M+ engaged acres, and cross-brand exchanges now move machine data between four OEM and FMIS clouds, so one harvested grant reaches further than the platform it was phished from.

›

The root cause has a name: OWASP broken authentication / BOLA (Broken Object-Level Authorization, API1:2023). The token, key, or password authenticates a claim ("I am an authorized caller") but never proves which machine is on the other end. A researched disclosure showed the ceiling of a single flaw of this class: owner name, home address, equipment ID and VIN, reachable from nothing but a guessable identifier.

Two properties make it invisible at the network layer. A legitimate grower is one IP to one farm; the abuser is one operator to thousands, holding valid credentials. And the egress hops across clouds or a residential-proxy swarm every few requests, so a security operations center correlates a fresh, meaningless last IP and nothing else. The wound lands on the industry's one sacred promise: "farmers own their farm data" is the first principle of every ag-data code of conduct, and without a per-party network identity it is unenforceable. A data-sovereignty exposure, not only a security one.

The reframe: the address is the machine

Detection will always be a step behind a credential that is genuinely valid. You can tune models forever and the abuser still looks exactly like a grower: to your backend, they are one. The strictly-stronger move is to change what the backend trusts.

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-signed to the IANA root, DANE-EE pinned (3 1 1), and RDAP-registered. Anyone can re-derive and verify it with dig.

Point it at the machine. Whisper derives each machine's (or each ECU's) /128 from the hardware key it already holds: its public SubjectPublicKeyInfo from the secure element or TPM in the telematics gateway, with the 17-character equipment PIN (and optionally an implement/ECU serial) as the domain separator. The derivation is deterministic and tenant-bound: the same device key and PIN always yield the same /128, and the mapping is unlinkable across fleets to an outsider. The backend then authorizes on the machine's pinned identity, not a stealable token: a request either proves it is the machine it claims to be, before a single detection rule runs, or it has no authority at all.

›

The PIN is the public index: the /128 is its cryptographic counterpart. The PIN is stamped on the frame and printed in every auction catalogue; that is what the attacker weaponizes. But the /128 derives from the in-device key salted by the PIN, so PIN alone yields nothing. You cannot go PIN → /128 without the key, there is no enumerable directory, and RDAP / reverse DNS return the registry object, never the machine's whereabouts.

What changes

Nothing here is a new detection rule. Each row is an abuse technique that stops being possible, not one you catch after the fact.

The abuse today	Why it dies under identity
One IP → a whole co-op	You cannot present thousands of machine-identities whose device keys you do not hold. Every forgery is a DNSSEC / DANE inconsistency any verifier catches with stock tools: `dig -x` names an identity whose `AAAA` and TLSA don't agree.
Rotate egress across clouds / residential proxies	Identity is not the source IP. The last IP was never the credential, so rotating it, across AWS, GCP, Azure, or a proxy swarm, changes nothing about whether the caller can prove the machine.
Replay a harvested grant or partner key	The credential has no device key behind it. State-changing commands terminate mutually-authenticated to the target machine's `/128` (the machine co-signs), so a valid-looking token that can't prove the identity never had authority. BOLA / IDOR lose their leverage: reaching any account no longer reaches any machine.
Consent with no trail behind it	Every sanctioned data consumer is one verifiable `/128` with a per-identity access log. "Who accessed this farm's data" becomes a record you can show the farmer, and the unauthorized aggregator is separable by construction.
Blast radius on compromise	One `revoke` tears down the `/128`, its PTR, and its DANE pin worldwide at DNS-TTL speed, thrown by the owner and publicly checkable. No fleet-wide credential reset. Compromise one ECU and you have compromised that ECU, not the fleet.

Provision a machine identity

Provisioning is one control-plane call to POST https://graph.whisper.security/api/query with your X-API-Key header. You pass the machine's public key material (the base64 SubjectPublicKeyInfo of its secure-element / TPM key) and its PIN; you get back the deterministic /128 and a WireGuard config to source the machine's traffic from that address.

The call

CALL whisper.agents({op:'connect', args:{
  tier:'wireguard',
  identity_public_key:'<base64 SPKI of the machine key>',   # its secure-element / TPM public key
  vin:'1AGCM82633A004352'                                   # the 17-character equipment PIN rides here today
}}) YIELD op, ok, status, result, error
  RETURN op, ok, status, result, error

Over stock tools. jq builds the JSON body so the Cypher's own quotes never fight the shell:

# the public key only, the private key never leaves the machine's secure element
Q="CALL whisper.agents({op:'connect', args:{tier:'wireguard', \
   identity_public_key:'AAAAC3NzaC1lZDI1…SPKI', vin:'1AGCM82633A004352'}}) \
   YIELD op, ok, status, result, error RETURN op, ok, status, result, error"

curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" \
  -H "content-type: application/json" \
  --data "$(jq -nc --arg q "$Q" '{query:$q}')"

The response

# result carries the deterministic identity plus a ready-to-apply tunnel
address        2a04:2a01:1c0::a6f1
fqdn           pin-1agcm82633a004352.farm.<tenant>.agents.whisper.online
ptr            pin-1agcm82633a004352.farm.<tenant>.agents.whisper.online
state          active                       # DNSSEC + DANE-EE (3 1 1) live at provision time
wireguard_config   [Interface] …            # source the machine's traffic from its own /128

The machine now has a name it can prove and an address it egresses from. Reverse DNS resolves the /128 to that identity, a TLSA record pins the leaf key, and RDAP registers the object under 2a04:2a01::/32: the full seven-proof chain, published atomically with the allocation.

Idempotency and errors

The call is deterministic and honest about conflicts: conservative in what it emits, liberal in what it accepts.

You send	You get
The same device key + PIN again	The same `/128`: idempotent, safe to retry, safe to run on every boot. No duplicate identities.
The same device key with a different PIN on your tenant	`409 Conflict`: a device key binds to exactly one machine. The `error.detail` tells you which identifier it is already bound to.
A non-string identifier (a number, an array, null)	`400` with an actionable `detail`, never an opaque `500`. Send the PIN as a string.

›

On the CLI: whisper create --register mints a generic agent identity, and whisper verify / whisper policy / whisper logs / whisper kill --revoke drive the rest. The equipment-specific --pin flag is not shipped yet. Provision machines through the control-plane call above, which is live today, and drive them with the CLI verbs once allocated.

Revoke, worldwide, owner-thrown

Decommission, trade-in, auction sale, or a compromised ECU is one call. It's provable with the same stock tools that proved the identity existed, no Whisper software required, and the act is publicly checkable: the accountable kill-switch, never a covert lockout.

# the control-plane op…
CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:1c0::a6f1'}})
# …or the CLI
whisper kill --revoke 2a04:2a01:1c0::a6f1

# now prove it, worldwide, at DNS-TTL speed:
dig -x 2a04:2a01:1c0::a6f1 +short                       # -> nothing
curl -s https://whisper.online/verify-identity/2a04:2a01:1c0::a6f1
# -> {"is_whisper_agent": false, ...}

Verify it: keyless, no account

The identity is public by design, so anyone (your PSIRT, a partner platform, an auditor, a regulator, the farmer) can check a machine without your key and without taking Whisper's word for it. This is the keyless half of the two-tier surface: verify with no key, provision and govern with your key.

# no key, no account: re-derive and verify the machine's identity, trustless to the IANA root
whisper verify --trustless 2a04:2a01:1c0::a6f1

# or with only curl: the keyless full-chain verdict
curl -s https://whisper.online/verify-identity/2a04:2a01:1c0::a6f1
# { "is_whisper_agent": true, "dane_ok": true, "jws_ok": true, "evidence": { ... } }

# the address IS the machine: forward-confirmed reverse DNS names it
dig -x 2a04:2a01:1c0::a6f1 +short
# pin-1agcm82633a004352.farm.<tenant>.agents.whisper.online.

# the registry object for the /128: RDAP, typed JSON
curl -s https://whisper.online/ip/2a04:2a01:1c0::a6f1 | jq '.handle, .parentHandle'
# "2A04:2A01:1C0::A6F1/128"
# "2A04:2A01::/32"

The --trustless flag is the point: nothing there calls back to Whisper's own API as an authority. The CLI re-derives the DNSSEC chain to the IANA root, on your machine, with your resolver. A regulator, or a farmer, can verify a machine outside your cloud's tenancy. Full mechanics: Verify an agent and DANE & TLSA.

Name what already got in

Identity stops the next forgery. It does not name the operator behind the grants already in your logs. The same platform back-traces them, and the attribution survives the rotation because it fingerprints the operator's infrastructure, not the ephemeral egress IP.

Take a suspect egress IP straight from your SOC logs and ask the graph who really operates it. This runs read-only over the same public graph API, with your key:

# who really operates a host, even behind a CDN or a cloud front
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(\"203.0.113.10\")"}'

The read-only verbs (identify, origins, walk, variants, history) run over that one endpoint against a live internet-infrastructure graph of fused BGP, DNS, WHOIS, TLS, hosting, and threat intelligence. Cloud rotation collapses through origins and walk, which cluster shared ASN, hosting, and certificate lineage into one infrastructure genealogy; history gives a timeline over a suspect operator. Every answer is reproducible, replayable JSON: the paper trail a GDPR or Data-Act finding needs, and the receipt a farmer's data-sovereignty question deserves, not a screenshot.

›

These graph verbs are the API surface: you call the endpoint directly, as above. There is no whisper identify / graph / export CLI subcommand; the CLI covers the control plane (create, verify, policy, logs, kill), and the graph is the query API. See Graph & cognition.

Where it fits: standards, SIEM, integrations

Whisper is additive. It rides on top of the anchors you already ship and the SIEM you already run. It replaces none of them.

Compliance. The per-/128 egress logs and the attribution graph are ready-made continuous-monitoring and forensics evidence for ISO 24882 (agricultural-machinery cybersecurity, DIS registered October 2025 in ISO/TC 23/SC 19); forge-proof per-machine identity and one-call, owner-thrown revocation give AEF Guideline 040's ISOBUS security principles their missing public-crypto counterpart at the IP boundary; and the EU Data Act (in force since 12 September 2025, and reaching connected farm machinery) multiplies the third parties calling your equipment APIs at the exact moment the sector is standardizing how to control them: each authorized party becomes one /128 plus DANE plus a who-accessed-what trail, which is also exactly the record Ag Data Transparent's "farmers own their data" principle presupposes. The mapping lives in Agriculture compliance.

›

Shipped vs roadmap. The Splunk, Microsoft Sentinel and OpenCTI connectors ship today; findings arrive as signed JSON mapped to CEF and ECS fields. Roadmap, labelled as such and not yet available: STIX 2.1 over TAXII export, and sector-ISAC-ready sharing formats for food & agriculture.

Integrations (proposed, not vendor-endorsed). Whisper anchors the cloud and IP boundary, never the implement bus, the drone broadcast, or the safety path:

Farm-data platforms. Every sanctioned consumer calling the platform APIs becomes one verifiable /128 the platform can allowlist, so a year-long refresh token replayed from an unknown address is separable from the real integration. Complements the platform's OAuth; does not replace it.
ISOBUS / AEF Guideline 040. The 64-bit NAME stays the bus identity; the derived /128 is its cryptographically provable public counterpart. Whisper never touches the J1939/CAN bus.
Cross-brand data exchange. When machine data moves between brand clouds, each party in the chain carries a verifiable /128, so "who accessed this grower's data, from which cloud" survives the brand boundary.
Secure element / TPM. The cleanest bridge: derive the /128 from the device's birth-certificate public key. The publicly verifiable, DNSSEC-anchored layer on top of the silicon identity you already stamp.

And it is built to fail open: a Whisper outage never parks a machine; checks degrade to the anchors you already ship and connectivity is preserved. Harvest doesn't wait for anyone's uptime.

Equipment & ECU identity: how the /128 is derived from the device key and PIN, in depth
Control plane: the full whisper.agents op set the provisioning call belongs to
Agriculture compliance: the clause-by-clause evidence mapping

← Equipment & ECU identity Agritech integrations →