HERMES-OT

Status of this paper

This manuscript deliberately distinguishes proposed architecture and hypotheses from experimentally demonstrated results. No experimental performance figures are claimed for HERMES-OT itself. The next stage of the research is to implement the architecture and conduct controlled experiments against the hypotheses set out in section XX. That work is essential before the system is presented as empirically validated.

Abstract

Operational technology (OT) and industrial control systems (ICS) increasingly connect information technology, industrial networks, programmable logic controllers (PLCs), supervisory control and data acquisition (SCADA), distributed control systems (DCS), robotics and physical processes. This convergence creates a cybersecurity environment in which compromise of a digital asset may propagate into physical consequences.

The emergence of tool-using and autonomous large language model (LLM) agents introduces an additional dimension to this threat. Recent research has demonstrated that LLMs can generate attacks against PLC environments, and that autonomous agents can, under appropriate conditions, progress from PLC interaction toward sustained physical objectives. PLCBench, for example, recently evaluated autonomous LLM agents against commercial PLC hardware in a hardware-in-the-loop environment and reported sustained physical objectives in 31.3% of evaluated episodes [1].

Existing AI cybersecurity approaches, however, predominantly focus on alert classification, anomaly detection, vulnerability identification, malware analysis or natural-language security assistance. These capabilities do not fully address the central OT problem: determining how a cyber event propagates through industrial topology and ultimately affects a physical process.

This paper proposes HERMES-OT, a hierarchical embedded reasoning model for industrial security. It is a cyber-physical defence architecture based on a hierarchy of compact, specialised language models rather than a single general-purpose LLM, combining industrial telemetry, asset topology, vulnerability intelligence, attack graphs, process-state information, engineering knowledge and digital-twin simulation. The architecture introduces a reasoning chain that runs observe, understand, correlate, predict, simulate, prescribe, validate, learn.

The central hypothesis is that specialised small language models, coordinated through structured graphs and deterministic safety mechanisms, can provide sufficiently reliable industrial security reasoning while reducing inference latency, computational requirements and exposure of sensitive industrial information. The paper also proposes the OT-HERMES benchmark, a cyber-physical evaluation framework measuring detection, asset reasoning, vulnerability correlation, attack-path prediction, physical-impact prediction, defensive prescription, safety and computational efficiency.

Keywords. Industrial control systems; operational technology; cybersecurity; artificial intelligence; large language models; small language models; agentic AI; cyber-physical systems; PLC; SCADA; digital twin; attack graphs; AI security; industrial automation; predictive cybersecurity; IEC 62443.

I. Introduction

Artificial intelligence is rapidly transitioning from a software productivity technology into an operational technology. Large language models have demonstrated increasingly capable performance in reasoning, coding, information retrieval, tool use and autonomous task execution. Agentic systems extend these capabilities by allowing models to observe an environment, select tools, execute actions and adapt their behaviour based on feedback. This development has profound implications for industrial cybersecurity.

Industrial environments contain computational systems that directly interact with the physical world. NIST defines OT as systems and devices that interact with the physical environment, or manage devices that do so, including industrial control systems, PLCs, SCADA and related technologies. OT security must therefore account for performance, reliability and safety requirements that differ from conventional IT security [2].

The threat model is changing. A conventional attacker may manually perform reconnaissance, identify assets, research vulnerabilities and construct an attack path. An AI-enabled attacker may increasingly automate parts of that sequence: reconnaissance, then asset discovery, then vulnerability reasoning, then tool selection, then exploitation, then adaptation, then process manipulation.

The defender must therefore develop a corresponding capability: observation, then asset understanding, then vulnerability correlation, then attack prediction, then physical impact analysis, then safe intervention. This paper proposes HERMES-OT as a framework for developing such a capability.

II. Motivation

A. From IT cybersecurity to cyber-physical security. Traditional cybersecurity frequently evaluates risk at the level of digital assets. A finding of the form "PLC-17 contains vulnerability CVE-X" is useful but incomplete. The security significance depends on a further set of questions that no vulnerability score answers.

• Is PLC-17 reachable, and which systems can reach it?
• Which account can access it, and what privileges are available?
• What process does it control, and is that process safety-critical?
• Is the affected equipment redundant?
• What happens if the controller is isolated, or if its configuration changes?
• What is the likely next step in the attack?

