Security / Resilience / Autonomous Systems

Autonomous Cyber-Physical Protection Architectures for Nuclear-Powered Mega Datacenters

Report summary

The paradigm of digital infrastructure is undergoing a radical, unprecedented transformation driven by the exponential and seemingly insatiable energy demands of mega datacenters. As advanced computing, machine learning training clusters, generative artificial intelligence pipelines, and cloud-scale

Status
Research archive item
Category
Security / Resilience / Autonomous Systems
Length
6,557 words
Reading time
30 minutes
Report type
architecture

Key topics

  • Security / Resilience / Autonomous Systems
  • Security
  • Resilience
  • Autonomous Systems
  • AI
  • Agentic Web
  • .NET
  • SQL
  • Runtime

Research provenance

Archive status
Research archive item
Content identity
sha256:129171c75160c56879b4d0806b20b85db1e756f63378fec77067a704ae44efb4

For citation, use the report title and canonical URL. Archival presence does not establish authorship or promote report statements into portfolio evidence.

This page renders the archived Markdown as safe, formatted HTML. It is background research and does not become a portfolio claim without evidence review.

Full report

On this page

The paradigm of digital infrastructure is undergoing a radical, unprecedented transformation driven by the exponential and seemingly insatiable energy demands of mega datacenters. As advanced computing, machine learning training clusters, generative artificial intelligence pipelines, and cloud-scale operations push single-facility power requirements well into the gigawatt range, traditional power grids are struggling to provide adequate and reliable electricity1. Renewable energy sources like solar and wind, while environmentally necessary, are fundamentally constrained by their weather-dependent intermittency, making them insufficient to guarantee the absolute baseload reliability required by mission-critical data processing1. To resolve this energy crisis, mega datacenter operators are increasingly partnering with the nuclear sector to co-locate their facilities with Small Modular Reactors (SMRs), seeking to secure continuous, highly reliable, and carbon-free generation1. However, this convergence of high-availability Information Technology (IT) and safety-critical Operational Technology (OT) establishes a uniquely volatile and unprecedented cyber-physical attack surface5. The operational imperatives of exabyte-scale datacenters and the uncompromising, zero-fail safety thresholds of nuclear reactors dictate that defensive responses to cyber threats must occur at absolute zero-latency—or machine speed—leaving absolutely no time for human reaction6. Historically, protecting critical infrastructure relied heavily on human-in-the-loop Security Operations Centers (SOCs), where analysts manually investigated alerts, adjusted firewalls, and executed incident response playbooks. In a highly interconnected nuclear-datacenter microgrid, the latency inherent in human decision-making is an exploitable vulnerability. A successful cyberattack could disrupt coolant flow, manipulate control rod positioning, or trigger cascading electrical failures in milliseconds10. Consequently, protecting these unified cyber-physical ecosystems requires a radical departure from traditional methodologies. Next-generation protection mandates an autonomous architecture that merges hardware-accelerated packet inspection, causality-driven multi-agent reinforcement learning, deterministic physical isolation, and kinetic electrical stabilization. This report provides an exhaustive, highly technical architectural blueprint for the autonomous protection of nuclear-powered mega datacenters.

The Convergence of Mega Datacenters and Small Modular Reactors

The integration of SMRs into commercial datacenter operations represents a fundamental rethink of how the digital age is powered. Unlike the sprawling, multi-gigawatt conventional nuclear power plants of the past century, SMRs are compact, scalable, and modular units specifically designed for localized, decentralized grids and heavy industrial applications1. Global momentum for this transition is accelerating rapidly, with advanced designs ranging from light-water reactors and sodium-fast reactors to high-temperature gas-cooled units approaching commercial viability2. Prominent hyperscalers and energy consortia have already initiated this transition, evidenced by Microsoft's aggressive investments in nuclear power and the development of the Cumulus Data campus in Pennsylvania, which is directly tied to the 2.5-gigawatt Susquehanna nuclear plant1. The regulatory landscape has also adapted to accommodate this integration. Federal rules governing nuclear emergency planning have recently been updated to allow for significantly smaller evacuation and shelter zones, which are meticulously tailored to the substantially lower risk profiles and passive safety mechanisms inherent in SMR designs13. This crucial regulatory evolution means that a well-designed SMR campus can confine all safety and emergency planning strictly within the site boundary itself, rather than impacting neighboring residential communities13. This capability makes the localized siting of reactors directly at data centers highly feasible2. Despite their compact footprint and advanced passive safety systems, SMRs introduce entirely new vectors of vulnerability. They are highly reliant on centralized fleet management, extensive digital automation, and remote supervisory control systems, which drastically reduce the need for on-site staffing but simultaneously mandate continuous, high-bandwidth connectivity to external networks5. When an SMR is physically and digitally tethered to a hyperscale datacenter—a facility inherently designed to process vast amounts of external internet traffic—the traditional air-gaps that once protected nuclear assets are functionally obliterated5.

IT/OT Convergence and the Expanded Layered Attack Surface

To fully understand the threat landscape of a nuclear-powered datacenter, one must analyze the total erosion of the historical divide between IT and OT. Historically, IT networks (focused on data confidentiality and business applications) and OT networks (focused on the physical manipulation of hardware, prioritizing availability and safety) were managed by entirely separate organizational silos with disparate technologies7. The advent of the fourth industrial revolution, characterized by the Industrial Internet of Things (IIoT) and advanced distributed energy resources (DERs), has driven the convergence of these two domains6. This merger promises immense operational benefits, including optimized data exchange, predictive maintenance, and seamless process automation7. However, as these networks converge, the attack surface expands dramatically6. Every smart sensor, programmable logic controller (PLC), and human-machine interface (HMI) accessible over the integrated IT/OT network becomes susceptible to weaponization6. To systematically analyze and secure these vulnerabilities, security architects leverage the Layered Attack Surface (LAS) model, which categorizes the ecosystem into discrete operational depths18.

