# 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.

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. Cloud rotation clusters into one infrastructure genealogy; a residential-proxy swarm collapses on a `JA4/JA3` client fingerprint that travels with the tooling. 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.

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.

**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. 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.

Gap 1 is detection made durable. Gap 2 is the root cause. Both arrive where your analysts already work.

## 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`.

### 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. Who is this, provably.

### Attribution graph

The operator fingerprint across rotating clouds and residential proxies, 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; default-deny policy per query; one `revoke` and a kill-switch. What may talk to what.

**Additive to what you already ship; it does not replace it.** Whisper complements the secure element or TPM, the X.509 device certificate your equipment cloud already issues over mTLS, the ISOBUS (ISO 11783) `NAME` and AEF Guideline 040's security principles. It 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. One leaf key per identity, never a shared root.

## 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_…",
  "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 > 25
```

The 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 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 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.

### 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. 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.

| 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 export (roadmap) |
| Post-auth identity binding (the machine co-signs) | ISO 24882 (DIS) 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 | 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 |

Honest labels: ISO 24882 is at DIS stage (registered October 2025, ISO/TC 23/SC 19), 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 →](/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. 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. If an upstream is slow or down, we fail open and keep serving.

### A minimal, published attack surface

Standard ports, standard tooling (`dig`, `kdig`, `curl`), an SBOM you can diff. 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: registry-anchored, RDAP-resolvable space.

## Priced so you can forecast it, from a vendor built to outlast the question.

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. 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. [See pricing →](/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 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.

### Feeds the SIEM you already run

A machine-readable feed that makes Recorded Future, Mandiant and Sentinel sharper. [See the full comparison →](/compare)

### Spec it into your supply chain

Write Whisper identity into your supplier interface agreements so every sourced telematics gateway and ECU ships identity-ready.

### A procurement path with an off-ramp

Keyless POC today, 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.

```sh
# 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
```

```sh
# 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
$ whisper revoke 2a04:2a01:1c0::a6f1      # owner-thrown, publicly verifiable
```

## Additive 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.