Consequently, a digital vulnerability is not the same thing as a physical risk, and a cyber-physical defence system must reason across both domains.

B. AI changes the attacker. Research published in 2026 has demonstrated that general-purpose LLMs can synthesise attack techniques targeting PLCs from different industrial vendors, and that the quality of generated attacks depends significantly on the amount of target context available to the model [3]. More recently, PLCBench introduced a real-PLC hardware-in-the-loop evaluation framework combining vendor-native interaction, commercial PLC execution and closed-loop process simulation. Its results demonstrate that evaluating only whether an agent gains access to a PLC can underestimate the eventual physical impact of an attack [1].

The defender should therefore be evaluated against the same end-to-end chain.

III. Related work

A. Conventional OT cybersecurity. NIST SP 800-82 Revision 3 establishes the need to address the unique performance, reliability and safety requirements of OT systems, and provides guidance covering architectures, threats, vulnerabilities and safeguards [2]. IEC 62443 provides a foundational industrial cybersecurity framework built around zones, conduits, risk assessment and target security levels; IEC 62443-3-2 specifically establishes requirements for defining the system under consideration, partitioning it into zones and conduits, assessing risk and establishing target security levels [4]. HERMES-OT is designed to operate within these established architectural principles rather than replace them.

B. LLM-based cybersecurity. LLMs are increasingly used for vulnerability analysis, malware analysis, threat intelligence, security operations, code security, incident response and attack reasoning. CyberSecEval 4 expands evaluation of LLM cybersecurity capabilities and includes CyberSOCEval for malware analysis and threat-intelligence reasoning, demonstrating increasing interest in evaluating LLMs as defensive security systems [5]. General cybersecurity reasoning, however, does not automatically translate into reliable OT reasoning.

C. Compact security models. A particularly relevant development is the emergence of compact security-specific language models. Antares introduces 350M, 1B and 3B parameter models for agentic vulnerability localisation, and the authors report that Antares-3B approaches the performance of much larger models on their evaluated task while enabling local and comparatively low-cost inference [6]. This motivates a central HERMES-OT hypothesis: that industrial cybersecurity may benefit more from specialised compact models than from deploying one very large general-purpose model.

D. LLM-based ICS attack research. Recent research has explicitly examined LLM-generated attacks against industrial control systems. "With power comes responsibility" evaluates LLM-generated attack techniques against PLC models from different industrial vendors and reports that general-purpose LLMs can identify the steps required to synthesise attacks capable of manipulating real PLC operations [3]. This establishes an important research direction: LLM attacker capability should be matched by LLM defender capability.

E. Autonomous agent evaluation. AgentDojo demonstrated that tool-using LLM agents can be vulnerable to prompt injection, particularly when external data can influence agent behaviour; the benchmark contains 97 realistic tasks and 629 security test cases [7]. This matters directly for HERMES-OT, because an industrial AI defender will itself consume untrusted information: network telemetry, PLC logs, engineering documents, threat intelligence, vulnerability descriptions and external maintenance information. These inputs must be treated as data rather than as executable instructions.

F. Digital twins. Digital twins are increasingly investigated as mechanisms for improving ICS cyber defence. A 2026 study in Scientific Reports proposed a digital-twin-enhanced security framework in which a physics-consistent virtual representation of an industrial process is synchronised with physical telemetry and used to validate anomaly detection [8]. HERMES-OT extends this concept by using the digital twin not only for anomaly validation but also for defensive action validation.

G. Limitations of current LLM security reasoning. Research examining structured cybersecurity decision-making found that LLMs can produce coherent strategies when explicit attack-graph structure is provided, but remain fragile as graph complexity increases and can be sensitive to prompt framing [9]. This finding directly informs the architecture proposed here. HERMES-OT does not assume that an LLM should independently solve the entire security problem. The system of interest is the LLM together with the graph, deterministic reasoning, simulation and policy.

IV. The research gap

The existing literature demonstrates significant progress in several individual areas, and it is worth being precise about where each one currently stands.

• OT security. Mature security architectures.
• ICS anomaly detection. Extensive research.
• LLM cybersecurity. Rapidly developing.
• LLM attack synthesis. Demonstrated against PLC environments.
• Autonomous agents. Increasing capability.
• Small security models. Emerging.
• Digital twins. Increasingly used for cyber defence.
• Attack graphs. An established security reasoning mechanism.
• Physical process modelling. An established engineering discipline.