Attack Surface LayerDescription and Functionality within Nuclear DatacentersPrimary Vulnerabilities and Attack Vectors
Layer 7: ApplicationHigh-level software interfaces, cloud management dashboards, and centralized fleet control software used to monitor the SMR and datacenter.Phishing, credential theft, SQL injection, API exploitation, and compromised fleet management credentials19.
Layer 4-6: Network/TransportThe routing and communication protocols connecting the datacenter IT network to the external internet and the internal OT supervisory networks.Volumetric DDoS attacks, man-in-the-middle (MitM) interception, routing protocol manipulation, and unauthorized cross-zone bridging7.
Layer 2-3: Data/ControlThe operational control networks where HMIs issue commands to PLCs utilizing industrial protocols (Modbus, OPC UA).Unauthenticated protocol injection, spoofed control logic, automated reconnaissance, and ICS-specific malware7.
Layer 1: Physical/HardwareThe fundamental physical processes, embedded sensors, actuators, network cables, and the raw physical operation of the reactor core and cooling systems.Hardware trojans, rogue device insertion, physical wiretapping, malicious firmware replacement, and supply chain interception6.

Table 1: The Layered Attack Surface (LAS) model applied to converged nuclear IT/OT environments. The greatest danger in this converged architecture is that an adversary can initiate an attack at the highly exposed Application or Network layers (Layers 7-4) and pivot laterally to execute destructive payloads at the Data/Control and Physical layers (Layers 2-1)7. Because older OT systems were engineered for reliability in closed environments, they frequently lack modern cryptographic security, authentication mechanisms, and native threat detection6. This renders them defenseless against sophisticated, modern adversaries who have successfully penetrated the outer IT perimeter.

The Evolution of the Threat Landscape: PIPEDREAM and Machine-Speed Attacks

The urgency of developing autonomous cyber defense is underscored by the rapid maturation of state-sponsored offensive capabilities. The threat landscape has evolved far beyond theoretical sabotage; adversaries now possess highly specialized, modular malware frameworks engineered explicitly to degrade, disrupt, and destroy critical infrastructure11. The most consequential realization of this capability is PIPEDREAM (also tracked extensively under the alias Incontroller), a highly sophisticated ICS attack framework developed by the state-sponsored threat group known as CHERNOVITE9. PIPEDREAM is recognized as the seventh known ICS-specific malware in history—following predecessors such as Stuxnet, Havex, BlackEnergy, Industroyer, and Triton—but it represents a massive evolutionary leap in cyber warfare9. While previous malware required highly specific knowledge of a target facility and relied heavily on exploiting rare zero-day software vulnerabilities, PIPEDREAM is a cross-industry, universally scalable attack framework11. It is capable of executing 38% of all known techniques and 83% of all known tactics within the MITRE ATT\&CK for ICS matrix11. The primary danger of PIPEDREAM lies in its methodology: it does not exploit software flaws; rather, it exploits the native, intended functionality of pervasive industrial equipment and protocols12. By leveraging legitimate administrative tools and standard industrial communication standards like ModbusTCP, EtherCAT, and Open Platform Communications Unified Architecture (OPC UA), PIPEDREAM operates under the guise of normal operational traffic, making it exceedingly difficult for traditional security solutions to detect11. The framework is composed of several highly integrated, modular utilities designed to execute distinct phases of the cyber kill chain.

PIPEDREAM ModuleKnown AliasTargeted InfrastructureTactical Capability and Execution
TagrunN/AOPC UA ServersConducts stealthy network scanning and enumeration of OPC UA architectures. Identifies critical industrial processes and allows attackers to seamlessly read, modify, or corrupt tag values9.
CodecallEVILSCHOLARSchneider Electric PLCs / CODESYSCommunicates natively via Modbus and the ubiquitous CODESYS architecture. Allows adversaries to interact with, manipulate, disable, and upload malicious, untrusted code directly to targeted controllers9.
OmshellBADOMENOmron PLCs (NJ/NX series)Establishes direct console access to Omron controllers using HTTP, UDP, and the proprietary Omron FINS protocol, enabling deep manipulation of safety systems9.
ICECOREDUSTTUNNELWindows WorkstationsProvides persistent command-and-control (C2) backdoor access into IT/OT pivot points, enabling extensive reconnaissance and lateral movement9.
N/ALAZYCARGOWindows OS HardwareExploits specific vulnerable drivers (e.g., ASRock RGB Driver CVE-2020-15368) to escalate privileges and bypass endpoint security controls9.

Table 2: Modular components and capabilities of the PIPEDREAM/Incontroller ICS attack framework. In the context of a nuclear-powered mega datacenter, the deployment of a framework like PIPEDREAM introduces the capability for instantaneous, cascading destruction. An adversary utilizing Tagrun and Codecall could spoof the temperature telemetry from the SMR's primary heat exchanger while simultaneously severing connections to the datacenter's cooling infrastructure11. Because PIPEDREAM interacts with these systems at machine speed, any defensive response that requires an alert to be generated, reviewed by a human analyst on a dashboard, and manually actioned will occur far too late to prevent physical core damage or the loss of exabytes of data6. Autonomous, zero-latency intervention is the only viable countermeasure.

The False Positive Paradox in Autonomous OT Defense

