AI in Maritime, in depth: spoofed GNSS and AIS, injected port documents, OT boundaries and the MASS Code

Where AI sits in a shipping operation

Start by drawing the system the way an attacker sees it. A typical deployment has four zones:

• Radio inputs. GNSS position and time, AIS reports and NAVTEX messages. None is authenticated in civil use; a transmitter ashore can produce reports that look exactly like real ones.
• Own-ship sensors. Radar, cameras, gyrocompass, speed log and echo sounder. Harder to forge remotely, so they are the reference you check radio inputs against.
• Business inputs. Email from agents and port authorities, port information PDFs, cargo manifests. This is where an LLM spends most of its time, and every document is attacker-controllable.
• Operational technology (OT). ECDIS, autopilot, engine and ballast control: the zone where a mistake moves steel.

The rule that falls out of the diagram: AI components may read from OT through a one-way export, and may advise people, but in a crewed ship they do not write to OT. Autonomous vessels change the last part, which is why they need a safety case rather than a feature list.

Threat model

Name the attacker's reach, not just the attack: most never touch the ship's network.

The last row matters: an assistant that states a conclusion fluently, without naming its inputs, quietly removes the bridge team's cross-checking habit.

GNSS and AIS are untrusted inputs

GNSS and AIS were designed for cooperation, not for adversaries. GNSS spoofing and jamming affecting ships has been widely reported in recent years, and AIS carries no authentication at all: the position, identity (MMSI) and voyage fields are whatever the transmitter sends. An AI system that consumes these values directly inherits that weakness, and a learned model can amplify it by reacting confidently to an impossible track.

The defence is a plausibility gate in front of every consumer. It never corrects the input; it attaches flags that downstream components and humans can see. Checks that need no special hardware:

• Own position: compare GNSS with dead reckoning from gyro heading and speed log since the last trusted fix; a jump larger than sensor error is suspect.
• Target tracks: the speed implied by two successive AIS positions must not exceed what the vessel type can do, and course changes must be physically possible.
• Identity: an MMSI for a ship station has nine digits and its first three (the maritime identification digits) should map to a real flag; the same MMSI in two places at once is a red flag.
• Correlation: an AIS target inside radar range with no matching radar return, or a radar return with no AIS, is shown to the watch, not resolved by the model.

import math
from dataclasses import dataclass, field

EARTH_NM = 3440.065  # Earth radius in nautical miles

def dist_nm(lat1, lon1, lat2, lon2):
    p1, p2 = math.radians(lat1), math.radians(lat2)
    dp, dl = p2 - p1, math.radians(lon2 - lon1)
    a = math.sin(dp / 2) ** 2 + math.cos(p1) * math.cos(p2) * math.sin(dl / 2) ** 2
    return 2 * EARTH_NM * math.asin(math.sqrt(a))

@dataclass
class Report:
    mmsi: str
    t: float          # seconds, receiver clock
    lat: float
    lon: float
    flags: list = field(default_factory=list)

MAX_KNOTS = 45.0      # generous ceiling for merchant traffic; tune per area

def gate(report, last_seen, positions_now):
    """Attach flags; never modify the position itself."""
    if not (report.mmsi.isdigit() and len(report.mmsi) == 9):
        report.flags.append("mmsi_format")
    prev = last_seen.get(report.mmsi)
    if prev and report.t > prev.t:
        hours = (report.t - prev.t) / 3600
        knots = dist_nm(prev.lat, prev.lon, report.lat, report.lon) / hours
        if knots > MAX_KNOTS:
            report.flags.append(f"implied_speed_{knots:.0f}kn")
    for other in positions_now.get(report.mmsi, []):
        if dist_nm(other.lat, other.lon, report.lat, report.lon) > 5:
            report.flags.append("duplicate_mmsi")   # same identity, two places
    last_seen[report.mmsi] = report
    return report

The gate's job is to make sure a spoofed input reaches the assistant and the officer already labelled, so the answer can say the track was flagged instead of presenting a phantom ship as fact.

Prompt injection through port-call documents

The LLM component most ships will meet first is not autonomy; it is an assistant that reads port information, agent emails, charter party clauses and manuals. Every one of those is text written by someone outside the company. If the assistant can also act, for example by drafting and sending replies, updating a voyage plan in the fleet system, or looking up crew records, then a sentence hidden in a PDF can try to steer it. AIS adds a small, odd channel: the voyage message carries a short free-text destination field that any transmitter can fill.

Controls that work:

1. Separate instructions from data. Untrusted documents enter the context inside clearly marked blocks, and the system prompt states that text inside them is content to analyse, not instructions. This lowers the hit rate; it does not make injection impossible.
2. Gate tools by provenance. When untrusted text is in the context, tools with side effects require a human confirmation that shows the exact action.
3. Least privilege per task. A port-call summariser needs no email-send or crew-record access; give separate assistants separate credentials.
4. Log the context. Store which documents were in the window for each answer so that an odd recommendation can be traced back to its source.

SIDE_EFFECT_TOOLS = {"send_email", "update_voyage_plan", "book_service"}