A gap remains at their intersection.

In particular, seven questions remain underexplored. What model size is sufficient for OT security reasoning? Does hierarchical reasoning outperform monolithic LLM reasoning? Does explicit industrial topology improve attack-path prediction? Does physical process state improve cyber-attack prediction? Can digital-twin simulation reduce unsafe defensive recommendations? Can local small models provide sufficient performance for plant-level deployment? And what is the relationship between model size and cyber-physical reasoning reliability?

V. Research objectives

• Objective 1. Develop a hierarchical architecture of specialised small language models for OT security.
• Objective 2. Create a unified cyber-physical knowledge representation.
• Objective 3. Develop predictive attack-path reasoning.
• Objective 4. Connect cybersecurity reasoning to physical-process consequences.
• Objective 5. Introduce safety-constrained defensive prescription.
• Objective 6. Develop a benchmark for measuring cyber-physical AI security reasoning.

VI. The HERMES-OT architecture

HERMES-OT is composed of seven major functional layers: data acquisition, event representation, the industrial knowledge graph, hierarchical AI reasoning, cyber-physical prediction, digital-twin simulation and safety-constrained prescription. The engine sits across the cyber and physical state of the plant and terminates, deliberately, at a human rather than at a controller.

VII. The industrial knowledge graph

The knowledge graph provides structured context to the models. A simplified path through it runs from an engineering workstation, over OPC UA, to PLC-17; PLC-17 controls Valve-12; Valve-12 regulates a pressure loop; and the pressure loop belongs to Reactor-01. The chain is short, and it is the chain that turns a network event into an engineering question.

Each relationship can carry further attributes: protocol, port, authentication, privilege, firmware, vulnerability, process dependency, safety classification, normal communication frequency and historical behaviour. The graph therefore becomes a continuously updated representation of the plant rather than a static asset inventory.

VIII. Hierarchical reasoning

The defining architectural feature of HERMES-OT is hierarchical reasoning. Each level consumes the output of the one below it, and each can be inspected on its own.

• Level 0, telemetry. Raw packets, logs, PLC events, sensor values and authentication events.
• Level 1, event interpretation. The first model converts raw information into structured events, for example: an engineering workstation initiated previously unseen OPC UA discovery activity.
• Level 2, asset reasoning. Source, destination, asset type, ownership, zone and criticality.
• Level 3, vulnerability reasoning. Correlation of firmware, CVEs, known weaknesses, exposed services, authentication and exploit prerequisites.
• Level 4, attack reasoning. Evaluation of possible sequences: engineering workstation, PLC discovery, PLC identification, vulnerability correlation, controller interaction, process-linked operation.
• Level 5, process reasoning. Which physical process is dependent upon this asset?
• Level 6, consequence reasoning. Estimated production impact, equipment impact, safety impact, environmental impact and recovery difficulty.
• Level 7, defensive reasoning. Candidate interventions are generated.
• Level 8, safety validation. A deterministic safety and policy engine evaluates whether the intervention is permissible.

IX. The small-language-model ensemble

Rather than one large model, HERMES-OT proposes a set of specialised ones. The sizes below are experimental hypotheses, not settled design parameters.

• Event model, 100M to 500M parameters. Converts high-volume telemetry into structured events.
• OT reasoning model, 350M to 1B. Interprets industrial protocols and operational behaviour.
• Vulnerability model, Antares-class as a candidate starting point. Maps vulnerabilities to industrial assets and attack prerequisites.
• Attack reasoning model, 1B to 3B. Predicts attack-path progression.
• Process reasoning model, 1B to 3B. Interprets relationships between cyber assets and process states.
• Prescription model, 1B to 3B. Generates candidate defensive actions.
• Arbitration model, 1B to 7B. Compares competing model outputs.

X. Model candidates

The research should initially compare several model families rather than commit early to one. Among compact security models, Antares-350M, Antares-1B and Antares-3B are directly relevant, because they are explicitly trained for cybersecurity reasoning rather than being generic language models [6]. Among general compact models, candidate families should include Qwen small models, Llama small models, Phi models, SmolLM-class models and other open-weight models available at experiment time.

The objective is not to crown an architecture in advance. It is to determine which architecture provides the best OT-security reasoning per unit of compute.

XI. A cyber-physical risk formulation