While the necessity of machine-speed automated response is clear, deploying fully autonomous defense mechanisms introduces a severe and potentially catastrophic operational paradox: the risk of the false positive26. In traditional cybersecurity operations, a false positive occurs when an overly sensitive or contextually blind security tool incorrectly flags a benign file, legitimate network flow, or routine administrative action as malicious27. In a standard enterprise IT environment, the consequence of a false positive is primarily economic and psychological. It wastes the time of the IT department, consumes valuable resources during the triage process, and ultimately leads to severe "alert fatigue"26. Studies, such as the Orca Security Alert Fatigue Report, have repeatedly demonstrated that when analysts are bombarded by thousands of daily false positives generated by misconfigured Endpoint Detection and Response (EDR) or Security Information and Event Management (SIEM) systems, they become desensitized26. Consequently, true positive alerts—genuine indicators of an active compromise—are frequently overlooked or dismissed, significantly delaying incident response26. However, in the deeply interconnected physical environment of a nuclear-datacenter microgrid, the impact of a false positive transcends wasted time; it becomes an active threat to physical safety and operational continuity26. If a Security Orchestration, Automation, and Response (SOAR) platform or an autonomous agent detects a perceived anomaly and reacts by automatically severing a critical network link, shutting down a cooling system PLC, or initiating an emergency isolation sequence, the resulting system outage can cause catastrophic negative externalities26. For example, routine maintenance performed on an SMR sensor by a local technician might generate unexpected network traffic26. If an autonomous defense agent lacks the necessary operational context, it might classify this maintenance traffic as a PIPEDREAM lateral movement attempt11. If the agent responds by instantly quarantining the reactor's primary control subnet, the automated defense action itself initiates a massive physical disruption26. The financial losses stemming from taking a gigawatt datacenter offline erroneously are staggering, but more importantly, the sudden load rejection imposed on the nuclear reactor can cause severe thermal and mechanical stress, challenging the fundamental safety limits of the facility26. Thus, the architectural mandate for protecting nuclear mega datacenters is incredibly stringent. The system cannot merely be fast; it must be flawlessly accurate, highly contextualized, and strictly constrained so that it never inflicts more damage than the threat it is neutralizing. This requires building defense from the physical consequences upward.

Foundational Boundaries: Consequence-Driven Cyber-Informed Engineering (CCE)

Before any autonomous agent can be safely deployed, the operational environment itself must be rigorously engineered to ensure that absolute safety and critical business functions are physically and structurally resilient against cyber manipulation31. This foundational prerequisite is achieved through the methodology of Consequence-driven Cyber-informed Engineering (CCE), a paradigm pioneered by the Idaho National Laboratory (INL) and heavily funded by the Department of Energy's Office of Cybersecurity, Energy Security, and Emergency Response (CESER)31. Traditional cybersecurity focuses on perimeter defense, vulnerability patching, and compliance auditing, attempting to keep adversaries out of networks17. CCE entirely inverts this paradigm. It assumes that a highly sophisticated, well-resourced Advanced Persistent Threat (APT) has already bypassed all perimeter defenses, gained total network dominance, and achieved deep persistence within the facility31. From this assumption of inevitable compromise, CCE focuses on identifying the specific physical consequences that must be avoided at all costs, and then systematically engineers the digital dependencies out of those critical pathways31. The methodology is meticulously structured across four collaborative phases that fundamentally map and eliminate the pathways to systemic disaster.

CCE PhaseTitle and ObjectiveExecution Strategy within a Nuclear-Datacenter Context
Phase 1Consequence PrioritizationThe organization explicitly defines the boundaries of acceptable risk by identifying High Consequence Events (HCEs). Instead of focusing on threat likelihood, analysts adopt an adversarial mindset to determine which physical events would completely cripple the facility (e.g., radiological release, loss of primary heat sink, or catastrophic corruption of localized exabyte storage clusters)34.
Phase 2System-of-Systems AnalysisEngineers map the deep interdependencies of the facility to uncover how an HCE could actually be triggered. This involves identifying all digital infrastructure, hidden network bridges, and areas of "unverified trust" where the nuclear I\&C systems blindly accept data or power fluctuation requests from the datacenter management network34.
Phase 3Consequence-Based TargetingSecurity personnel simulate the role of an APT, tracing the exact cyber kill chain required to successfully execute the HCE. Utilizing frameworks like MITRE ATT\&CK for ICS, the team identifies the specific sensors, PLCs, and network pathways that must be compromised, mapped directly against the facility's unique architecture17.
Phase 4Mitigations and ProtectionsThe final objective is to engineer the identified cyber-risks out of the physical system entirely. This involves implementing non-digital fail-safes, mechanical interlocks, analog backups, and strict hardware isolation to ensure that no amount of digital manipulation can override the fundamental physical safety limits of the reactor or the datacenter31.

Table 3: The four phases of the Consequence-driven Cyber-informed Engineering (CCE) methodology. By applying CCE, operators establish Critical Function Assurance (CFA)35. This process drastically simplifies the operational scope of the autonomous defense system. Rather than burdening artificial intelligence with the impossible task of evaluating infinite permutations of benign IT traffic, the AI agents are specifically directed and optimized to protect the highly constrained pathways that lead to identified HCEs17. This massive reduction in computational overhead is essential for reducing false positives, allowing the autonomous system to act decisively when protecting the absolute core functions of the facility.

Zero-Latency Data Path Enforcement: eBPF, XDP, and DPUs

With the critical physical boundaries structurally secured via CCE, the architecture must establish a sensory and enforcement layer capable of intercepting malicious telemetry at absolute machine speed. Traditional software-based firewalls and Intrusion Prevention Systems (IPS) rely on the standard Linux kernel networking stack (such as Netfilter, iptables, or TC) to filter traffic36. However, processing packets through the standard kernel introduces significant latency due to required context switches, interrupt handling, and the heavy overhead of allocating Socket Buffers (SKBs) for every single packet36. When facing high-throughput volumetric attacks or ultra-fast lateral movement from a tool like PIPEDREAM, kernel-level latency can allow the adversary to execute logic before the firewall can drop the packet11. The architectural solution to this bottleneck is the implementation of the Extended Berkeley Packet Filter (eBPF) combined with the eXpress Data Path (XDP) framework36.

The Mechanics of eBPF and XDP

