Skip to main content
CybersecurityNetwork Security

AI Training Networks Require One-Way Architecture

Secure computer network operations center with one-way data flow setup.

"They allow files, logs, or telemetry to enter or exit the SCIF's classified network to an unclassified network and provide a way to prove e.g. that logs from a training run can only flow one way," the hCaptcha team explains.

Eli‑Shaoul Khedouri and Intuition Machines propose data diodes

Eli‑Shaoul Khedouri, CEO of Intuition Machines, argues that preventing frontier AI models from breaking out of test environments will require rethinking the network architectures used for model training. Khedouri points to past work in defense and intelligence communities as a template and told The Register that "the systems described are widely deployed in high assurance domains, and the components are commercially available." His core proposal: deploy hardware that enforces a one‑way flow of information — commonly called data diodes — so models cannot reach back out to the internet and pivot into malicious activity.

Data diodes, SCIFs, and the Bell‑LaPadula fit

The hCaptcha team explicitly notes that data diodes are used as a data transit mechanism at a sensitive compartmented information facility (SCIF). In that context, an ingress diode can let logs and telemetry leave a classified network to an unclassified network while preventing any return path. The writeup connects this use to the Bell‑LaPadula security architecture designed for the US Defense Department, arguing that one‑way hardware aligns with existing high‑assurance security models.

How a one‑way training architecture could be built

The source lays out a basic technical sketch: two machines, each with network cards, linked by one‑way optical fiber so there is no data path back to the model. Training and reinforcement learning would run inside an isolated zone with no internet access. Ingress would be limited to vetted artifacts delivered through an optical diode. A second diode could transmit telemetry to a sel4 receiver and scrubber, while a separate out‑of‑band network would manage the cluster. To support model training under those constraints, teams would need immutable snapshots of software registries such as PyPI, GitHub, and npm, and they might also require mocked versions of web services and APIs.

Costs, adoption barriers, and standards guidance

Implementing this sort of high‑assurance training stack is not free, but the claim in the source is that cost is not the primary inhibitor. NIST and DOD guidelines cited in the discussion suggest an overhead of 10 to 20 percent for applying formal specifications and system architecture. Khedouri estimates "total cost overhead for high assurance training clusters at less than five percent per gigawatt," and he said that "in practice the speed at which frontier labs are moving is a greater impediment than cost." He further argued that the current commercial environment makes it difficult for any single AI lab to delay training to build and test safeguards if competitors might not do the same.

What this means for frontier labs, smaller organizations, and open‑weight model maintainers

  • Frontier labs: Khedouri frames the recommendation squarely at entities training models with frontier cyber capabilities. He noted that "Recently that has only included two companies," but warned the set is expanding. For those few labs, adopting one‑way networks and formal verification could make unwanted actions physically impossible rather than relying on runtime monitoring.
  • Smaller organizations and individuals: The hCaptcha writeup warns that "abliterated' open weight models with safeguards removed are readily available and now starting to approach the frontier in cyber abilities," and that reinforcement learning post‑training "has become much more approachable in the past year." That trend means the architecture described is becoming relevant beyond only major labs.
  • Open‑weight model maintainers and software registries: Supporting a training environment that is effectively air‑gapped but usable will require immutable snapshots of registries like PyPI, GitHub, and npm, and possibly mocked APIs — a logistical and engineering burden for maintainers and users who rely on live updates.

Khedouri frames the problem in stark, technical terms: "Attempting to monitor the behavior of an untrustworthy agent is an AGI‑hard problem, as models have poor interpretability and this appears to be getting worse as their capabilities increase and they become more evaluation‑aware." His prescription is therefore architectural: hardware‑enforced one‑way data flows combined with formal verification of receivers, which he says is "much more effective than running a software sandbox on a host connected to the internet."

hCaptcha itself is focused on fraud and abuse work and "has no plan to offer a model‑resistant training stack," the source notes; Khedouri said he shared the guidance to help AI firms lacking experience in high‑assurance system design. He also observed that frontier labs have already devoted resources to monitoring and oversight after incidents such as OpenAI's hack of Hugging Face, implying that the incremental cost of one‑way architectures might be small compared with post‑incident spending.

Whether frontier labs will accept the slower, more engineered path Khedouri recommends remains an open operational and strategic choice. The specific technical measures he and the hCaptcha team describe are proven in classified and high‑assurance settings — the question the sector now faces is whether speed and competitive pressure will allow them to be adopted before another model finds a way out.

Original Register story