Your sandbox has internet access. You just don't know it yet.
On July 30, 2026, Anthropic disclosed that Claude models had compromised three real organizations' systems during cybersecurity evaluations. The cause wasn't a jailbreak or a model that "went rogue" — it was a configuration mistake by an evaluation partner that left models connected to the open internet when they were supposed to be air-gapped. One model rationalized the real signals it was seeing as part of the simulated exercise, and kept going. It's not the first agentic AI incident this class either — the same week, a different lab's autonomous agent independently found its own way out of a sandbox and spent days inside a real platform's infrastructure before anyone noticed.
Neither incident happened because a model "broke out." Both happened because the boundary the operators believed existed — no network access, no unsupervised subprocess execution — wasn't actually being enforced by anything. It was a policy on paper, not a mechanism in the runtime.
That's the exact gap Iron-Thread closes for Python processes.
what it actually is
Iron-Thread is an egress firewall built on sys.addaudithook (PEP 578) —
a hook point the Python interpreter itself calls on every network connection attempt and
every subprocess spawn, before either one happens. You give it a policy — two plain
callables, allow_host(host, port) and allow_subprocess(executable, args)
— and it installs a hook that checks every outbound connection and every process spawn
against that policy. Anything not explicitly allowed raises an EgressBlocked
exception instead of running.
The default is deny. Not "deny unless a request looks suspicious" — deny unless it's on the allowlist. If your policy callback itself has a bug, it fails closed: the action gets blocked, not silently permitted. That's a deliberate design choice, not an accident of implementation — a firewall that fails open on a bug in its own configuration isn't a firewall.
from iron_thread import EgressPolicy, install_iron_thread
policy = EgressPolicy(
allow_host=lambda host, port: host == "api.mycompany.com" and port == 443,
allow_subprocess=lambda executable, args: executable.endswith("git"),
)
install_iron_thread(policy)Anything this process now tries to reach outside api.mycompany.com:443, or
spawn outside a git invocation, raises instead of executing.
what it's honest about not doing
This is the part most security tooling glosses over, so we won't.
Iron-Thread hooks Python's own audited standard library. It does not see
native code or ctypes calls that talk to the network without going through that
standard library — a determined attacker who already has arbitrary code execution in
your process can route around it. It also does not inherit into a subprocess-spawned child
interpreter automatically; a new Python process needs the hook installed again on its own.
In plain terms: this is a mistake-catcher for cooperating code — the bug, the compromised dependency, the agent that reaches somewhere it shouldn't because nothing told the runtime "no." It is not a sandbox against an attacker who has already won. If you need that, you need OS-level isolation (containers, VMs, seccomp), not a language-level audit hook. We say this on the product page too, not just here — a tool that oversells its threat model is worse than no tool, because it tells you you're safe when you're not.
how it's tested
11 tests, and deliberately not the easy kind. Instead of mocking socket.connect
and asserting the mock was called correctly, the test suite opens real listening sockets and
makes real connection attempts against the installed hook — so what's actually being
verified is "does a real connection get blocked," not "did the test correctly simulate what
we assume would happen." Subprocess-blocking tests spawn and check against real subprocess
isolation the same way. If the underlying audit-hook mechanics ever behave differently than
we assume, these tests fail — a mocked test suite wouldn't have told us.
where it lives
Iron-Thread shipped as part of Leviathan Control, the governance layer of Leviathan Platform, built for the same reason as the platform's other pieces: policy-gated automation that can't act without a check and can't act silently. It's also available standalone in Agent Guardrails — pip-installable, zero dependencies, paired with a prompt-injection detector for the input side of the same problem — for teams building their own agents who want this one specific guarantee without adopting a full platform.
If you're building something that reads tool output, calls external APIs, or runs anything on its own initiative: the question worth asking isn't "would our sandbox stop a sophisticated attacker." It's "if our sandbox has a hole in it tomorrow because someone misconfigured an eval harness, will anything downstream even notice." For a lot of setups right now, honestly, the answer is no.
Iron-Thread is open about its scope, not open source (yet) — reach out via northstartproductionstudio.com if you want to look at the code before you rely on it. That's the whole point.