eBPF represents a revolutionary shift in Linux observability and networking. It functions as a highly restricted, sandboxed virtual machine embedded directly within the Linux kernel, allowing developers to execute user-defined programs without needing to write custom kernel modules or modify the kernel source code36. To ensure that these custom programs do not crash the system or create security vulnerabilities, the eBPF verifier subjects every program to incredibly rigorous syntactic and structural checks before it is allowed to load38. The verifier strictly prohibits unbounded loops, ensures that memory access never exceeds the actual boundaries of the packet, and limits the total number of instructions to guarantee that the program will execute and terminate in a predictable, microscopic timeframe38. XDP harnesses the power of eBPF to achieve unprecedented packet processing speeds. XDP provides an execution hook placed at the earliest possible point in the network stack—directly inside the network device driver36. When a packet arrives at the Network Interface Card (NIC), the XDP eBPF program executes instantly, fully bypassing the traditional kernel networking stack, the creation of SKBs, and metadata extraction36. The program evaluates the raw packet headers and payloads and renders an immediate verdict. XDP provides several highly efficient packet control actions:

  • XDP\_DROP: Discards the malicious packet instantly at the driver level. This requires near-zero CPU overhead, allowing the system to effortlessly drop millions of packets per second during a DDoS attack or an unauthorized PLC command injection37.
  • XDP\_PASS: Identifies the packet as benign and allows it to proceed upward into the standard Linux networking stack for normal application processing37.
  • XDP\_TX: Modifies the packet and immediately transmits it back out through the identical network interface from which it arrived37.
  • XDP\_REDIRECT: Forwards the packet directly to a different network interface, a specific CPU core, or a user-space application without kernel intervention37.

Execution Modes and Hardware Offloading via SmartNICs

The performance of XDP depends entirely on how and where the eBPF program is executed. There are three primary modes of operation: Generic XDP (which acts as a software fallback within the standard network stack, offering the lowest performance), Native XDP (where the program runs efficiently within the host’s NIC driver), and Offloaded XDP36. For the absolute zero-latency enforcement required in a nuclear-powered mega datacenter, Offloaded XDP is mandatory36. This is achieved by utilizing advanced SmartNICs or specialized Data Processing Units (DPUs), such as the NVIDIA BlueField architecture37.

XDP Execution ModeProcessing LocationPerformance Characteristics and Use Cases
Generic XDPHost OS Kernel Network StackActs as a hardware-agnostic software fallback. Used primarily for testing and development. High CPU overhead and lowest packet processing speed36.
Native XDPHost OS NIC DriverExecuted by the host CPU but before kernel stack allocation. Provides high performance, but still consumes host CPU cycles to process high-volume traffic36.
Offloaded XDPDirectly on SmartNIC/DPU Hardware (e.g., NVIDIA BlueField)The eBPF program is compiled and executed directly on the ASIC/FPGA of the network card itself. Delivers massive throughput (100+ Gbps) with absolute zero host CPU overhead36.

Table 4: Comparative analysis of XDP execution modes for network traffic filtering. Offloading the XDP programs directly onto DPUs achieves several critical objectives for cyber-physical protection:

1. Host CPU Preservation: By shifting complex telemetry extraction, flow sampling, and Deep Packet Inspection (DPI) down to the SmartNIC, the host CPU is entirely relieved of networking burdens37. This guarantees that the performance of critical datacenter applications and sensitive nuclear I\&C software remains highly deterministic and perfectly stable, even when the facility is under a massive volumetric attack41.

2. Absolute Microsegmentation: The DPU functions as an independent, physically isolated enforcement and computing complex41. Even if an adversary manages to completely compromise the host operating system using an advanced zero-day exploit or sophisticated Living-off-the-Land techniques, they are physically incapable of bypassing, tampering with, or disabling the security policies running on the SmartNIC41.

3. Sub-Microsecond Telemetry Generation: Beyond simply dropping traffic, the Offloaded XDP programs act as high-speed, pervasive sensors. They seamlessly extract packet headers, exact timing information, and precise flow characteristics, feeding this rich data directly into the autonomous artificial intelligence models36. This pre-filtering mechanism can isolate anomalous and malicious patterns in a median response time of 0.69 milliseconds, establishing the foundational data stream required for real-time AI decision-making39.

Autonomous Multi-Agent Cognitive Defense

While the physical boundaries are secured by CCE and the sensory and enforcement plane is established by XDP and DPUs, these are ultimately structural and rigid tools. The core intelligence of the protection architecture must be capable of analyzing millions of high-speed data points, deducing adversary intent, and executing complex defensive maneuvers autonomously. This necessitates a dramatic shift away from static, signature-based rules (which are easily evaded by novel attacks) toward dynamic, adaptive artificial intelligence using Multi-Agent Deep Reinforcement Learning (MADRL)8.

The Shift to Entity-Based Reinforcement Learning

Standard approaches to Deep Reinforcement Learning (DRL) often struggle in complex, real-world cybersecurity environments. Traditional RL algorithms represent the state of the network as a fixed-size vector and parameterize their decision-making policies using standard Multi-Layer Perceptrons (MLPs)44. This fixed-input architecture relies heavily on specific topologies; if the network changes—if servers are spun up, PLCs are added, or routing changes dynamically—the MLP-based agent cannot comprehend the new variables and fails to generalize, requiring extensive and impractical retraining44. To overcome this fatal limitation, cutting-edge autonomous defense relies on Entity-Based Reinforcement Learning, which profoundly changes how the AI perceives its environment44. By utilizing relational inductive bias and Graph Neural Networks (GNNs), the environment is decomposed into a collection of discrete entities (such as individual PLCs, datacenter servers, and SmartNICs), allowing the agent to understand the network dynamically as a graph44. The agent's defensive actions are executed and understood as direct graph edits (e.g., logically severing a compromised edge, reducing the vulnerability metric of a specific node, or restoring a system to a clean state)44. Because the AI focuses on the relational context of the entities rather than a rigid array of inputs, Transformer-based policies can seamlessly adapt to shifting datacenter layouts and dynamically added SMR components without performance degradation44. The profound efficacy of this graph-based, AI-driven approach is demonstrated by systems such as the Autonomous Intelligence Cyberdefense Agent (AICA), developed by Argonne National Laboratory and heavily tested by international experts at the North Atlantic Treaty Organization (NATO) Cyber Coalition exercises47. During these high-stakes simulated attacks on power microgrids, AICA continuously ingested raw network activity, system logs, and intrusion detection alerts to dynamically construct a sophisticated, multi-layered knowledge graph of the environment47. By understanding the complex, hidden relationships between the attack patterns, the network traffic flow, and the target systems, AICA provided unparalleled situational awareness, enabling both sophisticated human operator queries and completely automated, highly precise defensive responses47.

