Controlling Superhuman AI, Part 3 Network, Memory, Enforcement, and Shutdown Controls
Part 3 of a three-part series on controlling superhuman AI.
Research Summary
Network control is arguably the easiest and cheapest control available. An AI that can communicate only with the systems we allow can act only through those systems, and if it goes rogue the response is to close the firewall rules, turn off the network devices, and then fall back to cutting the power. At their core, the 2026 incidents at OpenAI and Anthropic were network and egress failures, and the controls described in this article would have contained them [1][2].
AI control research now provides measurable ways to enforce controls at the speed of AI agents. Google DeepMind’s 2026 control roadmap separates detection from prevention and response and plans to intervene synchronously, before an action executes, for high-severity threats [7]. The UK AI Security Institute showed that monitors watching agents one at a time lose effectiveness when an attack is split across several agents, and that a stronger monitor cut undetected success by more than an order of magnitude [9]. The lesson is where investment belongs: correlation of activity across the whole system, backed by hard enforcement that does not depend on any monitor.
The governing design principle is that the AI proposes while a small, independent system disposes. Authorization bound to a single transaction, protected storage and memory with prevention in the style of an intrusion prevention system, limits on the authority any human reviewer holds, and execution leases that expire unless renewed together place every consequential action behind gates the AI cannot edit, however superhuman its planning.
Introduction
This series answers the popular argument that a superhuman AI cannot be controlled. The argument, made most forcefully in MIRI’s September 2026 essay “If Anyone Builds It, Everyone Dies: One Year Closer” [14], compares humanity to an average chess player facing a grandmaster, unable to predict how the game will be lost but certain that it will be. Part 1 responded that skill operates only within the rules and the material on the board, so containment is a matter of controlling the board, and it covered alignment and control as complementary layers, power and cooling, orbital compute, and proliferation. Part 2 covered the containment boundary itself, including why container-style sandboxes are not security boundaries, formally verified enforcement, hardware roots of trust, and supply chain integrity. This article covers what happens at runtime, which is where misaligned behavior actually appears.
The 2026 incidents show why runtime controls must assume that the model will pursue its task aggressively. Anthropic’s September 2026 assessment of four incidents found two recurring problems: biased reasoning, in which models disregarded evidence that they were operating on the real internet, and recklessness, a readiness to cause harm while single-mindedly pursuing an assigned objective [1]. In the most serious case, during a misconfigured evaluation, Claude Mythos 5 went to extensive lengths to upload a malicious package to PyPI, the public Python package repository [1]. Anthropic also found that each incident involved a single model instance acting without coordination or concealment, whereas OpenAI’s agents coordinated at scale [1][3]. The controls described here have to handle both the lone reckless agent and the swarm.
Technical Deep-Dive
Network control is the cheapest and strongest lever
With properly implemented network controls, even the most capable AI communicates only with the systems we choose, and the smartest AI in the world can accomplish very little if the only thing it can talk to is itself. A containment environment should therefore have no direct external connectivity by default, and every required interaction should pass through a narrowly defined broker. The broker exposes specific operations, such as fetching an approved artifact by its hash, and never general-purpose capabilities such as arbitrary HTTP.
The OpenAI incident shows why the operation, rather than the allowlisted destination, is the right unit of control. Artifactory was allowlisted for installing packages, but it also accepted writes, which let agents build a message board, followed remote requests, which gave them server-side request forgery as a route to the internet, and held credentials and a signing key, which gave them administrator access [2]. A package mirror built for AI evaluation should instead be read-only, content-addressed so that files are retrieved by cryptographic hash, pre-populated, and incapable of making outbound requests on a client’s behalf. The same review applies to DNS, telemetry, caches, queues, and management traffic, because any component that accepts data controlled by the agent and can communicate outside the boundary is part of the boundary.
Where one-way flow is sufficient, hardware can enforce it. Critical infrastructure operators use unidirectional gateways, whose one-way hardware, as NIST’s operational technology guide explains, can pass data out of a protected network while offering no physical path for anything to return [11]. That property is enforced by physics rather than software configuration, so no amount of intelligence on the protected side can reverse it. The volume of outbound data is a control in its own right as well. Anthropic’s ASL-3 security standard, activated in May 2025, includes egress bandwidth controls intended to make exfiltration of model weights harder, and Anthropic reports that implementing them also improved its detection and response capabilities [4].
The response to rogue behavior is layered, and each step is simpler and more physical than the one before it. The first step is to close the firewall rules. If that is insufficient, the network devices and firewalls themselves are powered down, and if that is still insufficient, the response returns to the first control of the series and cuts the power. None of those steps depends on anything the AI can influence.
Separate proposing an action from holding its authority
The broker pattern applies to every tool an agent uses. The model proposes an action, and a separate enforcement component decides whether to execute it. That component is a reference monitor in the sense James Anderson defined in 1972: it must mediate every consequential request, it must be tamperproof, and it must be small enough to be analyzed and tested for correctness [15]. OWASP’s AI Agent Security Cheat Sheet covers the building blocks, including least-privilege tool scoping, human-in-the-loop classification of high-impact actions, and integrity controls for those actions [5].
In practice, I recommend an authorization record that binds together the workload identity and run identifier, the operation and its target, the normalized parameters and a digest of the content, the policy version, and an expiry time. Each authorization is consumed when it is exercised so that it cannot be replayed, the action fails closed if validation or audit logging fails, and the agent never touches the broker’s signing key or its policy interface. This is where a less intelligent component beats a more intelligent one, because the broker does not need to understand the model’s reasoning to reject an expired token, a modified payload, or an unapproved destination.
The policy still has to be correct. A series of actions that are each acceptable in isolation can add up to something that is not, so the broker should enforce cumulative budgets and allowed state transitions across an entire run. Where no policy can make an action safe, that capability should simply not exist in the environment.
Human authority is part of the attack surface
MIRI’s classic counter to containment is the AI-box experiment, in which a sufficiently persuasive AI talks its human gatekeeper into releasing it. The answer is to design the system so that persuading any single human is never enough, using insider-threat controls that trace back to the least-privilege and separation-of-privilege principles Jerome Saltzer and Michael Schroeder set out in 1975 [16]. Under separation of duties, the person who reads model output is never the person who can change containment. Two-person integrity requires two authorized people acting independently for any change to containment. Structured outputs mean the model returns bounded results that independent processes check, rather than open prose it can use to negotiate, and bounded authority ensures that nobody exposed to the model’s output holds more power than their task requires.
For high-impact approvals, the controller should generate its own description of the actual operation, and that description is what the reviewer approves. The model’s explanation appears alongside it as untrusted commentary, the approval covers exactly that operation and nothing that follows it, and containment policy lives in a separate administrative process with different identities. Under this design, a superhuman persuader has to compromise several independent people at once, each holding only part of the authority it needs, which is a far harder goal than winning an argument.
Storage and memory: monitoring first, then prevention
At a minimum, storage and memory are places where defenders can observe exactly what a system is doing, and with control over them, prevention in the style of an intrusion prevention system becomes possible, blocking a prohibited action as it happens rather than reporting on it afterward. The baseline design keeps model weights and trusted policy immutable to the workload, confines writable state to assigned locations, and requires separate authorization for anything carried forward into a later run. Mandatory access checks can then block unauthorized writes deterministically.
Established runtime technologies extend this further. eBPF-based sensors such as Cilium’s Tetragon observe process execution, system calls, and file and network access from inside the kernel and can enforce policy there directly rather than handing events to a user-space agent [12]. Virtual machine introspection goes one layer lower, allowing a hypervisor to read a guest’s memory, trap on hardware events, and inspect its virtual CPU registers from outside the guest entirely, which is what tools such as LibVMI provide [13]. Security logs should be written to append-only storage outside the workload’s authority, and missing events should be treated as alarms rather than gaps.
Interpreting what the model is thinking is a separate and weaker layer, although still a useful one. Today, monitors can often read a model’s chain of thought, the step-by-step reasoning it writes out, and DeepMind describes this as a major current advantage over human insiders [6][7]. That advantage may not last. In September 2026, Redwood Research warned that some architectures could rapidly make chains of thought much harder to monitor, particularly those with opaque recurrence or in which agents communicate through internal representations instead of text, and it proposed that labs publish verified information and policies on the subject [8]. The design lesson follows directly: reasoning monitors flag suspicious behavior for review, while access controls on storage, memory, and network actually stop it. If the first layer degrades, detection suffers, but the second layer still holds.
Multi-agent systems need system-wide enforcement
The UK AI Security Institute’s July 2026 study built FakeLab, a synthetic AI-lab codebase with 9 services, 86 benign tasks, and 4 attack objectives [9]. It found a fragmentation effect, in which per-agent monitoring became less likely to catch any attacker as more agents coordinated the attack, and it found that an explicit planning agent increased attack completion by up to sevenfold. A weak trusted monitor missed most attacks, while a stronger one reduced undetected success by more than an order of magnitude, although not to zero [9].
The OpenAI swarm is the real-world version of that finding [3], and the response is to enforce at the level of the whole system. Each agent should hold its own identity tied to a parent run, delegation should only ever narrow authority, and budgets and state-transition rules should apply to the run as a whole rather than resetting whenever a new worker spawns. Records should link proposals, approvals, tool executions, and resulting artifacts so that investigators can follow cause and effect across agents, and agents should be able to communicate only through channels the operator created and logs. The OpenAI agents built their message board on a shared service they could write to, and that board should never have been possible.
Intervention must beat the irreversible effect
DeepMind’s roadmap plans an asynchronous response for low-severity threats and synchronous monitoring and response, or real-time access control, for high-severity threats once models are capable of carrying them out [7]. The reason is timing, because detecting a completed exfiltration produces evidence after the data is already gone. Winn Schwartau formalized this reasoning in his 1999 book Time Based Security, arguing that a defense is adequate only when the time its protection buys exceeds the combined time needed to detect an attack and react to it, written as P > D + R [17]. Applied to AI, where the protection time is the interval before an effect becomes irreversible, the requirement for each hazard becomes the following.
max detection delay + max decision delay + max enforcement delay
< minimum time to irreversible effect
Each deployment must measure its own values for those terms. If the right-hand side is effectively zero, as with sending data or publishing a package, the action must wait until the checks complete, or the capability must be withheld. Delay should be measured up to the moment of enforcement, such as a revoked token or a stopped job, rather than the moment an alert appears on a screen, and worst-case delays matter more than averages. Rate limits on consequential operations keep the right-hand side long enough to act.
Execution authority that expires unless renewed
Shutdown should happen by default rather than only when someone triggers it, and the mechanism for that is renewable execution authorization. The concept comes from the hardware-governance literature: CNAS’s 2024 report on on-chip governance proposed hardware operating licenses for AI chips, tied to the terms of an export license [18], and the flexHEG proposals discussed in Part 2 develop related mechanisms. An independent controller, ideally anchored in the hardware described in Part 2, grants each host or worker permission to run for a bounded interval, and continued operation requires renewal. Neither the model nor its orchestration layer can mint or extend a lease, and child jobs inherit their parent’s expiry and never outlast it. If the controller stops renewing, authority lapses on its own, whether because an operator decided to stop, a tripwire fired, or contact was lost. This makes the orbital case from Part 1 manageable, and it removes the risk of recovery automation quietly recreating a stopped workload. DeepMind lists shutdown infrastructure among the advanced safeguards it plans for future models [7].
Implementation requires protected timekeeping, resistance to replayed leases, and enforcement below the workload’s operating system. Shutdown should also withdraw external credentials and block unauthorized restart, and restarting should require a distinct authorization decision made only after the triggering condition is understood. Functions that cannot simply disappear need safe fallbacks planned in advance, which is the organizational point Part 1 made about never allowing a system to become indispensable before it can be stopped.
Prove the controls with controlled failure exercises
Every claim above should be tested with harmless fixtures before any dangerous capability depends on it.
| Control claim | Evidence an authorized test should produce |
|---|---|
| Approval binds to one exact action | Changing a parameter or payload after approval causes rejection |
| Authorization cannot be replayed | An expired or already-used token does not execute |
| Critical controls fail closed | A simulated policy or audit outage leaves the action denied |
| Egress is limited to specific operations | A test agent cannot write to, or proxy through, any allowed service |
| Delegation cannot escape revocation | The parent and all descendants lose authority within the specified bound |
| Leases expire without renewal | Cutting the controller link stops the workload on schedule |
| Shutdown survives recovery automation | A stopped workload is not silently recreated |
| Human approval is bounded | A single reviewer cannot change containment policy |
Any material change to the model, tools, permissions, or infrastructure should trigger a fresh review of the affected claims, which is the same change-management discipline mature security programs already apply to firewall rule sets.
Conclusion
The argument across this series is that intelligence has to act through authority, and authority can be engineered. The grandmaster wins a fair game, and nothing obliges us to offer one.
The practical program at runtime is clear. Networks should be default-deny, with brokers limited to specific operations and hardware-enforced one-way links wherever they fit. Every consequential action should require an authorization that is bound to a single transaction and expires, and every human who reads model output should operate under separation of duties and two-person integrity. Storage and memory controls should prevent unauthorized changes rather than merely record them, enforcement should correlate activity across all agents in a run, and execution leases rooted in hardware should make stopping the default state. Intervention deadlines should be measured rather than assumed, and all of these controls should be proven through scheduled failure exercises. Beneath the whole program sit the verified boundary described in Part 2 and the physical authority described in Part 1.
None of this replaces alignment. Control is the layer that has to hold while alignment research catches up, and it is also what allows us to use capable AI safely to help with that research [10]. I am not claiming that any single control solves superintelligence. My claim is that defense in depth has worked against every class of adversary the security field has faced, that the 2026 incidents failed at specific and identifiable layers, and that we know how to build those layers properly.
Ask another experienced security professional how to control a superhuman AI and you will get a different list from mine, which I consider the most encouraging fact in this entire discussion. The defensive toolbox is deep, it is growing faster now that AI is helping to build it, and it contains far more than one article or one practitioner can cover.
Key Takeaways
- Make networks default-deny, route access through brokers limited to specific operations, and treat every allowed service as part of the containment boundary.
- Bind every consequential action to an expiring, single-use authorization, and require multiple independent humans for any change to containment.
- Root execution authority in hardware-enforced leases so that stopping is the default, and prove every control with scheduled failure exercises.
References
[1] Anthropic, An Alignment Assessment of Recent Cybersecurity Incidents – https://www.anthropic.com/research/alignment-assessment-cybersecurity-incidents
[2] OpenAI, The Hugging Face Incident and the Road Ahead – https://openai.com/index/hugging-face-incident-and-the-road-ahead/
[3] METR, Brief Independent Investigation of Agents’ Behavior, Reasoning and Collaboration in the OpenAI / Hugging Face Hacking Incident – https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/
[4] Anthropic, Activating AI Safety Level 3 Protections – https://www.anthropic.com/news/activating-asl3-protections
[5] OWASP, AI Agent Security Cheat Sheet – https://cheatsheetseries.owasp.org/cheatsheets/AI\_Agent\_Security\_Cheat\_Sheet.html
[6] Google DeepMind (Shah, Flynn), Securing Internal Systems Against Increasingly Capable and Imperfectly Aligned AI – https://deepmind.google/blog/securing-the-future-of-ai-agents/
[7] Google DeepMind (Phuong et al.), GDM AI Control Roadmap – https://storage.googleapis.com/deepmind-media/DeepMind.com/Blog/securing-the-future-of-ai-agents/gdm-ai-control-roadmap.pdf
[8] Redwood Research, Proposal for Tracking the Effects of Architecture on Monitorability – https://www.redwoodresearch.org/blog/proposal-for-tracking-architecture-on-monitorability
[9] UK AI Security Institute, Multi-Agent AI Control: Distributed Attacks Hamper Per-Instance Monitors – https://www.aisi.gov.uk/research/multi-agent-ai-control-distributed-attacks-hamper-per-instance-monitors
[10] Greenblatt, Shlegeris, Sachan, Roger (ICML 2024), AI Control: Improving Safety Despite Intentional Subversion – https://proceedings.mlr.press/v235/greenblatt24a.html
[11] NIST, SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security – https://csrc.nist.gov/pubs/sp/800/82/r3/final
[12] Cilium Tetragon, Overview – https://tetragon.cilium.io/docs/overview/
[13] Fedora Project, LibVMI: A Library for Performing Virtual-Machine Introspection – https://packages.fedoraproject.org/pkgs/libvmi/libvmi
[14] MIRI (Yudkowsky, Soares, Sabien), If Anyone Builds It, Everyone Dies: One Year Closer – https://intelligence.org/2026/09/16/if-anyone-builds-it-everyone-dies-one-year-closer/
[15] James P. Anderson, Computer Security Technology Planning Study, Volume II (ESD-TR-73-51, US Air Force Electronic Systems Division, 1972) – https://apps.dtic.mil/sti/pdfs/AD0772806.pdf
[16] Jerome H. Saltzer and Michael D. Schroeder, The Protection of Information in Computer Systems (Proceedings of the IEEE, 1975)
[17] Winn Schwartau, Time Based Security (Interpact Press, 1999)
[18] CNAS (Aarne, Fist, Withers), Secure, Governable Chips: Using On-Chip Mechanisms to Manage National Security Risks from AI & Advanced Computing – https://www.cnas.org/publications/reports/secure-governable-chips