A conventional vulnerability score does not adequately represent industrial risk. The following research formulation is proposed.

• V, the vulnerability and exploitability factor.
• R, reachability.
• P, the privilege and access factor.
• D, process dependency.
• I, physical impact.

The formulation is deliberately proposed as a research construct rather than as a replacement for established risk standards, and it should be empirically calibrated against simulated and hardware-in-the-loop outcomes. Its multiplicative form carries a claim worth stating openly: if any one term is zero, the cyber-physical risk is zero, however alarming the others look in isolation.

XII. The attack progression graph

HERMES-OT introduces an attack progression graph, which represents possible transitions between attacker states rather than isolated alerts. A representative progression runs from initial access to discovery, asset enumeration, vulnerability identification, privileged access, controller interaction, process manipulation and finally physical impact.

Each transition carries a probability, its supporting evidence, its prerequisites, a confidence value and a potential impact. The system therefore reasons over trajectories, which is what allows it to say something about the step that has not happened yet.

XIII. Detecting an AI adversary

The system should not attempt to classify network traffic as human or AI-generated. Such classification would be fragile, and would degrade the moment the adversary changed tooling. Instead, HERMES-OT identifies behavioural characteristics associated with autonomous attack workflows: unusual asset enumeration, rapid service discovery, previously unseen protocol interactions, systematic vulnerability probing, repeated adaptive queries, escalating privilege attempts and process-linked interaction.

The signal of interest is therefore the combination of behaviour, sequence, topology, privilege, vulnerability and process, rather than any linguistic characteristic of the attacker.

XIV. The predictive security loop

The proposed operational loop has ten stages. Observe: collect telemetry. Detect: identify anomalous behaviour. Understand: identify affected assets. Correlate: connect vulnerabilities and topology. Predict: estimate possible attack progression. Simulate: evaluate physical consequences. Prescribe: generate defensive options. Validate: apply policy and safety constraints. Act: execute only authorised controls. Learn: update models and knowledge.

XV. Digital-twin validation

A major component of HERMES-OT is the digital twin. Consider a recommendation to isolate PLC-17. The AI cannot safely determine whether this is appropriate from cybersecurity information alone, because isolating a controller is itself an action on the process.

The twin evaluates the action as a process-state transition. Isolating PLC-17 makes a pump unavailable; pressure decreases; the control loop responds; temperature changes; and the safety margin moves. The twin produces an estimated outcome for each candidate, which is what makes the options comparable: isolate the asset, restrict communication, revoke a credential, increase monitoring, or do nothing and observe. The safest intervention can then be selected on evidence rather than on instinct.

XVI. Safety-constrained AI

A fundamental principle governs the whole architecture: no probabilistic model should have unrestricted authority over a safety-critical industrial control system. The AI is not the controller. It produces a recommendation, which passes to policy, then to safety validation, then to authorisation, and only then to control.

The deterministic layer should enforce allowable actions, asset criticality, operational state, maintenance windows, safety constraints, separation-of-duty rules and human approval requirements. None of those belong inside the model.

XVII. Securing the AI agent itself

HERMES-OT introduces its own attack surface. An attacker could attempt to manipulate logs, telemetry, documentation, threat intelligence, asset metadata, vulnerability information or tool responses. This creates the possibility of industrial prompt injection.

The architecture must therefore explicitly separate data, meaning information observed by the system, from instructions, meaning authoritative system directives. This is particularly important because research on agentic systems has demonstrated that untrusted tool-returned data can influence model behaviour [7]. HERMES-OT accordingly requires trusted instruction channels, untrusted-data labelling, tool permission boundaries, action validation, provenance tracking and deterministic policy enforcement.

XVIII. The OT-HERMES benchmark

The OT-HERMES benchmark is proposed as a dedicated evaluation framework covering eight tasks.

• Task 1, event detection. Can the system identify abnormal industrial behaviour? Scored as F1, the harmonic mean of precision and recall: F1 = 2PR / (P + R).
• Task 2, asset identification. Can the system correctly identify affected assets?
• Task 3, vulnerability correlation. Can it determine whether a vulnerability is relevant to the observed attack path?
• Task 4, attack-path prediction. Can the model predict the next plausible attack transition?
• Task 5, physical-impact prediction. Can the system predict the affected physical process?
• Task 6, defensive prescription. Can it generate a safe intervention?
• Task 7, safety. Does the proposed intervention violate predefined safety constraints?
• Task 8, efficiency. How much compute is required?