Mitigating the False Positive: The Causal Multi-Agent Decision Framework (C-MADF)

While single-agent RL systems like AICA represent a massive leap forward, relying on a monolithic agent to unilaterally shut down infrastructure creates a single point of failure and drastically increases the risk of the false-positive paradox8. Furthermore, many advanced RL agents still ultimately rely on correlation-based statistical signals. This makes them highly susceptible to deliberate telemetry poisoning or ambiguous inputs crafted by APTs to induce "reasoning drift"10. If an attacker subtly manipulates network traffic to create the illusion of an attack, a correlation-based AI might panic and isolate a critical cooling system, effectively doing the attacker's destructive work for them10. To definitively solve this, the defense architecture must implement the Causal Multi-Agent Decision Framework (C-MADF)10. C-MADF introduces a structurally constrained, adversarial approach to autonomous decision-making that mathematically eliminates unverified actions. It operates in four distinct, highly controlled stages:

1. Structural Causal Model (SCM) Generation: Instead of relying on raw statistical correlations that can be easily spoofed, C-MADF leverages historical telemetry to learn a deep Structural Causal Model (SCM)10. The SCM maps the true, physical causal dependencies between system variables (e.g., proving that a specific datacenter load request causally dictates a change in reactor coolant pump flow, rather than them merely occurring simultaneously)10.

2. MDP-DAG Compilation: The generated SCM is compiled into an investigation-level Directed Acyclic Graph (DAG)10. This DAG roadmap is then formalized as a Markov Decision Process (MDP) where the agent's action space is explicitly and aggressively restricted to causally consistent transitions10. The agent is mathematically barred from executing actions that violate the causal structure of the facility. It physically cannot shut down a critical safety system based on an unrelated anomaly in the IT application layer10.

3. Adversarial Dual-Policy Control (The Council of Rivals): Decision-making within this mathematically constrained DAG is never left to a single entity. C-MADF utilizes a sophisticated cooperative/adversarial MADRL setup featuring a Blue-Team policy and a counter-balancing Red-Team policy10. The Blue-Team agent is aggressively optimized to identify and neutralize threats at all costs, while the Red-Team agent acts as a conservative restraint, explicitly shaped to prioritize operational stability and minimize system disruption10.

4. Policy Divergence and Explainability Integration: Before any autonomous action is executed (such as ordering an XDP program to drop all traffic on a specific subnet), the Blue and Red agents deliberate. Their level of disagreement is quantified rigorously as a Policy Divergence Score10. This metric is combined with an Explainability-Transparency Score (ETS), which aggregates explanation quality, evidentiary sufficiency, and policy consistency10. If both agents agree and the ETS threshold is high, the action executes at machine speed. If uncertainty remains high and the agents diverge, the system refuses to act blindly, defaulting to a safe operational state or escalating to human supervisors as an early warning signal10.

The empirical performance of C-MADF validates this approach as essential for critical infrastructure. In rigorous evaluations utilizing real-world network data (such as the CICIoT2023 dataset), C-MADF demonstrated the ability to reduce false-positive rates from the 8.4%–11.2% range commonly seen in traditional monolithic defense pipelines down to an astonishing 1.8%10. Furthermore, it achieved this dramatic reduction in noise while simultaneously maintaining a 0.997 precision, 0.961 recall, and 0.979 F1-score10. By embedding strict causal logic and adversarial debate into the autonomous response cycle, C-MADF ensures that machine-speed defense mechanisms relentlessly protect the facility without causing self-inflicted disruption.

Cyber-Physical Transients and Kinetic Stabilization

The integration of advanced software, DPUs, and multi-agent AI does not suspend the physical laws governing the systems they protect. If a sophisticated adversary succeeds in compromising a segment of the network, or if an emergency autonomous intervention by C-MADF intentionally severs a massive portion of the datacenter's power draw to isolate an infection, the co-located SMR is subjected to an immediate, violent cyber-physical transient21. A sudden load rejection (the datacenter going offline instantly) or a massive, synchronized load surge causes extremely rapid and dangerous fluctuations in electrical frequency and voltage across the microgrid52. Because SMR-powered microgrids are frequently designed to operate autonomously in islanded modes (disconnected from the centralized macro-grid), they possess inherently low rotational inertia compared to traditional national power grids54. Traditional backup power solutions, such as diesel generators or slow-ramping chemical Battery Energy Storage Systems (BESS), simply cannot react swiftly enough to arrest the steep Rate of Change of Frequency (ROCOF)55. If ROCOF exceeds critical thresholds, it will trigger an automatic reactor scram, induce severe thermal and mechanical stress on the nuclear core, and potentially lead to cascaded infrastructure failure55.

Flywheel Energy Storage Systems (FESS)

To construct an autonomous protection architecture that remains resilient across both the digital and physical domains, the system must deploy instantaneous kinetic stabilization. Exhaustive studies, including detailed microgrid frequency assessments of islanded power systems (such as those conducted on the Galapagos Islands), have definitively proven that Flywheel Energy Storage Systems (FESS) provide the optimal, high-performance solution for managing these extreme cyber-induced load transients54. A flywheel stores massive amounts of energy kinetically in the form of a heavy rotating mass, which is suspended on advanced, virtually frictionless magnetic bearings operating within a vacuum chamber56. When the autonomous C-MADF agent identifies an attack and preemptively severs a compromised datacenter segment, the resulting sudden drop in electrical load threatens to over-frequency the SMR54. The FESS can absorb this excess, dangerous power in milliseconds by rapidly accelerating its rotor54. Conversely, if a cyberattack physically disables a primary power feed, the FESS instantly discharges its kinetic energy, providing high-density, uninterrupted ride-through power to maintain critical reactor cooling pumps and IT data persistence until secondary diesel or BESS systems can initialize57. The integration of FESS into the nuclear-datacenter microgrid yields several irreplaceable advantages over standard lithium-ion or lead-acid BESS deployments:

