Agritech integrations

Whisper sits beside the agricultural stack you already run and anchors exactly one thing: a routable, verifiable identity at the cloud/IP boundary. That's the layer where a harvested grant or a scraped API today looks identical to the real thing.

Everything below is a proposed integration pattern (our design, not a vendor endorsement), and every one is written the same way: Whisper complements the mechanism you have; it never replaces it. We do not sit on the ISOBUS/J1939 bus, we do not touch tractor-implement (TIM) functional safety, and we do not intercept a drone's Part-89 Remote-ID broadcast. Those live on the bus, in the safety case, and on the air, and they are already someone's job. Whisper's job is the network identity of whatever is talking to your cloud: the telematics gateway, the FMIS consumer, the drone ground station, the LPWAN concentrator. It's expressed as an IPv6 /128 that DNSSEC, DANE and RDAP can prove and one owner-thrown call can revoke.

Anchor the boundary, not the hitch

A connected machine carries several trust mechanisms, each correct for its own layer. The mistake is to imagine a new identity system has to displace one of them. It doesn't. Whisper is deliberately confined to the one place none of them cover: the moment a network endpoint claims to be a particular machine, ECU, or sanctioned data consumer, and the receiver has only a bearer token or a shared-CA certificate to go on.

Read the last row as the whole thesis: at the IP boundary, identity today is a claim carried in a header. Whisper turns it into a network fact: the source address itself, forward-confirmed in DNS, pinned in DANE, registered in RDAP.

John Deere Operations Center: the keystone

The Operations Center is the keystone FMIS surface: a single platform touching 400M+ engaged acres, with a mature public API programme. Access rides OAuth 2.0, an access token good for roughly twelve hours and a refresh token good for 365 days, and both are bearer credentials: portable to any IP on earth. That is exactly right for authorizing applications, and it says nothing about which network endpoint is presenting the grant a year after it was issued.

