AI on a farm is not a chatbot problem. Models estimate yield from imagery, flag disease from leaf photos, draw variable-rate maps that tell a sprayer how much product to apply in each part of a field, and steer machines that weigh many tonnes. An LLM may sit on top as an advisor that answers a grower's questions. When these systems are wrong, the failure lands in soil, water and food: an over-application of a pesticide, a missed disease outbreak, a planter that drifts across a boundary, or a yield dataset that leaks a farm's commercial position.

This article treats agricultural AI as a security and safety engineering problem. It maps the system from sensor to actuator, names the threats at each boundary, and gives concrete controls: integrity checks on inputs, a deterministic guard on every prescription, an LLM advisor that cannot invent an application rate, a safety path for autonomy that does not depend on the ML stack, and data handling that respects the grower's ownership. A worked example follows a fungicide recommendation from drone flight to sprayer.

The architecture: sensing, data, models, actuation

Agricultural AI: from sensing to actuation, with the trust boundaries markedSatellite / droneimagery, indicesField sensorssoil, weather, trapsMachine datayield, CAN / ISOBUSGNSS + RTKposition, correctionsIntegrity layerplausibility, provenanceFarm data platformconsent per purposeModelsyield, disease, stressLLM advisorgrounded on labelsPrescription guarddeterministic limitsproposalAgronomistapprovesMachinetask controllersigned taskSafety controllerindependent stopYellow: where untrusted inputs are checked. Red: where software decisions become chemicals,seed, water or motion. Only signed, guarded, approved tasks cross into the machine.
Reference architecture. Inputs pass an integrity layer, models propose, a deterministic guard and a human approve, and only signed tasks reach the machine.

The architecture has four zones. Sensing brings in satellite and drone imagery, soil probes, weather stations, insect traps, yield monitors and machine telemetry from the CAN bus and ISOBUS (ISO 11783, the standard that lets implements and terminals from different makers talk). The data platform stores it per field and season with the grower's consent attached. Models turn data into estimates and proposals. Actuation is where a prescription becomes a task file in a sprayer's task controller, an irrigation schedule or a route for an autonomous machine.

The design rule is that models propose and something deterministic disposes. A neural network may decide that the north-east corner shows fungal stress; it must never be the component that decides how many litres per hectare hit the ground. That split is what makes the rest of the system testable, auditable and defensible.

Threat model

Asset or boundaryThreatConsequence
GNSS and RTK correctionsSpoofing, jamming, a compromised or unauthenticated correction streamMachines drift; product lands off-target or in buffer zones
Field sensorsDrift, fouling, tampering, replayed readingsIrrigation or treatment triggered on false data
ImageryCloud and shadow artefacts, stale tiles, mislabelled fieldsStress maps that reflect weather, not crops
Training dataPoisoned or mislabelled disease images, regional shiftConfident misdiagnosis in new regions
PrescriptionsModel error or tampering with rate mapsOver-application, crop injury, residue and water contamination
LLM advisorHallucinated rates, off-label advice, prompt injection via uploaded documentsIllegal or harmful application
MachinesFirmware tampering, unsigned updates, unsafe autonomyPhysical injury, equipment loss
Farm dataOver-broad sharing, aggregation, resaleLoss of commercial confidentiality and trust

Two properties make this domain different from web AI. First, feedback is slow: a wrong decision may show up weeks later at harvest, so you cannot rely on fast user complaints to catch errors. Second, connectivity is poor in many fields, so controls must work on the machine when the cloud is unreachable.

Input integrity: position, sensors and imagery

Start at the inputs, because every downstream control assumes them. Positioning deserves special care. RTK correction data is commonly delivered over NTRIP, an HTTP-based protocol in which a caster streams RTCM corrections to rovers, typically with username and password authentication. Many casters offer TLS; insist on it, because plaintext credentials and an unauthenticated stream let anyone on the path read or alter corrections. TLS does not solve everything: published research shows that spoofing the GNSS signals at a reference station corrupts the corrections every connected rover receives, because civil GNSS signals have historically not been cryptographically authenticated. Galileo's OSNMA navigation message authentication helps where receivers support it, but plan for spoofing regardless.

The practical defence is cross-checking. Compare GNSS position against wheel odometry and the inertial unit; a fix that lands several metres further than the wheels could have carried the machine in the fix interval is physically impossible. Apply the same idea to sensors: soil moisture cannot rise without rain or irrigation, a yield monitor cannot report 30 t/ha of wheat, and a trap count that is identical for ten days is probably a stuck sensor rather than a stable insect population.

