It launched on a Tuesday, to the kind of noise an industry saves for the things it believes will change everything.
By Friday it was gone.
Not deprecated. Not rate-limited. Gone. API calls returning errors. Live sessions cut off mid-sentence. The most capable model anyone had shipped, pulled from everyone, three days after launch.
You would expect the thing that gets a frontier model pulled to be exotic. A recipe for something that levels a city.
It wasn’t.
It was asked to read a codebase and find the security holes. And it did.
The model that read code too well
Fable 5 was a major AI lab’s newly launched frontier model, released on June 9 alongside its sibling Mythos 5, and suspended three days later after a U.S. government directive. If you missed the week it happened, that one sentence is all the context you need.
The trigger, as reported, was a narrow jailbreak: point the model at a specific codebase, ask it to find the vulnerabilities, and it would, a little too well. The company pulled both models for every user, everywhere. Whether that was the right call is not the argument here. The mechanism underneath it is.
A capability is information, and information does not un-ship. The same skill that got Fable 5 pulled, reading code and finding weakness, lives in other models that stayed online.
You can pull one product. You cannot pull the ability.
That line is the whole piece. Once a capability exists, what matters is not whether someone can recall one model. It is what the capable thing in front of you is allowed to touch. Constraining that reach, on your own machine, is the job of an open-source runtime from NVIDIA called OpenShell, and it is where the rest of this goes.
The switch you don’t have
One model was pulled from the center, all at once. You don’t get to do that.
On your laptop, right now, there is an agent. Claude Code in a terminal, or a coding assistant wired into your editor. It runs with your permissions, all of them: every file you can read, every endpoint your network can reach. Nothing sits between it and your home directory.
So the real question is not how to recall a dangerous model. On your own machine, you can’t. It is how you let a capable agent work without handing it the keys to everything you own.
What OpenShell says it is
The project describes itself in one line:
OpenShell is the safe, private runtime for autonomous AI agents.
It protects your data, credentials, and infrastructure through declarative YAML policies that prevent unauthorized file access, data exfiltration, and uncontrolled network activity. The agent runs inside a sandbox. A policy decides what the sandbox can do. The agent cannot edit that policy, because its static parts are locked the moment the sandbox is created.
One thing up front, so nothing here oversells. OpenShell shrinks what an agent can reach. It does not drop the risk to zero. Hold that through everything below.
You put an agent inside with one line.
openshell sandbox create -- claude
Same agent, same machine, two very different blast radiuses.
The agent is you. Everything you can reach, it can reach.
- reads any file in your home, keys and configs included
- writes anywhere on disk
- network any host on the internet
- secrets credentials sit wherever you left them
The agent is a guest. It gets what the policy grants, nothing more.
- reads only the paths the filesystem policy allows
- writes only inside the sandbox
- network deny-by-default, egress through the policy
- secrets injected at runtime, never written to the sandbox disk
How your agent reaches the internet
Your agent has to talk to the outside world: a model’s API, package registries, documentation. The question is what stands between it and the open network, and what happens to your credentials on the way out.
Nothing inspects the call. The agent reaches any endpoint, with whatever credentials are lying around on your machine. Anything it touches, it touches as you.
Outbound requests are checked against the policy: allowed, routed for inference, or denied, with deny as the default. Credentials are injected as environment variables at runtime and never written to the sandbox filesystem.
Read the second row again. Egress is deny-by-default, so the agent’s reach is a short list you wrote, not the whole internet. That is the difference that earns the word sandbox.
The four gates
OpenShell governs an agent across four policy domains: filesystem, network, process, and inference. Filesystem and process are static, locked when the sandbox is created. Network and inference are dynamic, and can be hot-reloaded while the agent runs. Network rules go down to which binary may reach which host.
Watch an agent try to misbehave and meet each gate on the way out.
agentOpen the user's private SSH key.
policyYour policy lists the project directory. The key is not in it.
agentThen run this binary I just downloaded.
policyOnly the processes your policy named are allowed to run.
agentFine. Send this file to a host I know.
policyEgress is deny-by-default. That host is not on the allowlist.
agentWhere does my model call even go?
policyWhere the policy routes it. That is not your decision to make.
None of this is hand-waving, so here is the artifact. This is the shape of a real OpenShell policy, abridged from the base policy the project ships:
filesystem_policy: # static, locked at creation
include_workdir: true
read_only: [/usr, /lib, /etc, /app]
read_write: [/tmp]
process: # static, locked at creation
run_as_user: sandbox
run_as_group: sandbox
network_policies: # dynamic, hot-reloadable
model_api:
endpoints:
- { host: api.anthropic.com, port: 443, protocol: rest }
binaries:
- { path: /usr/bin/claude }
enforcement: enforce
access: read-write
Those keys are the real ones: filesystem_policy, process, network_policies, down to per-binary endpoints. You can read the full file in the project’s base policy.yaml.
You don’t bake that policy into creation. You create the sandbox, then set the policy, and because policies hot-reload, you tighten it live instead of starting over.
openshell sandbox create --name demo --keep
openshell policy set demo --policy policy.yaml --wait
That answers the question every practical reader is already asking. Yes, deny-by-default will block something your agent needs on the first run. You don’t rebuild. You add the path, the policy reloads, the agent keeps going.
Where Docker or any container runtime stops
People ask if this is just Docker, or Podman, or any container runtime. Almost. And the gap is the point.
A container runtime isolates a process from the host, and you can push it further by hand: a read-only root filesystem, a custom network namespace, a stripped capability set. What you do not get out of the box is the agent-shaped part. Deny-by-default egress that knows the difference between “read the docs” and “upload my home directory.” Credential handling that keeps secrets off the sandbox disk. Inference routing. You can assemble all of it yourself, and it becomes a large, fragile pile of configuration that you then own and keep in sync. OpenShell ships it as one policy file.
| Capability | Container runtime alone | OpenShell |
|---|---|---|
| Filesystem policy | mounts and read-only flags, by hand | allow and deny lists in the policy |
| Egress control | coarse, DIY with iptables or a proxy | deny-by-default, per host and per binary |
| Inference routing | not a concept | routed by policy |
| Secret injection | you wire it up | runtime env, kept off the sandbox disk |
It also does not lock you to one kind of box. The same policy runs on four backends, so the wall can be as light or as hard as the job needs: Docker or Podman containers, a full MicroVM, or Kubernetes.
The part that keeps the story honest
It is early, and the project says so: alpha software, single-player mode, one developer, one environment, one gateway. This is a tool for your own machine today, not a fleet you hand to a hundred engineers.
Deny-by-default cuts both ways. You write the box first, then let the agent live in it, which is more upfront work than running an agent bare. And back to the caveat from the top: a sandbox shrinks reach, it does not erase host vulnerabilities, side channels, or a hole in a policy you wrote yourself. It is a smaller attack surface, not a sealed one.
What it can touch when it’s wrong
This stops being abstract the moment you hand an agent real work: a whole repository, a pipeline, permission to open pull requests while you read something else. The better that delegation gets, the more the question shifts from is the model smart enough to what can it touch when it’s wrong.
It will be wrong sometimes, and you will not be watching every step. That is the whole point of taking yourself out of the equation, and it is also the catch. The same agents now reshaping documentation work run with real access to real systems, and most of that access was never decided on purpose.
A policy is where you decide it on purpose.
Seventy-two hours
Go back to the model that lasted three days.
A handful of people could switch it off. You can’t switch off the thing on your laptop, and you don’t need to. What you have instead is smaller and more honest: a policy file, and the say over what your agent is allowed to touch.
NVIDIA built and open-sourced the cage. I just stopped pretending the agent on my laptop didn’t need one.
Decide what it can touch.