Architecting Unidirectional Data Sync Across Isolated OT Zones Using Monitored Hot Folders

The Architectural Chasm: Why Webhook/API Models Collapse Under Critical Infrastructure Regulation

Every cloud automation vendor—Make, Tines, Torq, Palo Alto XSOAR—assumes a fundamental architectural precondition: bidirectional, authenticated API connectivity between orchestrator and target. The orchestrator issues an HTTPS POST; the target responds with a 200 OK. Simple. Elegant. And entirely illegal inside any OT network governed by IEC 62443, NERC CIP, or Israeli NISA Directive 7.

Critical infrastructure networks operated by Israel Electric Corporation, Mekorot, the Israel Ports Company, and defense-adjacent facilities enforce strict unidirectional data flow. The physics are non-negotiable: data may exit the OT zone for monitoring purposes, but no external system may initiate a connection into the operational technology perimeter. This is not a firewall rule that can be adjusted with a change request. It is a regulatory mandate enforced by hardware data diodes, physically severed return paths, and continuous compliance auditing.

The Vendor Compliance Matrix

Below is a factual assessment of how mainstream automation platforms fare against critical infrastructure network topology requirements:

The implication is clear: cloud automation is architecturally incompatible with regulated OT environments. The question is not whether these platforms are useful—they are, in IT contexts. The question is whether they can legally and physically operate across the IT/OT divide. They cannot.

The "Hot Folder" Design Pattern: Cyberm8's Unidirectional Cyberm8 Architecture

Cyberm8 solves the IT/OT automation challenge through a design pattern borrowed from decades of secure file transfer in defense and intelligence communities: the monitored hot folder.

The architecture is deliberately simple. Simplicity is not a limitation—it is a security property. Every additional protocol, handshake, or session state introduced between zones is an attack surface. Cyberm8's approach minimizes attack surface to a single, read-only file share monitored by inotify-equivalent watchers.

Action Sequence

1. Configuration Compilation. The Cyberm8 orchestrator in the IT zone compiles an automation workflow into a predictable, self-contained JSON instruction set. No external dependencies. No runtime API calls.
2. Cryptographic Signing. The compiled payload is signed with a SHA-256 hash and an organization-specific asymmetric key. The Cyberm8 component in the OT zone holds the corresponding public key and will reject any payload that fails verification.
3. Hot Folder Drop. The signed payload is written to a monitored file share (SMB or NFS) located in the DMZ or data-diode staging area. The IT-side orchestrator has write-only permissions. The OT-side Cyberm8 component has read-only permissions. No bidirectional session is ever established.
4. Cyberm8 Consumption. The containerized Cyberm8 component running inside the OT zone detects the new file via filesystem event monitoring (inotify/kqueue equivalent). It verifies the cryptographic signature, validates the instruction schema, and executes the approved configuration against local OT assets.
5. Audit Trail. Every step—compilation, signing, file drop, consumption, action, and result—is logged to an clear, append-only audit store. Compliance officers receive a complete chain of custody for every automated action.

The AI-to-Predictable Pipeline: Addressing the Risk Officer's Legitimate Concern

We understand the concern. Every CISO in Israel's critical infrastructure sector has the same question: "You claim to use AI. How do I know a probabilistic model isn't making configuration decisions inside my OT network?"

It is a legitimate, important question. Here is the precise answer.

Cyberm8's conversational AI assistant, Cody AI, operates exclusively in the design phase. It assists human operators in constructing automation logic through natural-language interaction. Think of it as an intelligent IDE autocomplete for security workflows—not an autonomous decision-maker.

The Strict Separation

The AI never touches the run path. The compiled configuration is a frozen, clear artifact—version-controlled in Git, cryptographically signed, and schema-validated before Cyberm8 will accept it. Cyberm8 does not interpret instructions. It executes byte-identical configurations.

GitOps as the Compliance Record

Every configuration that reaches the OT zone exists as a committed, tagged artifact in a Git repository. Compliance auditors can diff any two versions, review approval histories, and verify that what was executed matches exactly what was approved. There is no "runtime drift." There is no "AI hallucination risk." The configuration is a file. The file is signed. The signature is verified. The action is predictable.

Validate the Architecture in Your Environment

We understand that critical infrastructure operators do not make technology decisions based on whitepapers. You need to see zero-inbound data transit demonstrated live, in a topology that mirrors your actual network segmentation.

Cyberm8 offers a 3-hour workflow proof designed specifically for regulated infrastructure teams. This is not a sales demo. It is an isolated, remote lab testing session where your engineering team validates:

1. Zero inbound ports. Packet capture verification that no connection is initiated from the IT zone into the OT zone during the entire session.
2. Cryptographic payload integrity. Live demonstration of tamper detection when a payload is modified in transit.
3. Repeatable action. Side-by-side comparison of the compiled JSON instruction and the actual configuration applied to a simulated OT asset.
4. Audit trail completeness. Full chain-of-custody log export compatible with your existing compliance reporting toolchain.