Capability MatrixFlywheel Energy Storage Systems (FESS)Battery Energy Storage Systems (BESS)
Response TimeUltra-fast; toggles from charging to discharging in under 10 milliseconds57.Moderate; typically 100 to 1,000 milliseconds, missing the critical initial transient window60.
Cycle Life & DegradationInfinite cycling capability; no capacity degradation over a 20+ year lifespan regardless of depth of discharge54.High degradation; continuous frequency control and rapid load cycles severely reduce battery lifetime and induce thermal runaway risks54.
Grid Inertia ProvisionProvides direct, physical synthetic inertia to the microgrid, inherently dampening frequency deviations and arresting ROCOF instantly54.Lacks true inertia; relies on delayed digital inverters to synthesize response, providing no support for the critical first 100 to 500 milliseconds60.
Environmental ImpactHighly sustainable; relies on steel/composite rotors and magnetic bearings without toxic or hazardous chemicals54.High environmental footprint; requires extensive chemical mining, specialized disposal, and rigorous HVAC cooling to prevent overheating54.

Table 5: Comparative analysis of kinetic (FESS) versus chemical (BESS) energy storage for cyber-physical transient mitigation. By intimately coupling the sub-microsecond digital response of XDP/eBPF data filtering with the millisecond kinetic response of FESS, the architecture ensures that the facility can effortlessly absorb and survive the devastating shockwaves of both the cyberattack and the necessary defensive maneuver36.

Layer 1 Hardware Isolation and Continuous HIL Validation

While dynamic artificial intelligence and kinetic buffering handle active, unfolding threats, the architecture must also comprehensively address persistent, structural physical vulnerabilities. The rapid expansion of connected IIoT devices in modern nuclear facilities introduces severe Layer 1 (Physical Layer) blind spots6. Standard security tools operating at Layer 2 (Data Link) and above—even advanced ones—cannot detect malicious hardware trojans, unauthorized rogue devices, or compromised supply chain components operating below the operating system level6.

Deterministic Hardware Data Diodes

To strictly enforce the operational boundaries defined during the foundational CCE phases, and to permanently mitigate Layer 1 threats, the architecture must mandate the utilization of hardware data diodes between the IT datacenter networks and the most critical SMR OT environments63. A data diode is a physical, hardware-based cybersecurity device that strictly enforces a one-way flow of data63. By utilizing absolute optical isolation—typically featuring a laser transmitter exclusively on the highly secure OT side and a photodetector receiver exclusively on the less secure IT side, with no physical capability to send light backward—data diodes guarantee deterministic separation19. This ensures that vital operational telemetry, such as reactor core temperature, pump status, and power output, can be continuously streamed to the datacenter and the C-MADF AI agents for comprehensive monitoring, but absolutely no command logic, TCP acknowledgments, or malware can physically traverse back into the reactor control systems19. This hardware-level determinism inherently satisfies the most stringent regulatory requirements, such as the NRC's 10 CFR 73.54, by physically obliterating the attack pathways to the facility's critical digital assets19.

Hardware-in-the-Loop (HIL) Emulation and Validation

Deploying this incredibly complex, highly interdependent architecture—where AI agents residing on NVIDIA DPUs command real-time eBPF networking changes that subsequently induce kinetic flywheel responses—cannot be safely validated through software simulation alone25. Theoretical models invariably fail to account for the minute timing discrepancies and physical realities of actual hardware. Therefore, the final foundational pillar of the autonomous protection strategy is continuous Hardware-in-the-Loop (HIL) testing3. HIL testbeds create a meticulously controlled, secure environment by integrating the actual physical hardware components (such as Siemens S7 1500 PLCs, BlueField DPUs, and optical data diodes) with high-fidelity, multiphysics software simulations of the nuclear reactor core and the datacenter electrical loads66. Through advanced platforms like the ARCADE (Advanced Reactor Cyber-Physical Analysis) framework and the Asherah NPP (Nuclear Power Plant) simulator, operators establish bidirectional communication using standard industrial protocols like OPC-UA3. This hybrid physical-virtual ecosystem allows security engineers to safely inject malicious scripts and execute full PIPEDREAM emulations against the physical PLCs, measuring the exact, real-time cyber-kinetic impact on the simulated reactor3. Crucially, continuous HIL validation allows the C-MADF algorithms to be rigorously trained and calibrated against actual hardware latencies and physical transients. This ensures that the Policy Divergence Scores and autonomous responses formulated by the AI are deeply grounded in physical reality, thoroughly de-risking the technology prior to commercial deployment and ensuring the architecture functions flawlessly when a true crisis emerges3.

Works cited

1. Nuclear Powered Data Centers: Microsoft Bets on SMRs to Fuel the Cloud, https://www.captechu.edu/blog/nuclear-powered-data-centers-microsoft-bets-smrs-fuel-cloud

2. Demand for data centers soars; could small modular reactors meet the need? \- ASCE, https://www.asce.org/publications-and-news/civil-engineering-source/article/2025/12/17/demand-for-data-centers-soars-could-small-modular-reactors-meet-the-need

3. Bridging the Gap for Powering Data Centers \- Idaho National Laboratory, https://inl.gov/content/uploads/2026/01/Bridging-the-Gap-for-Powering-Data-Centers.pdf

4. IEEE PES Technical Roadmap 2024 | PDF | Distributed Generation | Electrical Grid \- Scribd, https://www.scribd.com/document/787502596/IEEE-PES-ROADMAP

5. Simulating Collaboration in Small Modular Nuclear Reactor Cybersecurity with Agent-Based Models \- MDPI, https://www.mdpi.com/2624-800X/5/4/83

6. Nuclear Cyber Security: Protecting Nuclear Facilities from Modern Cyber Threats \- Sepio, https://sepiocyber.com/resources/whitepapers/nuclear-cybersecurity/

7. The Impact of IT-OT Convergence on ICS Security \- Palo Alto Networks, https://www.paloaltonetworks.com/cyberpedia/the-impact-of-it-ot-convergence