XIX. Security reasoning efficiency

A new evaluation metric is proposed to make architectures comparable rather than merely rankable.

Here Q is validated security reasoning quality, P is parameter count and L is inference latency. The purpose is not to claim that parameter count and latency are interchangeable physical quantities, but to create an experimental efficiency measure for comparing architectures. A more comprehensive implementation could report SRE* = Q / (C × L), where C represents measured inference compute or energy cost. Either form allows 350M, 1B, 3B and 7B models to be compared against larger frontier models on the same axis.

XX. Research hypotheses

• H1, hierarchical efficiency. A hierarchy of specialised compact models will achieve comparable or superior OT security reasoning performance to a single general-purpose model at substantially lower inference cost.
• H2, graph advantage. Providing explicit asset and attack graphs will improve reasoning reliability compared with unstructured natural-language prompts.
• H3, physical context advantage. Including physical process state will improve prediction of cyber-physical consequences.
• H4, simulation safety. Digital-twin validation will reduce unsafe defensive recommendations.
• H5, local inference. Compact local models will provide lower latency and reduced data exposure compared with cloud-dependent architectures.
• H6, progressive reasoning. Hierarchical reasoning will improve interpretability by allowing each inference stage to be inspected independently.

XXI. Experimental methodology

The experimental programme should use a controlled cyber-physical testbed containing a PLC, an HMI, SCADA, an engineering workstation, an industrial network, a simulated physical process, telemetry collection, a vulnerability database, attack scenarios and a digital twin. The experiment should not initially target live production infrastructure.

XXII. Experimental conditions

At least five configurations should be compared, so that each architectural contribution can be isolated rather than assumed.

• Configuration A. A traditional machine-learning anomaly detector.
• Configuration B. A single general-purpose LLM.
• Configuration C. A single compact security model.
• Configuration D. The hierarchical small-model architecture.
• Configuration E. The hierarchical architecture with knowledge graph and digital twin.

XXIII. Ablation studies

Ablation experiments should remove one capability at a time, because they provide stronger evidence than an overall accuracy figure. Without the knowledge graph, measure attack reasoning degradation. Without process information, measure physical-impact prediction degradation. Without the digital twin, measure defensive safety degradation. Without hierarchy, measure the performance of monolithic reasoning. Without vulnerability context, measure attack-path prediction. Without deterministic policy, measure the unsafe recommendation rate.

XXIV. Expected results

Because the system has not yet been experimentally implemented, this paper claims no empirical results. It predicts six outcomes, all of which must be tested: that small specialised models will outperform generic compact models on specialised OT tasks; that hierarchical reasoning will reduce hallucination; that graph context will improve attack-path reasoning; that process context will improve physical-impact prediction; that digital-twin validation will reduce unsafe prescriptions; and that local inference will substantially reduce latency and data-transfer requirements.

XXV. The dataset challenge

Dataset availability is likely to become one of the principal barriers to this research. A 2026 meta-review identified major structural weaknesses in ICS cybersecurity datasets, including heavy concentration on late-stage OT disruption, limited cross-stage IT and OT progression sequences, very limited field-device evidence and relatively low levels of operationally sourced data [10]. A separate roadmap similarly identifies the lack of standardised benchmarking datasets, modern attack scenarios, real operational traffic and reliable validation environments as persistent problems [11]. OT-HERMES should therefore contribute a dataset rather than assume one.

XXVI. Proposed dataset structure

Each event should carry the fields that make both machine-learning and language-model evaluation possible on the same record: timestamp, asset, asset type, network zone, protocol, source, destination, identity, privilege, observed event, known vulnerability, process state, attack stage, physical impact, ground truth, recommended response and safety constraint.

XXVII. Knowledge representation

Each event should be represented simultaneously in three forms: a time-series representation for numerical process information, a graph representation for asset relationships, and a language representation for engineering documents, logs and security intelligence. The architecture is therefore multimodal by necessity rather than by fashion, because cyber-physical reasoning requires all three at once.

XXVIII. Industrial deployment model

A practical deployment places HERMES-OT primarily at the OT security boundary, between the enterprise systems above it and the control network below.

The system should support four modes, and the mode is set outside the model.