The integration is to give every sanctioned consumer (your integration hosts, your partners' backends) a Whisper /128 and allowlist those addresses beside the OAuth check. The grant authorizes the application, exactly as the platform designed; the address proves the endpoint. A refresh token that leaks into a scraper's hands is now separable from the real integration by a fact the scraper cannot fake, and the who-accessed-what record becomes per-identity, which is the trail a grower's data-use agreement presupposes.

# The platform side: is this API caller one of the sanctioned integration endpoints?
# Keyless, from stock tools: forward-confirmed reverse DNS + the verdict endpoint.
dig -x 2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8 +short
a6f1007b9e2d30c8.<tenant>.agents.whisper.online.

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": { … }}

ISOBUS & AEF Guideline 040: claim on the bus, proof on the wire

On the implement bus, ISO 11783 identifies every device with a 64-bit NAME: manufacturer code, function, ECU instance, identity number, carried in SAE J1939 framing on CAN. The NAME is self-declared, and nothing on the bus can cryptographically verify it. AEF Guideline 040, the AEF's ISOBUS security principles, names exactly this class of gap as the industry's starting point for securing ISOBUS communication.

Whisper's integration deliberately does not put cryptography on the bus. It gives the same machine a provable public counterpart at the IP boundary: the telematics gateway derives its /128 from its secure-element key with the machine's PIN as the domain separator, and everything the machine says to the cloud sources from an address anyone can verify against the IANA root. The bus keeps its NAME; the wire gains a proof.

# The machine's bus identity is a claim; its wire identity is a proof:
whisper verify --trustless a6f1007b9e2d30c8.<tenant>.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
CRYPTOGRAPHICALLY PROVEN · trust anchor: DNSSEC root (IANA) + DANE-EE

Secure element / TPM: the birth certificate

This is the shipped spine the other five build on. A secure element or TPM in the telematics gateway gives a machine a hardware birth certificate: a key that was generated on the silicon and whose private half never leaves it. Whisper derives the machine or ECU /128 from that device's public SubjectPublicKeyInfo plus its equipment PIN (and, optionally, an implement/ECU serial). The private key stays sealed where it was born; only the public SPKI is ever presented.

The derivation is deterministic and tenant-bound: the same key and PIN always yield the same /128 (idempotent re-provisioning), the mapping is unlinkable to outsiders so a fleet can't be enumerated from its addresses, and the result is DNSSEC-anchored, DANE-EE 3 1 1 pinned, and RDAP-registered the instant it's minted.

# Provision the /128 for a machine from the key it already holds + its PIN.
# identity_public_key is the device's PUBLIC SPKI (base64); the PIN rides in vin today.
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

Send it with stock tools. The control plane is one HTTP endpoint, and the key travels only in the header:

curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" \
  -H "content-type: application/json" \
  -d @connect.json | jq .      # connect.json = {"query":"CALL whisper.agents({op:'connect', ...})"}
{"ok": true, "status": 200, "result": {
   "address": "2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8",
   "wireguard": { "…": "…" }}}          # → the deterministic /128 + a WireGuard config

The behaviour is honest and predictable, which is the point:

Tear it down worldwide at DNS-TTL speed with one owner-thrown call. The /128, its PTR, and its DANE pin all go together:

CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8'}})
  YIELD op, ok, status, error RETURN op, ok, status, error

Cross-brand data exchange

Mixed fleets are the norm, so the industry built cross-brand exchange: DataConnect-style agreements move machine data between four major OEM and FMIS clouds so a grower sees one map, whichever colour the machine is. Every hop in that chain is a cloud-to-cloud API call authorized by contracts and tokens, and each hop is a place where "who accessed this grower's data" can go dark.

The integration is per-party identity along the chain: each participating cloud endpoint, each broker, each consuming FMIS carries a Whisper /128, so the access trail survives the brand boundary. When a grower or their association asks who touched the data, the answer is a list of verifiable identities, not a shrug between four clouds.

# Any party in the chain, or the grower's advocate, verifies a participant:
curl -s https://whisper.online/verify-identity/2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8
{"is_whisper_agent": true, "dane_ok": true, …}
# and the per-identity access log is one keyed call:
CALL whisper.agents({op:'logs', args:{agent:'<the consumer /128>', kind:'conn', from:'-30d'}})

Ag drones: the ground half of Remote ID

Agricultural drones fly under FAA Remote ID (Part 89): the aircraft broadcasts its identity on the air interface, and that broadcast is the regulator's domain, not ours. But everything behind the flight is internet infrastructure: the ground control station, the fleet-management backend, the spray-log upload, the USS/UTM endpoints. Those are exactly the machine↔cloud surfaces the rest of this page anchors.

Give the ground station and the fleet backend each a /128: command-and-telemetry egress becomes attributable per controller, the backend can allowlist the stations it actually owns, and a spray log arrives from an identity the food-traceability chain can cite.

# The fleet backend verifies a ground station before accepting a mission upload:
curl -s https://whisper.online/verify-identity/2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8
{"is_whisper_agent": true, "dane_ok": true, …}
# and its egress policy is default-deny, one keyed call:
whisper policy --agent 2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8 \
  --default deny --allow fleet.example-ops.com,uss.example-provider.com

Irrigation & LPWAN sensor networks

A centre-pivot controller or a LoRaWAN gateway concentrating a thousand soil-moisture sensors is a small computer with a cellular uplink, usually behind a carrier NAT, usually invisible in your logs beyond a shared IP. LoRaWAN's own OTAA join keys authenticate the sensors to the gateway; nothing authenticates the gateway to the internet.

The integration is one /128 per gateway or controller, with default-deny egress policy. A hijacked irrigation controller can't quietly talk to anything but its own platform, every connection it makes is logged per-identity, and the platform can verify the gateway it's hearing from is the one bolted to the pivot.

# Default-deny for a pivot controller: it talks to its platform and nothing else.
whisper policy --agent 2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8 \
  --default deny --allow telemetry.example-irrigation.com
policy updated · effective at DNS-TTL speed across both servers

# What did it actually reach last night? Per-identity, one keyed call:
CALL whisper.agents({op:'logs', args:{agent:'<the gateway /128>', kind:'dns', from:'-24h'}})

Shipped today vs proposed

Honesty about what runs matters more here than anywhere. The identity primitive under every integration is live and provable right now; the integration guides themselves are proposed patterns for wiring that primitive into each platform.

On the roadmap

These feed machine-security evidence into the tools a SOC already runs, listed here so you can see where this goes:

• Microsoft Sentinel connector: shipped today, alongside the Splunk connector.
• OpenCTI threat-intelligence integration: shipped today.
• STIX/TAXII export + sector-ISAC sharing formats: roadmap. Maps identity and egress evidence onto standard TI transports for the food-and-agriculture sharing channel and the ISO 24882 monitoring workflow.
• An equipment-native pin argument and an ISOBUS-NAME domain separator: roadmap. Today the PIN rides in vin, honestly labelled everywhere it appears.

Next

• Equipment & ECU identity: the shipped derivation these integrations all build on
• Equipment API-abuse cure, the primary wedge: identity at the farm-API ingress
• Agriculture compliance: where the evidence lands for ISO 24882, the Data Act and ADT