Cylus.ai Rail Cybersecurity Adds AI Agents, but Keeps Operators in Control
Cylus launched Cylus.ai rail cybersecurity on September 16, introducing agentic analysis while keeping a human approval step before critical actions. The product arrives with a specific promise: help small security teams interpret rail operational technology without replacing their existing tools or operational authority.
The announcement is more consequential than another cybersecurity vendor adding a conversational assistant. Cylus.ai is designed to investigate alerts, assemble evidence, map compliance controls, and draft responses across safety-sensitive rail environments. That places the system between security data and decisions affecting signaling, stations, onboard networks, and maintenance access.
Cylus also appointed three former transit leaders to its advisory board. Nuria Fernández previously led the U.S. Federal Transit Administration. Josef Doppelbauer headed the European Union Agency for Railways, while Mario Péloquin most recently led VIA Rail Canada. Their arrival gives the launch regulatory and operating credibility, but it does not validate the product’s performance.
The central contest is therefore not Cylus against another named vendor. It is rail-specific agentic intelligence against generic security automation that lacks operational context. Cylus says its system can close that gap. Rail operators must now determine whether its recommendations are accurate, explainable, and safe under real operating pressure.
Cylus.ai Rail Cybersecurity Sits Above Existing Security Tools
Cylus is selling an intelligence layer, not a replacement security stack.
Cylus introduced the platform at InnoTrans 2026 in Berlin, alongside demonstrations of CylusOne, its established rail-security product. According to the company’s launch announcement, Cylus.ai works above the tools an operator already uses.
That architectural choice matters. Rail networks often combine modern security products with aging controllers, specialized protocols, long-lived signaling equipment, and systems maintained by several vendors. Replacing that environment with one unified platform would be expensive, slow, and operationally risky.
Cylus.ai instead connects to security information and event management systems, endpoint detection products, firewalls, identity systems, asset inventories, and ticketing platforms. It can also query operational technology monitoring tools. Operational technology, or OT, includes the hardware and software that monitor or control physical railway processes.
The company presents CylusOne as the deepest integration point. CylusOne supplies network visibility and threat information, while the new agent interprets those observations and recommends a response. That moves Cylus from identifying suspicious activity toward influencing what an operator does next.
Its advertised virtual security operations center analyst can investigate alerts across onboard, wayside, and station networks. Cylus says the agent gathers asset context, protocol baselines, maintenance schedules, endpoint detections, and relevant firewall sessions before returning a verdict.
That distinction addresses a persistent weakness in generic alert automation. A remote desktop connection can be routine maintenance in one context and suspicious lateral movement in another. Its meaning depends on the asset, operating state, approved work, route configuration, and surrounding events.
The platform’s published demonstration describes an unusual command sent toward a wayside interlocking while a route remains locked. An interlocking is a safety system that prevents conflicting train movements. The example then correlates that command with an endpoint alert involving unexpected remote desktop activity.
Cylus.ai would assemble the evidence and draft a ticket rather than immediately changing the production environment. The company says a person must approve critical actions, including firewall, endpoint, ticketing, or configuration changes.
A second agent targets governance, risk, and compliance work. It maps controls from IEC 62443, European NIS2 requirements, and U.S. Transportation Security Administration directives against an operator’s environment. It can flag missing evidence and prepare remediation items with assigned owners.
Another advertised role evaluates rail architecture. The agent can review communications-based train control, positive train control, and European Rail Traffic Management System designs. It can also inspect segmentation models and identify network paths that bypass expected security boundaries.
These capabilities remain company claims. Cylus has not published independent accuracy measurements, customer results, benchmark comparisons, or failure rates for the new platform. The launch establishes the product’s intended design, not its operational effectiveness.
Still, the overlay model gives operators a practical starting point. It lets them evaluate agentic analysis without immediately discarding the monitoring, identity, and response products they already trust. That reduces adoption friction while preserving existing sources of evidence.
The larger change is conceptual. Traditional rail monitoring asks whether something unusual happened. Cylus.ai is designed to ask why it happened, what other evidence matters, and what response should be prepared. That is a substantial increase in responsibility, even when the final decision remains human.
Connected Rail Systems Have Outgrown Generic Alert Triage
The pressure comes from a mismatch between expanding connectivity and scarce rail-specific security expertise.
Rail operators are adding digital passenger services, remote diagnostics, connected rolling stock, predictive maintenance, and centralized traffic-management capabilities. These systems can improve reliability, but each connection creates another dependency that defenders must understand.
The resulting environment is not simply an enterprise network placed beside railway tracks. It includes systems where availability and predictable behavior carry safety implications. An aggressive containment action can interrupt maintenance, disable visibility, or push equipment into a restricted operating state.
Attackers do not need to manipulate train control directly to cause damage. Compromising administrative systems, vendor access, passenger information, scheduling, or maintenance operations can disrupt service and consume scarce response resources. Defenders must therefore connect cyber evidence with operating consequences.
This is where Cylus sees an opening for agentic AI. Agentic systems can pursue a defined task through several steps, choosing which tools or information sources to query before producing an answer. That differs from a basic chatbot responding only to a single prompt.
The company argues that attackers already use AI to increase their speed. However, it has not published evidence showing how much faster AI-enabled adversaries are against rail targets. The better-supported pressure point is the volume and complexity of evidence facing security teams.
Regulatory expectations are also becoming more concrete. The U.S. National Institute of Standards and Technology published its final transit security profile on August 5, 2026. The profile helps U.S. transit agencies prioritize cybersecurity outcomes across bus, commuter rail, subway, and related environments.
NIST designed the profile to complement existing programs, not replace them. That principle closely resembles Cylus’s product strategy. Both recognize that operators already work under established processes, regulations, and technical constraints.
European operators face a parallel demand for stronger governance. The European Union Agency for Cybersecurity identifies rail undertakings and infrastructure managers as essential entities under NIS2. Its transport guidance connects rising cyber exposure with IT and OT convergence across the sector.
Compliance does not remove the interpretation problem. A control framework can specify desired outcomes, but an operator must still determine which assets are affected, what evidence satisfies an auditor, and which remediation action is safe.
Cylus.ai attempts to automate parts of that translation. Its virtual compliance function reportedly associates requirements with actual assets, configurations, logs, and policies. If accurate, that could reduce manual evidence collection and expose controls that exist only on paper.
Security teams still need to test those mappings. Standards use terms that can require local interpretation, while railway architectures differ across countries, operators, and generations of equipment. An AI-generated control assessment cannot become authoritative merely because it cites the correct framework.
Generic security copilots also face this context problem. They can summarize an alert or recommend a common response, but rail environments punish assumptions. A network connection that looks obsolete may support a maintenance procedure tied to certified equipment and limited operating windows.
The commercial opportunity therefore rests on domain depth. Cylus is betting that knowledge of signaling, rolling stock, railway protocols, regulatory obligations, and maintenance practices will matter more than access to a general-purpose language model.
That strategy pressures broad security platforms to deepen their industrial knowledge. It also pressures traditional rail-security suppliers to add reasoning and workflow automation. Buyers will expect more than dashboards once agents can gather evidence and prepare a defensible response.
Yet deployment speed will depend on trust. Operators will want to know where the agent obtained each fact, why it selected a recommendation, and what it ignored. In rail, a plausible answer without traceable evidence is not enough.
Rail-Specific Context Is the Product’s Real Test
Cylus.ai succeeds only if domain context consistently improves decisions beyond what existing automation can provide.
The company’s public product material describes four central components: rail OT knowledge, a reasoning engine, persistent memory, and agentic workflows. Together, they allow the system to query connected tools repeatedly rather than delivering a one-step summary.
Consider an anomalous command involving a signaling asset. A conventional system may flag the command because it differs from a baseline. A rail-aware agent can theoretically examine the route state, maintenance schedule, asset role, authorized user, endpoint activity, and firewall session before judging the event.
That process resembles the work of an experienced analyst. The difference is speed and consistency. An agent can retrieve the same categories of evidence for every alert, document its steps, and prepare a standardized record for human review.
The approach also promises to preserve institutional knowledge. Experienced rail-security professionals understand which alarms commonly follow maintenance, which connections are exceptional, and which changes require operating approval. Encoding that knowledge could help smaller teams make more consistent decisions.
Persistent memory introduces both value and risk. An agent that remembers previous investigations can recognize recurring maintenance behavior and avoid repeating basic work. It might also preserve an incorrect assumption and apply it across later incidents.
Operators will need strict controls around what enters that memory, how long it remains, and who can correct it. They must also distinguish verified operational facts from analyst notes and model-generated conclusions.
Cylus says its system shows its reasoning, sources, and tool calls. It also says every action enters an audit log. Those features are essential because a security recommendation may later face operational, regulatory, or legal review.
However, showing intermediate reasoning does not guarantee correctness. A polished explanation can still rely on incomplete logs, stale topology, or a mistaken asset classification. Buyers should evaluate whether the cited evidence supports the conclusion, not whether the narrative sounds convincing.
Integration quality will shape that evaluation. The product must receive accurate information from security and operational systems without creating risky new access paths. Read permissions, service identities, network boundaries, and data synchronization all affect the result.
The strongest initial use cases are likely read-heavy and reversible. Alert investigation, evidence gathering, control mapping, procurement reviews, and draft ticket creation can save time without giving an agent direct authority over production systems.
Architecture review offers another plausible entry point. Cylus says the agent can inspect firewall rules and identify paths that bypass segmentation between enterprise IT and signaling zones. Human architects can then confirm whether those paths are necessary, documented, and adequately protected.
The more consequential step involves proposed response actions. In the company’s example, Cylus.ai recommends disabling a remote-access firewall policy and containing an endpoint. Either action could affect maintenance access, so the interface displays the predicted consequence before requesting approval.
That is a stronger design than silent automation, but the person reviewing the proposal needs enough time and expertise to challenge it. Human approval becomes ceremonial when an exhausted analyst simply accepts a recommendation presented with confidence.
Good implementations should make dissent easy. They should surface missing data, competing explanations, confidence limits, and the consequences of doing nothing. They should also distinguish an urgent containment recommendation from a lower-risk administrative task.
Cylus states that customer data will not be used to train models. It also advertises encryption in transit and at rest, single sign-on, role-based access control, and least-privilege design. Independent assurance will matter because the platform can access sensitive network and operational context.
Buyers should ask where model processing occurs, which subprocessors receive data, and whether deployments can isolate sensitive information. They should also examine retention policies, incident-response commitments, and controls against malicious content entering the agent’s context.
Prompt injection is particularly relevant. An agent could encounter hostile instructions hidden inside a document, ticket, log field, or connected knowledge source. A secure design must treat retrieved content as evidence rather than authority.
The product’s differentiation therefore depends on more than rail vocabulary. It must combine accurate context, disciplined permissions, reliable integrations, and evidence that survives expert review. Without those qualities, the domain layer becomes an expensive interface over familiar automation.
Three Transit Leaders Give Cylus a Wider Operating Lens
The advisory appointments connect the product to American transit policy, European rail regulation, and passenger-rail operations.
Nuria Fernández brings more than 35 years of transportation experience, according to the company’s announcement. She served as administrator of the U.S. Federal Transit Administration, which oversees federal programs supporting public transportation.
Her earlier positions included general manager and chief executive of the Santa Clara Valley Transportation Authority. She also held senior roles at the New York Metropolitan Transportation Authority, Chicago Transit Authority, and Washington Metropolitan Area Transit Authority.
That background gives Cylus access to an operator and policymaker perspective. Public agencies do not adopt security technology based solely on detection performance. They consider procurement rules, workforce capacity, federal requirements, accessibility, service continuity, and public accountability.
Fernández’s launch statement focused on the systems passengers never see. She argued that safety and reliability increasingly depend on connected systems with greater exposure. That framing links cybersecurity decisions to service delivery rather than treating them as isolated technical work.
Josef Doppelbauer contributes a different view. He formerly served as executive director of the European Union Agency for Railways, where his responsibilities covered vehicle authorization, safety certification, and European train-control approvals.
He also spent more than 35 years in railway technology, including work involving signaling and control-command systems. Earlier roles included chief technology officer at Bombardier Transportation and leadership positions in European rail-research initiatives.
Doppelbauer’s experience matters because European rail combines cross-border interoperability, national implementation, safety certification, and growing cybersecurity obligations. A product intended for that market must fit both technical standards and institutional processes.
His statement emphasized cooperation across the European sector. That is a useful warning against treating compliance as a static checklist. Rail cybersecurity decisions intersect with suppliers, infrastructure managers, operators, national authorities, and standards bodies.
Mario Péloquin adds a passenger-rail and project-delivery perspective. He served as president and chief executive of VIA Rail Canada and previously held senior positions at Siemens Mobility, Thales, AECOM, and the New York MTA.
The company credits him with close to 40 years of transportation experience. His work spans safety, operations, infrastructure delivery, and technology vendors, all of which influence whether a new security platform survives procurement and deployment.
Péloquin’s statement identified modernization as the source of both benefit and exposure. Each new connection can improve service, but it also requires protection. He argued that operators cannot become cybersecurity specialists overnight.
The board additions reinforce Cylus’s domain-first narrative. They give the company advisers who understand how railway organizations budget, regulate, certify, and operate technology. That can improve product decisions if their input reaches engineering and deployment teams.
Advisory positions nevertheless require careful interpretation. The appointments do not constitute customer endorsements, independent security assessments, or proof that Cylus.ai performs effectively. Cylus announced the advisers and the product together, making the credibility benefit part of its launch strategy.
The real value will appear in less visible choices. Does the product reflect how dispatchers, maintainers, safety officers, and security teams divide authority? Can it support different regulatory environments without flattening their requirements?
Another test concerns procurement. Transit agencies often need evidence about accessibility, data handling, vendor resilience, integration costs, and long-term support. Experienced advisers can help Cylus anticipate those questions before a technical pilot reaches formal approval.
The appointments also widen Cylus’s geographic lens. Fernández represents U.S. transit policy and operating experience. Doppelbauer brings European standards and regulation, while Péloquin connects Canadian passenger rail with multinational project delivery.
That breadth matches the company’s global ambition. However, rail networks remain locally specific. A multinational advisory board cannot replace direct testing with the operators, vendors, and front-line teams that will use the agent.
Human Approval Is Necessary, but It Is Not a Safety Guarantee
The central tradeoff is speed versus justified control inside a safety-sensitive environment.
Cylus repeatedly states that a person remains in control. Critical actions require explicit approval, and the system reportedly records its recommendations, evidence, and actions. Those safeguards align with current government advice.
In December 2025, the NSA, CISA, and international partners published AI integration principles for operational technology. The guidance recommends human involvement in critical decisions, strong governance, testing, monitoring, and fail-safe mechanisms.
The same guidance says operators should deploy AI only when benefits outweigh risks. It also recommends separating AI systems from OT environments where appropriate and pushing data outward instead of granting unnecessary inward access.
Cylus.ai appears aligned with that cautious model because its agent proposes actions for approval. The launch material also says the platform uses least-privilege access. Independent technical documentation would help buyers assess how those principles work in deployment.
Human review can fail in several ways. Analysts may defer to a confident recommendation, especially when workloads are high. They may also lack the rail expertise that the agent supposedly provides, making it difficult to identify a subtle error.
Approval design must therefore measure more than whether someone pressed a button. Operators should record what evidence the reviewer examined, whether a second authorization was required, and which action types remain prohibited.
High-consequence actions may need separate rules. Drafting a ticket is different from isolating an endpoint. Isolating an office laptop is different from disconnecting a workstation used for signaling maintenance.
Safety engineering already treats authority and consequence as structured problems. Agentic rail cybersecurity needs comparable rigor. Permission boundaries should follow the potential operational effect, not merely the technical category of the action.
An agent can also create a new concentration of access. To correlate evidence, it may need visibility across endpoint systems, network sensors, asset inventories, documentation, and ticketing. Compromising that identity could expose an unusually broad view of the environment.
Least privilege must remain dynamic. The system should receive only the data and tool permissions required for a specific workflow. Persistent credentials with broad reach would undermine the safety benefits of human approval.
Model updates create another concern. A behavior change introduced by a new model or prompt can alter recommendations without changing the connected railway systems. Operators need version controls, testing environments, rollback procedures, and clear notice of material changes.
They also need representative evaluation scenarios. A useful pilot should include known attacks, routine maintenance, incomplete telemetry, conflicting evidence, stale asset records, and unusual but legitimate operating conditions.
False positives can consume attention and weaken trust. False negatives can leave harmful activity unchallenged. A third failure mode is more subtle: a correct alert paired with an unsafe or impractical response.
Cylus has not disclosed measured rates for these outcomes. Nor has it publicly named launch customers, production deployments, or independently reviewed case studies for Cylus.ai. That information gap should shape how operators interpret its claims.
Early adopters should begin with decision support and observe the system across real workflows. They can compare agent conclusions with experienced analysts, track corrections, and identify where the system lacks local context.
Auditability is especially important when recommendations involve regulatory controls. An automatically assembled compliance record can save time, but it should preserve the underlying evidence. Reviewers must be able to reproduce the mapping without relying on the model’s summary.
The platform should also state uncertainty. An agent that lacks current topology, maintenance information, or endpoint data should identify the gap. Guessing can be worse than returning no conclusion in a safety-sensitive environment.
Cylus has chosen a defensible boundary by keeping people in the loop. The harder task is proving that those people receive enough context, authority, and time to exercise meaningful control.
Three Signals Will Show Whether Cylus.ai Works Beyond the Demo
Customer evidence, measured decision quality, and governance details will determine whether the launch changes rail-security operations.
The first signal is a documented production deployment. A named operator should explain which workflows use Cylus.ai, what data sources it connects to, and whether it operates in read-only or action-enabled mode.
The strongest case study would include operational outcomes rather than broad satisfaction. Useful measures include investigation time, evidence completeness, analyst corrections, false-positive handling, and the proportion of recommendations rejected.
A deployment spanning onboard, wayside, and station systems would strengthen Cylus’s domain argument. A limited compliance-document assistant would show value, but it would not validate the company’s broader security-operations claims.
The absence of customer evidence would weaken the launch narrative over time. Rail procurement moves slowly, so immediate silence is not decisive. However, pilots should eventually produce verifiable lessons if the product solves a pressing problem.
The second signal is transparent evaluation. Cylus should describe how it tests alert investigations, architecture findings, control mappings, and proposed actions. Buyers need to know whether evaluations include adversarial inputs and incomplete operational data.
Independent assessment would carry greater weight than internal benchmarks. A third party could examine the system’s evidence trails, permission controls, response quality, and resistance to manipulated content.
Evaluation should include local adaptation. An agent may perform well against a reference architecture and struggle with an operator’s naming conventions, undocumented links, or legacy maintenance procedures. Domain knowledge does not eliminate site-specific uncertainty.
The third signal is detailed governance for agent access and updates. Cylus should clarify how deployments isolate data, protect service identities, validate model changes, manage persistent memory, and preserve audit records.
This signal will become more important as regulators develop expectations for AI inside critical infrastructure. The NIST transit profile does not certify AI products, but it gives agencies a framework for prioritizing cybersecurity outcomes. Operators can use that structure to question how an agent affects governance, detection, response, and recovery.
European buyers will also consider NIS2 duties and rail-specific standards. Cylus’s new advisers can help translate these obligations, but customers will still require contractual and technical evidence.
Competitor reactions will provide supporting context. Broad security vendors may expand OT-aware copilots, while industrial-security specialists may train agents on sector-specific processes. Rail suppliers may also embed similar analysis within signaling or fleet-management platforms.
Cylus’s advantage lies in its narrow focus. Its disadvantage is that larger security platforms already control many data sources and response tools. The overlay strategy must deliver enough rail-specific value to justify another privileged system.
For rail-security teams, the right next step is not immediate autonomous response. It is a controlled comparison between agent-assisted investigations and existing practice. Teams should document where the agent saves time, where it lacks context, and when experts override it.
Cylus.ai rail cybersecurity deserves attention because it moves agentic AI toward operational decisions in critical infrastructure. Its human-approval boundary is sensible, and its rail-specific design addresses a real expertise problem.
Now the burden shifts from launch messaging to evidence. Can Cylus.ai produce repeatable conclusions from messy operational data? Can reviewers understand and challenge those conclusions under pressure? Rail operators should make those questions the center of every pilot before giving an AI agent greater authority.