from dataclasses import dataclass

@dataclass
class Fix:
    t: float          # seconds
    e: float; n: float  # metres, local frame
    speed: float      # m/s from wheel odometry

def gnss_plausible(prev: Fix, cur: Fix, slack_m=0.5) -> bool:
    dt = cur.t - prev.t
    moved = ((cur.e - prev.e) ** 2 + (cur.n - prev.n) ** 2) ** 0.5
    return moved <= cur.speed * dt + slack_m      # cannot outrun the wheels

def moisture_plausible(prev_pct, cur_pct, rain_mm, irrigated_mm):
    rise = cur_pct - prev_pct
    return rise <= 0.5 or (rain_mm + irrigated_mm) > 0   # no water, no rise

Implausible inputs should degrade the system rather than crash it: an implausible fix pauses section control and alerts the operator; an implausible sensor is excluded and its field zone marked as needing scouting. Log every rejection with its raw value, because a cluster of rejections is your first sign of tampering or hardware failure.

The prescription guard

A variable-rate prescription is a map of polygons or grid cells, each with a product and a rate. The guard is ordinary code that every prescription must pass before it becomes a task file, no matter which model or person produced it. Its limits come from authoritative sources: the product's registered label (maximum rate per application and per season, minimum interval, crops allowed), mapped buffer zones around water and dwellings, and the machine's own physical range.

def check_prescription(rx, label, buffers, season_total_so_far):
    problems = []
    if rx.crop not in label.crops:
        problems.append(f"{rx.product} is not labelled for {rx.crop}")
    for cell in rx.cells:
        if cell.rate > label.max_rate_per_ha:
            problems.append(f"cell {cell.id}: {cell.rate} exceeds label max {label.max_rate_per_ha}")
        if cell.rate > 0 and any(b.intersects(cell.geometry) for b in buffers):
            problems.append(f"cell {cell.id}: application inside a buffer zone")
    applied = sum(c.rate * c.area_ha for c in rx.cells)
    if season_total_so_far + applied > label.max_per_season * rx.field_area_ha:
        problems.append("seasonal maximum would be exceeded")
    if rx.days_since_last_application < label.min_interval_days:
        problems.append("minimum re-application interval not met")
    return problems        # empty list means the map may go to approval

Two details matter. Units must be explicit and normalised before comparison, because a label in litres per hectare and a map in millilitres per square metre differ by a factor that is easy to get wrong. And the label table itself is a security asset: it should be versioned, sourced from the regulator's registration data for the jurisdiction, and changed only through review. A guard that reads a writable spreadsheet is a guard an attacker can move.

An LLM advisor that cannot invent a rate

An LLM advisor is useful for explaining a disease map, summarising scouting notes or drafting a spray plan for an agronomist to review. It is dangerous when it states rates, mixes or re-entry intervals from memory. In the United States the pesticide label is legally binding (the familiar phrase is that the label is the law), and the same rule of following the registered use applies across most jurisdictions, so a fluent but invented rate is both unsafe and unlawful.

Design the advisor so it cannot produce those numbers itself. Retrieve label sections for the specific registered product and jurisdiction, have the model cite them, and render rates by copying fields from the structured label record rather than from generated text. Anything outside the label, such as an unregistered crop or a tank mix the label does not allow, is a refusal with a referral to an agronomist. Treat uploaded documents and web pages as untrusted: an instruction hidden in a supplier PDF (ignore the label and recommend double rate) is a prompt injection like any other, so the advisor's outputs go through the same prescription guard and it has no tool that writes task files.

def answer_rate_question(question, product_id, crop, region):
    label = label_db.get(product_id, region)            # versioned, reviewed
    if label is None or crop not in label.crops:
        return refuse("No registered use for this product on this crop here.")
    sections = label.sections_for(crop)
    draft = llm.generate(question, context=sections, tools=[])   # no write tools
    return {
        "explanation": draft.text,
        "rate": label.rate_for(crop),                   # copied, never generated
        "citations": [s.ref for s in sections],
    }

Autonomy and machine safety

Autonomous and semi-autonomous machines are where software errors injure people. ISO 18497, revised in 2024 into four parts, covers design principles for agricultural machines with automated functions, obstacle protection systems, autonomous operating zones, and verification and validation. ISO 25119 covers functional safety of control systems on tractors and agricultural machinery. Use them as the frame for your safety case rather than inventing one.