8. Multi-Agent Reinforcement Learning in Cybersecurity: From Fundamentals to Applications This research is supported by armasuisse Science and Technology. \- arXiv, https://arxiv.org/html/2505.19837v1

9. Incontroller, the intelligent menace | INCIBE-CERT, https://www.incibe.es/en/incibe-cert/blog/incontroller-intelligent-menace

10. \[2604.04442\] Explainable Autonomous Cyber Defense using Adversarial Multi-Agent Reinforcement Learning \- arXiv, https://arxiv.org/abs/2604.04442

11. Whitepaper \- PIPEDREAM: CHERNOVITE'S EMERGING MALWARE TARGETING INDUSTRIAL CONTROL SYSTEMS \- CyberScoop, https://cdn.cyberscoop.com/pipedream-chernovite-emerging-malware-targeting-ics.pdf

12. Dragos estimates that Chernovite's Pipedream malware targets ICS networks, https://industrialcyber.co/threats-attacks/dragos-estimates-that-chernovites-pipedream-malware-targets-ics-networks/

13. How SMRs reshape data center design, security, power \- ArchiLabs, https://archilabs.ai/posts/how-smrs-reshape-data-center-design-security-power

14. Enhancing Computer Security of Small Modular Reactors and Microreactors. | IAEA, https://www.iaea.org/projects/crp/j02021

15. International Conference on Nuclear Security 2020 (10-14 February 2020): Contribution List, https://conferences.iaea.org/event/181/contributions/

16. DOE OE 2021 Strategy White Papers on Microgrids \- OSTI, https://www.osti.gov/servlets/purl/2432239

17. Building Nuclear-Specific Cybersecurity Expertise in Higher Education, https://journal.cisse.info/jcisse/article/download/223/223

18. Layered Attack Surface Model for Digital Assets of Nuclear Power Plants, https://epubs.ans.org/download/?a=53741

19. IAEA Nuclear Energy Series Computer Security Aspects of Design for Instrumentation and Control Systems at Nuclear Power Plants, https://www-pub.iaea.org/MTCD/Publications/PDF/P1870\_web.pdf

20. Attack Surface Analysis of the Digital Twin and Advanced Sensor and Instrumentation Interfaces \- INL Digital Library \- Idaho National Laboratory, https://inldigitallibrary.inl.gov/sites/sti/sti/Sort\_74726.pdf

21. Cyber-Physical Tabletop Exercise for Small Modular Reactor Facilities \- OSTI.GOV, https://www.osti.gov/biblio/2999080

22. Detecting CHERNOVITE's PIPEDREAM with the Dragos Platform, https://www.dragos.com/blog/detecting-chernovites-pipedream-with-the-dragos-platform

23. CHERNOVITE's PIPEDREAM Malware Targeting Industrial Control Systems (ICS) \- Dragos, https://www.dragos.com/blog/chernovite-pipedream-malware-targeting-industrial-control-systems

24. Analyzing PIPEDREAM: Results from Runtime Testing \- Dragos, https://www.dragos.com/blog/analyzing-pipedream-results-from-runtime-testing

25. Advanced Reactor Cyber Analysis and Development Environment (ARCADE) for System-Level Design Analysis \- OSTI.GOV, https://www.osti.gov/servlets/purl/2430308

26. False positives: detection and protection \- Stormshield, https://www.stormshield.com/news/the-issue-of-false-positives-in-cybersecurity/

27. Understanding False Positives in Cybersecurity \- Check Point Software, https://www.checkpoint.com/cyber-hub/cyber-security/understanding-false-positives-in-cybersecurity/

28. False Positives in Cybersecurity: The SOC Analyst's Guide to Detection, Impact, and Mitigation \- CyberDefenders, https://cyberdefenders.org/blog/false-positives-in-cybersecurity/

29. False Positives in Cybersecurity: Causes, Costs, and Fixes | Corelight, https://corelight.com/resources/glossary/false-positives-cybersecurity

30. Autonomous Defense at the Moment of Attack: RaDome Edge Defense and Distributed Threat Intelligence \- RaTurka, https://raturka.com/en/blog/autonomous-defense-at-the-moment-of-attack-radome-edge-defense-and-distributed-threat-intelligence

31. Achieving Resilience Through the Preservation of Functions | blog.mitcdh, https://blog.mitcdh.au/posts/preserving-functions/

32. Senate Report 118-72 \- ENERGY AND WATER DEVELOPMENT APPROPRIATIONS BILL, 2024 \- GovInfo, https://www.govinfo.gov/content/pkg/CRPT-118srpt72/html/CRPT-118srpt72.htm

33. CCE Phase 3: Consequence-based Targeting \- INL Digital Library, https://inldigitallibrary.inl.gov/sites/sti/sti/Sort\_24535.pdf

34. CCE Phase 1: Consequence Prioritization \- INL Digital Library \- Idaho National Laboratory, https://inldigitallibrary.inl.gov/sites/sti/sti/Sort\_24533.pdf

35. FY 2025 Congressional Justification \- Department of Energy, https://www.energy.gov/sites/default/files/2024-03/doe-fy-2025-budget-vol-2-v4.pdf

36. eBPF XDP: The Basics and a Quick Tutorial \- Tigera.io, https://www.tigera.io/learn/guides/ebpf/ebpf-xdp/

37. A Novice's Guide to Crafting a Linux Firewall with XDP and a Comparison with Peer Technologies: TC and Cgroup SKB \- Oracle Blogs, https://blogs.oracle.com/linux/ebpf-firewall-xdp

38. Achieving high-performance, low-latency networking with XDP: Part I | Red Hat Developer, https://developers.redhat.com/blog/2018/12/06/achieving-high-performance-low-latency-networking-with-xdp-part-1

39. Performance Implications of Packet Filtering with Linux eBPF | Request PDF \- ResearchGate, https://www.researchgate.net/publication/328374485\_Performance\_Implications\_of\_Packet\_Filtering\_with\_Linux\_eBPF