• Passive mode. Observe only.
• Advisory mode. Generate recommendations.
• Controlled response. Execute approved actions that are not safety-critical.
• Automated response. Only where explicitly permitted by deterministic policy.

XXIX. Industrial use cases

The same reasoning chain expresses itself differently by sector, because what the process does differs.

• Manufacturing. Detect an engineering workstation attempting unusual PLC discovery. Predict potential production-line impact.
• Chemical processing. Identify a cyber event affecting a controller associated with pressure or temperature regulation. Simulate possible process consequences.
• Oil and gas. Correlate network intrusion with compressor or pump control systems. Predict production and equipment implications.
• Power. Correlate cyber events with substation or control-system state. Evaluate safe containment.
• Robotics. Detect abnormal robot-controller interactions. Determine whether the robot is connected to safety-critical production operations.

XXX. Differentiation from existing security products

Category confusion is the fastest way for work of this kind to be misread, so the negative definition matters as much as the positive one. HERMES-OT should not be positioned as a conventional SIEM, an LLM chatbot, a vulnerability scanner, a generic SOC copilot, an autonomous penetration-testing tool, or a PLC controller.

XXXI. Theoretical contribution

The paper proposes a transition through three levels of industrial cybersecurity reasoning.

• Level 1, asset-centric. Is the asset vulnerable?
• Level 2, path-centric. Can an attacker reach and exploit the asset?
• Level 3, consequence-centric. What physical consequence could result, and what intervention minimises that risk?

This produces a conceptual chain that runs from a digital fact to a physical decision:

The third level is the primary target of HERMES-OT.

XXXII. Contributions

The proposed research makes eight contributions.

• 1. A hierarchical architecture for small-language-model industrial cybersecurity.
• 2. A cyber-physical knowledge graph integrating OT topology, security and process state.
• 3. An attack progression reasoning model.
• 4. A cyber-physical risk formulation.
• 5. Digital-twin-based validation of defensive recommendations.
• 6. A safety-constrained AI prescription architecture.
• 7. The OT-HERMES benchmark.
• 8. A methodology for determining minimum viable model size for OT security reasoning.

XXXIII. Limitations

Several limitations must be acknowledged, and they are stated before any result exists rather than after.

• Compact language models may have insufficient general reasoning capability for complex multi-stage attacks.
• Industrial process models can be difficult to construct accurately.
• High-quality OT datasets remain limited.
• Simulated environments may not fully reproduce real industrial environments.
• LLM outputs remain probabilistic and therefore cannot be treated as deterministic safety controls.
• Knowledge graphs can become outdated if asset configuration changes are not continuously synchronised.
• The proposed cyber-physical risk formulation requires empirical calibration.

XXXIV. Ethical and safety considerations

Research involving autonomous AI and industrial control systems must be conducted in controlled environments. The proposed system should initially be evaluated using isolated testbeds, simulated processes, hardware-in-the-loop environments, synthetic vulnerabilities and authorised systems.

The objective of the research is defensive capability. The benchmark should therefore measure defensive performance without requiring unrestricted deployment of attack agents against production infrastructure.

XXXV. Future research

• Self-improving OT security models, continuously learning from validated incidents.
• Federated industrial learning, so multiple plants improve models collaboratively without exchanging sensitive telemetry.
• Explainable attack reasoning, where every prediction includes its evidence.
• Formal verification, checking safety-critical prescriptions against formal constraints.
• Multimodal industrial reasoning, combining text, network traffic, PLC logic, time series, images, diagrams and engineering drawings.
• Autonomous defensive agents, eventually executing predefined low-risk remediation automatically.
• AI-versus-AI evaluation, assessing AI attackers and AI defenders in the same controlled environment.

XXXVI. Discussion

The central argument of this paper is not that large language models should control industrial systems. The opposite is proposed. Industrial cybersecurity requires an architecture in which probabilistic intelligence is surrounded by deterministic constraints, and in which each component holds a role it is not permitted to exceed.

• The AI should reason.
• The graph should provide context.
• The process model should provide physical understanding.
• The digital twin should provide simulation.
• The policy engine should provide authority.
• The safety layer should provide boundaries.
• The human should retain control where risk demands it.

That produces a fundamentally different architecture from a generic security chatbot, and it is the reason the components are named separately rather than folded into one model.

XXXVII. The core research question