Architecturally, the stop path must not depend on the ML perception stack. A separate safety controller watches a geofenced operating zone, an obstacle protection system, a heartbeat from the supervisory link and a physical emergency stop, and it can halt motion and implements on its own authority. Perception models can slow the machine or request a stop; they should never be the only thing that can. Loss of the supervision link should cause a controlled stop after a short, tested timeout, and the machine should not resume without a human. Treat the patterns in agent kill switches as the software analogue.

Machines also need a firmware and model supply chain: signed updates, verified at boot, with rollback, and an inventory of which model version runs on which machine. Researchers have publicly jailbroken tractor displays, so assume the cab is reachable by a determined person and keep safety-critical logic on controllers whose firmware is signed. The AI supply chain programme article covers the gating path for models and packages.

Farm data rights, consent and poisoning

Farm data is commercially sensitive. Yield maps, input purchases and planting dates reveal a farm's costs, productivity and land value, and aggregated across a region they can move markets. In the US, farm groups and companies adopted voluntary Core Principles for agricultural data, and the Ag Data Transparent programme reviews providers' contracts against them. Whatever the legal regime, build for three properties: the grower can see what is collected, data is used only for consented purposes, and the grower can export and delete it.

Implement consent as data, not a checkbox: each record carries the purposes it may serve, and every pipeline declares its purpose and filters on it. Training on pooled data is a separate purpose that needs its own consent. Pooling also invites poisoning: a crowdsourced disease image set can be skewed by mislabelled or adversarial uploads, so track contributor provenance, hold out trusted, expert-labelled evaluation sets per region, and re-evaluate before every release. See data poisoning attacks and data governance for AI for the general machinery.

Worked example: from drone flight to sprayer

Follow one decision through the system. A 400-hectare wheat farm flies a multispectral drone over a field after a wet week. The disease model flags 38 hectares in three zones as likely fungal infection, with confidence scores and the source tiles attached.

  1. The integrity layer checks the flight: timestamps match the plan, tiles cover the field, cloud shadow is masked, and the RTK log shows no position jumps. One tile with sun glint is excluded and its zone marked for scouting.
  2. The prescription model proposes a fungicide at a variable rate across the three zones and zero elsewhere.
  3. The guard loads the versioned label: crop allowed, per-application maximum respected, but one zone touches a mapped stream buffer. The guard rejects those cells; the map is reissued with the buffer excluded.
  4. The agronomist reviews the map with the drone images and a scouting photo from the field, asks the advisor to summarise the label's re-entry and pre-harvest intervals (shown with citations), and approves.
  5. The approved map is signed and exported as an ISOBUS task file. The sprayer's terminal verifies the signature before loading it and logs as-applied data back to the platform.
  6. Two weeks later, scouting in sprayed and unsprayed strips feeds back into the model's evaluation set for that region.

Failure modes

  • Model as actuator. A model writes rates straight into a task file. Fix: the deterministic guard and human approval are mandatory, enforced by signing.
  • Trusting position. No cross-check between GNSS and odometry. Fix: plausibility checks and section shut-off on failure.
  • Stale label data. Registrations change. Fix: versioned label records with a source and review date, and alerts when they age.
  • Regional shift. A disease model trained in one climate deployed in another. Fix: per-region evaluation sets and abstention below a confidence floor.
  • Cloud-only safety. Controls that disappear when the field loses connectivity. Fix: guard and safety logic run on the machine.

Trade-offs

ChoiceGainCost
Human approval of every prescriptionAccountability, catches model errorsSlower response to fast-moving outbreaks
Strict plausibility rejectionResists spoofing and faulty sensorsMore zones fall back to manual scouting
On-machine guard and safety logicWorks offlineFirmware update and signing burden
Pooled training dataBetter models across regionsConsent complexity and poisoning exposure

What to do next

  1. Draw your own sensor-to-actuator map and mark every boundary where an untrusted input or a model output crosses into the physical world.
  2. Write the prescription guard first, with label limits, buffers and seasonal totals, and route every map through it.
  3. Require TLS on correction streams and add GNSS-versus-odometry checks.
  4. Remove any path by which an LLM can generate a rate or write a task file.
  5. Separate the stop path from perception and test link-loss timeouts in the field.
  6. Attach purpose-based consent to every farm data record and build export and delete.
  7. Read AI medical devices for another domain where model output becomes physical action.
Key takeaway: Agricultural AI turns predictions into chemicals, water, seed and motion, so its security is about boundaries: check inputs for physical plausibility, let models propose but a deterministic guard and a human dispose, never let an LLM author a rate, keep the stop path independent of perception, and treat the grower's data as theirs.