def call_tool(name, args, context, confirm):
    tainted = any(block.source == "external" for block in context.blocks)
    if name in SIDE_EFFECT_TOOLS and tainted:
        summary = f"{name}({args}) after reading: " + ", ".join(
            b.origin for b in context.blocks if b.source == "external")
        if not confirm(summary):           # a person sees the action and its inputs
            return {"status": "refused", "reason": "needs human approval"}
    audit_log(name, args, [b.digest for b in context.blocks])
    return TOOLS[name](**args)

The OT boundary and the E26/E27 baseline

New ships carry a hard baseline for the network side. The IACS unified requirements E26 (cyber resilience of the ship) and E27 (cyber resilience of on-board systems and equipment) apply to ships contracted for construction on or after 1 July 2024. E26 works through identifying assets, protecting them, detecting attacks, responding and recovering; E27 places security requirements on the equipment suppliers. In the United States, the Coast Guard's final rule on cybersecurity in the marine transportation system, published in January 2025, adds plan and officer requirements for covered vessels and facilities on a phased schedule.

For an AI component, the practical consequences are architectural:

• Place the assistant on the IT side. Feed it OT data through a one-way export (a data diode or a read-only replica), never a bidirectional connection into the integrated bridge network.
• List the model server, weights and retrieval index in the asset inventory, and ship updates as signed, forward-only bundles; a USB stick at port is delivery, not trust.

Designing for satellite links that drop

Satellite links vary with weather, region and contract, and a design that assumes a cloud model is always reachable fails mid-ocean. An attacker who can jam the link can force the degraded mode, so the degraded mode must be safe.

• Run a small on-board model for core tasks and use a larger shore model when the link allows; tag which one answered.
• Show staleness explicitly: weather, notices and regulations retrieved before the link dropped are labelled with their age.
• For remotely operated vessels, define the fallback in the safety case: what the ship does when the remote operation centre loses contact, and how long it may continue.

Human oversight, the MASS Code and safety cases

The IMO adopted a goal-based Code for Maritime Autonomous Surface Ships (the MASS Code) at the Maritime Safety Committee's 111th session in May 2026. It is non-mandatory to begin with; the roadmap foresees a mandatory version entering into force on 1 January 2032 after an experience-building phase. Earlier summaries that put mandatory rules in 2028 are out of date. Being goal-based, it prescribes no algorithm; you must show that functions a crew performed are still performed safely.

In engineering terms that means a safety case: a structured argument, with evidence, that the autonomous functions are acceptably safe in a defined operating envelope. The AI-specific evidence a safety case needs:

• The operating envelope: sea areas, traffic density, visibility and sea states the perception system was tested in.
• Behaviour under degraded inputs: spoofed GNSS, false AIS targets, camera glare, radar clutter.
• Handover: how the system detects that it is out of its envelope and transfers control to the remote operation centre or the crew, with measured handover times.

Worked example: a phantom tanker in a busy strait

Consider a fleet operator that runs a voyage-planning assistant ashore and a read-only copy on board. The officer asks it to check the planned passage through a busy strait for the next six hours. Traffic comes from the ship's AIS receiver and a commercial AIS feed. Here is how a false track plays out, with and without the controls above. The scenario is illustrative.

1. A transmitter ashore broadcasts position reports for a vessel using an MMSI copied from a real tanker that is actually in another sea. The fake track crosses the planned route.
2. Without a gate, the assistant sees a crossing tanker and recommends delaying entry by forty minutes. A more dangerous variant hides a real ship by mixing false reports under its MMSI.
3. With the gate, the commercial feed shows the same MMSI over 300 nm away, so the reports get duplicate_mmsi. The separate radar-correlation check finds no return at the reported position and marks the target as uncorrelated.
4. The assistant's answer names its inputs: "one crossing target, flagged as implausible (duplicate identity, no radar return); recommend visual and radar confirmation before altering the plan".
5. The officer confirms there is no ship. The flags and the raw reports go into the incident log and are reported under the company's cyber procedures.

The model did not decide the target was fake; the gate and the radar established that, and the model carried it into the advice.

Failure modes

• Silent correction. A filter that replaces a suspicious GNSS fix with dead reckoning hides the attack from the crew. Flag, show, and let a person choose.
• Over-flagging. If the gate fires on every noisy target, the watch learns to ignore it. Tune thresholds per area and measure the false-alarm rate.
• Flags lost in summarisation. The model drops the warning to produce a cleaner answer. Test for this explicitly and fail the release if flagged inputs are not mentioned.
• Shore centre over-trust. Remote operators watching many ships rely on the autonomy summary; if it hides input flags, the human in the loop is not really in it.

Trade-offs

What to do next

1. Draw your AI components on a diagram with the four zones above, and mark every input as trusted or attacker-controllable.
2. Put a plausibility gate in front of GNSS and AIS consumers that flags, logs and never corrects.
3. Make every assistant answer cite its inputs and their flags; add a release test that fails when a flagged input is not mentioned.
4. Remove write paths from assistants into OT; use a one-way export for the data they need.
5. Split assistants by task, give each its own credentials, and require human confirmation for side-effect tools when external documents are in context.
6. Add model servers, weights and indexes to the asset inventory you keep for E26, with signed, forward-only updates.
7. If you are planning remote or autonomous operation, start the safety case now and align it with the MASS Code's goal-based structure.
8. Keep learning: attacks on learned driving stacks, spotlighting against prompt injection, tracing an injection back to its payload and securing model infrastructure.