The proposed programme reduces to a single question. Can small, specialised AI models, when combined with structured industrial knowledge and physical-process reasoning, provide reliable cyber-physical defence at the edge?

If the answer is yes, the implications are significant. Industrial organisations would not necessarily need to send sensitive plant telemetry to large external AI services. Intelligence could increasingly operate locally: inside the plant, close to the process, close to the data and close to the decision.

XXXVIII. Conclusion

The cybersecurity boundary of the modern industrial plant is changing. Historically, cybersecurity focused primarily on protecting digital systems. Industrial cybersecurity expanded the problem by recognising that digital compromise can affect physical operations. Artificial intelligence introduces another transition.

An autonomous AI attacker may be capable of discovering industrial systems, reasoning about vulnerabilities, selecting tools and adapting its behaviour. The defender therefore requires more than anomaly detection. It requires reasoning.

HERMES-OT proposes a hierarchical architecture in which compact specialised language models collaborate with knowledge graphs, attack graphs, process models, digital twins and deterministic safety controls. Its central proposition is that AI cybersecurity is not an AI chatbot. Cyber telemetry, industrial topology, vulnerability intelligence, process state, attack reasoning and simulation together produce something different in kind: cyber-physical defence.

The most important research question is not whether a large language model can understand cybersecurity. That question is increasingly answered by existing research. The more important one is harder.

Answering it could establish a new research direction at the intersection of artificial intelligence, cybersecurity, operational technology, industrial automation and cyber-physical systems. HERMES-OT is proposed as a framework for investigating that frontier.

References

• [1] Zhou, Y., Zheng, J., Jiang, Q., Du, L., Liu, H., Wu, L., Zhao, S., Liu, M. and Deng, R. (2026). PLCBench: can autonomous LLM agents turn PLC access into sustained physical impact? arXiv:2608.26882.
• [2] Stouffer, K. and others (2023). Guide to Operational Technology (OT) Security. NIST Special Publication 800-82 Revision 3, National Institute of Standards and Technology.
• [3] With power comes responsibility: attack synthesis for industrial control systems using large language models (2026). ACM Transactions on Privacy and Security, 29(3), Article 31. doi:10.1145/3815116.
• [4] ANSI/ISA-62443-3-2-2020. Security for industrial automation and control systems, Part 3-2: security risk assessment for system design.
• [5] Deason, L. and others (2025). CyberSOCEval: benchmarking LLM capabilities for malware analysis and threat intelligence reasoning. CyberSecEval 4, Meta.
• [6] Vijay, S. and others (2026). Antares: foundation models for agentic vulnerability localization. arXiv:2608.02407.
• [7] Debenedetti, E., Zhang, J., Balunovic, M., Beurer-Kellner, L., Fischer, M. and Tramer, F. (2024). AgentDojo: a dynamic environment to evaluate prompt injection attacks and defenses for LLM agents. Advances in Neural Information Processing Systems 37.
• [8] Sayghe, A., Alahmadi, M. D. and Gharawi, A. A. (2026). A digital twin and deep-learning ensemble for cyber attack detection in industrial control systems at the IoT edge. Scientific Reports, 16, 23318.
• [9] Malacaria, P. and Zhang, Y. (2026). Structured but fragile: on the limits of LLMs in cybersecurity decision-making. arXiv:2608.20966.
• [10] Kampourakis, K. E. and others (2026). ICS cybersecurity datasets: a systematic meta-review of coverage, evaluation practice and structural gaps. arXiv:2608.24757.
• [11] Alqahtani, E. J. and Hammoudeh, M. (2026). A roadmap to available ICS datasets and testbeds for cybersecurity research. arXiv:2608.30332.
• [12] NIST. Operational Technology Security. Computer Security Resource Center, National Institute of Standards and Technology.
• [13] Meta. PurpleLlama and CyberSecEval 4, open-source cybersecurity benchmark suite.

Author's note

This manuscript deliberately distinguishes proposed architecture and hypotheses from experimentally demonstrated results. No experimental performance figures are claimed for HERMES-OT itself. The next stage of the research should implement the architecture and conduct controlled experiments against the proposed hypotheses. This is essential before presenting the work as an empirically validated system.

Short title. HERMES-OT: small AI models for cyber-physical defence. Tagline. From detecting the attack to predicting the consequence.

Cite this paper

The preprint is archived on Zenodo under a CC BY 4.0 licence, with the PDF available for download.