Maritime AI Cybersecurity: How Shipping Lines Govern the New OT Attack Surface

Shipping lines deploying AI are creating a new category of cyber risk, and most of them have not updated their security governance to account for it. The problem is not that AI systems are inherently insecure. The problem is that AI systems in production depend on data feeds, APIs, and network-connected sensors that were never designed to be security perimeters, and nobody gave the AI team a security brief before deployment.

The consequence: every new production AI system is also a new attack vector, and the attack surface is growing faster than the governance frameworks meant to contain it.

The numbers behind the risk

The U.S. Coast Guard's 2026 maritime cybersecurity report is a useful benchmark: maritime cyber incidents rose 17% year-over-year, and operational technology (OT) systems featured in 62% of those incidents. Edge devices (routers, firewalls, VPNs) saw an 800% increase in attacks. These are not IT systems inside an office. They are the systems controlling navigation, cargo handling, and vessel communications.

BIMCO's August 2026 survey found that 60% of newly disclosed software vulnerabilities in ship and onshore systems were weaponized within 48 hours. AI-assisted attackers are scanning for vulnerabilities and exploiting them faster than most security teams can patch them.

One 2026 incident illustrated the systemic risk clearly: a hacktivist group disconnected 116 tankers from internet connectivity by compromising a connectivity provider and wiping VSAT partitions. No individual vessel security failure was required. The attack succeeded at the infrastructure layer that every vessel depended on.

These incidents predate the wide deployment of AI systems on vessels. As AI systems proliferate, the attack surface expands further, because AI systems in maritime operations have specific dependencies that create specific vulnerabilities.

What makes maritime AI different from IT security

Most shipping lines treat cybersecurity as an IT problem: patch the servers, train the crew on phishing, segment the OT network. That framework was adequate for the previous generation of marine systems. It is not adequate for AI systems in production.

The three characteristics that make maritime AI systems a distinct security challenge:

Data dependency. Vessel AI systems consume AIS feeds, port data, weather data, cargo manifests, and sensor telemetry from equipment built over decades to different standards. A freight rate forecasting model depends on live exchange data feeds. An ETA prediction model depends on AIS position signals. Corrupt or spoof those inputs and the model's outputs become unreliable, or worse, confidently wrong. The January 2026 GPS spoofing events near the Port of Long Beach (seven vessels reported GPS outages, with AIS tracks showing erroneous speeds of 100+ knots) illustrate what this looks like in practice. Any AI system using those AIS signals downstream was receiving garbage.

OT integration. AI systems for vessel optimization and port operations communicate with or receive signals from OT systems: cargo handling equipment, navigation systems, fuel monitoring. The boundary between AI inference output and operational decision-making is thinner in maritime than in most other industries. A routing recommendation from an AI system influences bridge crew decisions in real time.

Third-party connectivity. AI systems require regular updates, model retraining, and data pipeline maintenance. That means external connectivity to cloud infrastructure, API endpoints, and vendor systems. Each of those connections is a potential entry point. Shipping lines that would never allow a vendor direct network access to navigation systems are routinely allowing AI vendors similar access through data pipelines.

The governance gap

The security question most shipping lines have not answered is: who is responsible for the security posture of each AI system in production, and what does "secure" mean for that system?

This is not a rhetorical question. In most shipping organizations, the IT security team owns network security and OT security owns vessel systems. The AI team owns model performance. Nobody owns the intersection. When an AI system's input data feed is compromised, or when an API key for a production system is leaked in a model artifact, the accountability is unclear.

The governance framework needs to close three gaps:

1. Inventory every AI system's data dependencies. For each AI system in production, document what data it consumes, where that data comes from, who controls the data source, and what happens to the model's outputs if that data is corrupted or delayed. This is the maritime AI equivalent of a data flow diagram, and it is required for any realistic threat modeling.

2. Define degradation behavior for each system. An ETA prediction model that receives spoofed GPS data should have a defined behavior: flag the anomaly, fall back to a less-accurate but tamper-resistant data source, or alert the operator rather than issuing a prediction based on corrupt inputs. Most AI systems deployed in maritime operations do not have defined degradation behavior. They were built to be accurate, not to be resilient.

3. Extend vendor security reviews to AI data pipelines. If a maritime AI system consumes data from a third-party provider, the security review of that provider should be as thorough as the review of any other third-party software. API keys, data feed contracts, access controls, and incident response obligations all need to be in scope. For shipping lines deploying multiple AI systems, this is where governance at scale (similar to what internal auditors apply to control environments) becomes necessary.

What production governance looks like

At a tier-1 global container carrier, deploying 15+ agentic workflows means governing 15+ sets of data dependencies, API connections, and OT interfaces simultaneously. The governance model that works at that scale is not a checklist. It is an ongoing audit capability applied to AI systems the same way it applies to financial controls: continuous monitoring, evidence collection, and documented findings when a system behaves outside expected parameters.

That is why the AI governance and maritime operations questions converge in production. Shipping lines that treat AI governance as a security project will solve the immediate vulnerability inventory problem. Shipping lines that treat it as an ongoing operational audit will maintain it as the AI footprint grows.

The BIMCO AI security advisories and DNV's 2026 AI risk guidance both point in the same direction: the security governance frameworks that covered the last generation of digital systems need to be extended, not retrofited, for AI. The extensions require new thinking about data integrity, model degradation behavior, and third-party AI vendor accountability. The shipping lines deploying production AI systems now are writing those frameworks by necessity. The ones waiting will inherit the vulnerabilities.