Who Protects the Driverless Train?

A train leaves the platform without a driver at the front. To a passenger, the system can feel almost magical. To a security professional, it raises a practical question: if computers help move the train, what prevents a digital problem from becoming a physical one?

Japan offers a real-world starting point. The answer involves several kinds of technology, rather than a single chip in charge of everything.

This is a forward-looking explainer, not an incident report. The sources reviewed do not establish an AI-enabled takeover of a Japanese monorail or driverless train. The scenarios below are hypothetical.

First, which kind of train?

Tokyo’s Yurikamome is an automated, rubber-tired transit system. Its operator distinguishes it from a monorail: a monorail follows a single supporting beam, while Yurikamome’s vehicles run on a dedicated guideway using rubber tires. Calling every elevated automated train a monorail confuses physical design with degree of automation. Yurikamome explanation

• What supports and guides the vehicle: a monorail beam, an automated-transit guideway or conventional rails?
• Which driving tasks are automated?
• What must staff still do, on board and elsewhere?

JR East’s framework distinguishes GoA2, with a driver at the front; GoA3, with crew aboard but no requirement to be at the front; and GoA4, with no crew aboard. These describe operational responsibility, not how intelligent an AI model is. JR East automation plan

Three responsibilities, different consequences

This is an educational model, not a diagram of any particular operator’s network:

1. Passenger and business IT. Websites, customer accounts, ticketing and information services serve passengers and the organization. A compromise can expose data or disrupt travel without establishing control of a train.
2. Operational control. Systems coordinate service and perform driving tasks. Yurikamome describes automatic train operation, or ATO, coordinating station stops and doors, with its central command office monitoring operations and able to prevent departure when needed. Operator system overview
3. Safety protection. Train-protection functions constrain unsafe movement and need a safety argument of their own. Yurikamome describes layered, fail-safe equipment, automatic train control and train detection, with continuous control-room oversight. Operator safety FAQ

ENISA’s railway guidance describes grouping assets into security zones and controlling communication according to risk. A public-facing service and a safety-related function should not acquire the same trust simply because both belong to a railway. ENISA architecture guidance

Nor should readers assume boundaries are perfect. Establishing the necessary independence of safety protections requires engineering evidence, including assessment of shared dependencies. A generic illustration cannot certify a railway.

A protective stop is different from a takeover

Safety engineering aims to keep failures from creating unacceptable hazards. Cybersecurity also considers deliberate interference. The disciplines need to work together.

NIST’s operational-technology guidance describes fail-safe behavior as moving equipment or a process into an appropriate safe state. Lost communication can trigger that response. The correct state depends on the system and its hazards; it is not a universal instruction to switch everything off. NIST OT guide

Disruption, precautionary suspension and an attacker gaining authority over movement are different claims requiring different evidence. An outage alone does not demonstrate that safety protections were defeated.

Disruption can still be serious. Passenger assistance, clear announcements and safe recovery belong in the conversation alongside technical containment.

Where AI could change the picture

Computer-controlled trains existed long before generative AI. An automatic driving system should not be imagined as a chatbot improvising its way along the track.

Japan’s Railway Technical Research Institute reports prototype tests of a more autonomous operating system, including stopping for a detected obstacle and resuming after its removal. These demonstrations took place on its test track. They are research evidence, not proof that every Japanese passenger railway uses the same technology. RTRI research summary

AI changes the discussion in two ways: adversaries can use it, and organizations can introduce it into workflows. The UK’s NCSC assesses that AI will make parts of intrusion more efficient and effective, largely by enhancing existing techniques. This is a broad assessment, not a finding about a Japanese railway. NCSC assessment through 2027

Consider three hypothetical situations:

• A convincing false request. An AI-assisted message impersonates a supplier and urges rushed maintenance approval. Does independent verification establish identity and authority, beyond polished wording?
• An unreliable AI assistant. A future maintenance copilot gives a confident but incorrect recommendation or is influenced by untrusted material. Check its output against approved procedures and tightly limit its authority.
• Untrustworthy inputs. A future AI-supported monitoring system receives inaccurate or manipulated data. Designers need to recognize uncertainty and maintain appropriate safety constraints rather than treating confidence as proof.

These are design questions, not allegations about named operators. NCSC calls for security throughout AI design, development, deployment and operation, including the supply chain. Secure AI guidance

What deserves attention now

Japan’s transport ministry revised its railway information-security safety guidelines to a sixth edition on April 22, 2026. Their stated purpose is to guide safeguards and continuing improvement. This is a policy framework, not certification that every system is secure. MLIT railway guidance

• Separate responsibilities and trust. Define security zones around assets and risks. Permit only necessary communication across boundaries. ENISA
• Make maintenance accountable. Restrict and monitor remote access, authenticate authorized parties and support disabling access without compromising operations. Coordinate testing and patches with vendors, using additional safeguards where patching must wait. NIST
• Connect safety and recovery. Review security changes for operational effects. Plan response and restoration around people, reliability and the physical process, not only an IT dashboard. NIST
• Bound AI’s role. Identify what it can recommend, what it can change and who remains accountable. Secure dependencies and monitor it throughout its life. NCSC

Who protects the driverless train?

People still do: engineers designing and testing protections, operators overseeing service, maintainers controlling changes and security teams watching for misuse. Automation changes where work happens and what evidence it requires.

If one component becomes unreliable or compromised, what prevents failure from spreading, and how will the operator restore service safely? Japan’s driverless railways make the question easy to visualize. Answering it requires more than a clever computer.

Read the companion analysis of Japan’s AI-assisted cyberattacks for what investigators have established about attacks on web services. Those incidents do not establish a train takeover.