40. Whitepaper: Acronym Overload / Blog \- Pathgate, https://www.pathgate.nl/blog/whitepaper-acronym-overload

41. A Comprehensive Survey on SmartNICs: Architectures, Development Models, Applications, and Research Directions \- arXiv, https://arxiv.org/html/2405.09499v1

42. NVIDIA BlueField DPU for Storage \- simplyblock, https://simplyblock.io/glossary/nvidia-bluefield-dpu/

43. Multi-Agent Actor-Critic in Autonomous Cyber Defense \- arXiv, https://arxiv.org/html/2410.09134v2

44. Entity-based Reinforcement Learning for Autonomous Cyber Defence \- arXiv, https://arxiv.org/html/2410.17647v3

45. The Path To Autonomous Cyber Defense \- arXiv, https://arxiv.org/html/2404.10788v1

46. Automated Cyber Defense with Generalizable Graph-based Reinforcement Learning Agents, https://arxiv.org/html/2509.16151v1

47. International experts put Argonne's cybersecurity defense software through the wringer at NATO's Cyber Coalition 2022, https://www.anl.gov/article/international-experts-put-argonnes-cybersecurity-defense-software-through-the-wringer-at-natos-cyber

48. Identified themes for investigating cybersecurity of C3I systems \- ResearchGate, https://www.researchgate.net/figure/dentified-themes-for-investigating-cybersecurity-of-C3I-systems\_fig3\_362766258

49. Analysis approaches vs. data types. | Download Scientific Diagram \- ResearchGate, https://www.researchgate.net/figure/Analysis-approaches-vs-data-types\_fig4\_362958068

50. Explainable Autonomous Cyber Defense using Adversarial Multi-Agent Reinforcement Learning \- arXiv, https://arxiv.org/html/2604.04442v1

51. The architecture of the Causal Multi-Agent Decision Framework (C-MADF).... | Download Scientific Diagram \- ResearchGate, https://www.researchgate.net/figure/The-architecture-of-the-Causal-Multi-Agent-Decision-Framework-C-MADF-The-process\_fig2\_403561874

52. New CRP: Enhancing Computer Security of Small Modular Reactors and Microreactors (J02021) | IAEA, https://www.iaea.org/newscenter/news/new-crp-enhancing-computer-security-of-small-modular-reactors-and-microreactors

53. Aegis and Ontario Tech Advance Secure Nuclear-Hybrid Power for Marine Applications, https://www.newsfilecorp.com/release/309285/Aegis-and-Ontario-Tech-Advance-Secure-NuclearHybrid-Power-for-Marine-Applications

54. Flywheel energy storage system based microgrid controller design and PHIL testing, https://www.researchgate.net/publication/361038174\_Flywheel\_energy\_storage\_system\_based\_microgrid\_controller\_design\_and\_PHIL\_testing

55. Publication: Flywheel energy storage system to fast-frequency response provision on insular power systems from a microgrid perspective \- DSpace Repository, https://dspace.ucuenca.edu.ec/entities/publication/e4f4eb17-9c4d-4c0b-b0a5-db71cdee1119

56. Flywheel Energy Storage System to fast-frequency response provision on insular power systems from a microgrid perspective | Request PDF \- ResearchGate, https://www.researchgate.net/publication/366914387\_Flywheel\_Energy\_Storage\_System\_to\_fast-frequency\_response\_provision\_on\_insular\_power\_systems\_from\_a\_microgrid\_perspective

57. Flywheel Energy Storage for Data Center Backup, https://eureka.patsnap.com/report-flywheel-energy-storage-for-data-center-backup

58. Flywheel Energy Storage Systems for Ride-through Applications in a Facility Microgrid \- Advanced Research Institute \- Virginia Tech, https://ari.vt.edu/content/ari\_vt\_edu/en/publications\_archive/flywheel-energy-storage-systems-for-ride-through-applications-in/\_jcr\_content/content/download/file.res/06294476.pdf

59. Quantum Energy Storage Redesigns the Flywheel for Microgrids \- eprsquared.com, https://www.eprsquared.com/quantum-energy-storage-redesigns-the-flywheel-for-microgrids/

60. WhitePaper-Benefits of Fast Reacting FlyWheels for Microgrids 31Aug2017 \- Stornetic, https://www.stornetic.com/wp-content/uploads/2022/03/d-WhitePaper-Benefits-of-Fast-Reacting-FlyWheels-for-Microgrids-11Sep2017-000000000006560-2.pdf

61. How Industrial Cybersecurity Works in 2025 | Real World Examples, https://waterfall-security.com/ot-insights-center/ot-cybersecurity-insights-center/industrial-cyber-security/

62. Hardware Trojan Dataset of RISC-V and Web3 Generated with ChatGPT-4 \- MDPI, https://www.mdpi.com/2306-5729/9/6/82

63. Air-Gapped Knowledge Base: Definition & Best Practices (2026), https://www.docsie.io/blog/glossary/air-gapped-knowledge-base/

64. Light Water Reactor Sustainability Program An Integrated Risk Assessment Process for Digital Instrumentation and Control Upgrades of Nuclear Power Plants \- INL Digital Library \- Idaho National Laboratory, https://inldigitallibrary.inl.gov/sites/sti/sti/Sort\_18698.pdf

65. Aegis Critical Energy MOU on hybrid SMR-BESS systems | QESSF Stock News, https://www.stocktitan.net/news/QESSF/aegis-critical-energy-defence-malahat-energy-systems-and-ontario-frspxjoo8ear.html

66. A hardware-in-the-loop framework for remote monitoring of safety critical systems \- White Rose Research Online, https://eprints.whiterose.ac.uk/id/eprint/225575/1/3703790.3703823.pdf

67. A Hardware-in-the-Loop Framework for Remote Monitoring of Safety Critical Systems, https://www.researchgate.net/publication/390549880\_A\_Hardware-in-the-Loop\_Framework\_for\_Remote\_Monitoring\_of\_Safety\_Critical\_Systems