UR E26/E27 made cyber resilience a surveyed requirement — but didn't supply the SOC. The newbuild now has the hardened network, the logging, the incident-response plan on paper — and a crew of engineers and officers with no security operations team to read the alerts. That gap is where the pitch for an LLM security assistant lands: a model that watches the logs, explains the anomaly in plain language, and guides a non-expert through a response.
It is one of the more plausible LLM-aboard applications — and one of the more dangerous if done badly. This article evaluates it honestly.
Key findings
- The need is structural: regulated cyber resilience + no aboard SOC + a crew without security training — a real capability gap. Established
- LLMs are demonstrably useful for <em>explaining</em> technical findings and <em>guiding</em> procedures — the exact gap a crew without security training has. Research demonstration
- The same capability that explains an alert can <em>hallucinate</em> an interpretation — a wrong diagnosis aboard can be worse than none. Established
- Aboard LLMs are unproven in production; the verified work is on diagnostic/triage roles, not autonomous security action. Research demonstration
- The safe architecture is advisor-not-actor: read logs, explain, recommend, never execute — matching the agentic-diagnostics pattern already validated aboard. Maritime-GPT analysis
The gap the pitch fills
The regulatory arithmetic doesn't work without help. UR E26/E27 demands detection, logging, response — functions an enterprise provides with a security operations centre. A merchant ship has 20 people, no SOC, and satellite bandwidth. Something must watch the alerts and translate them for a non-expert. An LLM is the obvious candidate precisely because its core skill — fluent explanation — is the skill the gap is made of. Established
What the role can safely be
- <strong>Alert triage and plain-language explanation.</strong> 'This log pattern resembles X; the recommended check is Y' — summarisation and translation are exactly what LLMs demonstrably do well. Research demonstration
- <strong>Guided response.</strong> Walking the crew through the incident-response checklist UR E26 requires — procedure-following is a documented strength. Research demonstration
- <strong>Query interface to security data.</strong> The agentic pattern — LLM that calls tools to fetch logs and status, never acts on them — is the validated architecture from marine-engineering diagnostics. Research demonstration
- <strong>Never autonomous action.</strong> Blocking a port, isolating a system, rebooting a controller — the safety-critical actions must stay gated behind a human and, ideally, shore confirmation. Maritime-GPT analysis
The hallucination problem aboard
The LLM's fluent-confidence failure mode is the safety problem. An assistant that explains a false anomaly as a real attack teaches the crew to distrust it; one that explains a real attack as noise is worse. The mitigations are the same as in our SLM and diagnostics pieces: retrieval-grounded answers, constrained outputs, uncertainty flags, and — the key aboard safeguard — a model small enough to run on shipboard hardware so it works when the satellite link doesn't. Maritime-GPT analysis
The architecture the evidence supports
Maritime-GPT synthesis — LLM as translator and advisor between the detection layer and the crew, never as the actuator. Maritime-GPT analysis
What we know
- The aboard capability gap (regulated resilience, no SOC) is real and structural.
- LLM explanation/triage abilities are demonstrated in analogous diagnostic roles.
- Advisor-not-actor is the only architecture consistent with the safety case.
What we don't
- A validated aboard deployment of an LLM security assistant.
- How crews calibrate trust in an LLM that can be fluently wrong about a security event.
- Whether shipboard SLMs are good enough for the reasoning the role needs.
Being tested
- Retrieval-grounded assistants on real vessel logs (testbed).
- Offline-capable small models for unlinked operation.
- Human-factors evaluation of LLM security guidance under stress.
Maritime-GPT analysis
This is one of the most defensible LLM-aboard applications — because the role is advisor, not actor, and the skill required (explanation) is the skill LLMs demonstrably have. The risk is the same as everywhere: confidence without correctness. The safeguard that makes it honest is the same: keep the human in authority, ground the model in retrieved facts, and size it small enough to run when the link fails. Maritime-GPT analysis
This is a research feature, not operational guidance. Simulation results are reported as simulation; demonstrations are not deployments; company claims are attributed as such. Verify safety-critical decisions against official nautical publications and flag-state requirements.
Sources & evidence
The regulation that creates the aboard capability gap the assistant fills.
The advisor-not-actor architecture the cyber assistant should copy.
The offline-compute constraint the assistant must satisfy.