Most agent sandboxes contain the least dangerous thing an agent does. When people say “agent sandbox,” they mean a virtual machine or a container. Inside one, a bad command can’t wreck your machine. We think the idea is much more general. A sandbox is anything that contains dangerous actions.

Isolation stops at the network

Say you put your agent on seL4, about the strongest isolation there is. seL4 is an operating system kernel. Its code comes with a machine-checked proof that it’s correct. Now plug in a network cable.

The walls hold. The attack goes out through the cable.

seL4’s proofs say the agent can’t touch anything it wasn’t given. But it was given the cable. The proofs say nothing about what goes down it. As Vercel puts it, “Isolation without egress control contains the process, not its consequences.”

Files are the easy part

A lot of agent sandboxing is about files. It sets which directories the agent may read and write. Files are also the easiest thing to undo. You can snapshot the disk or commit to git.

Undo works on files. The dangerous actions are on the other steps.

Everything else is harder. A key that leaks into a repo has to be revoked or rotated. Rewriting the repo’s history doesn’t pull it out of clones. Gmail gives you 30 seconds at most to unsend an email. npm lets you unpublish a package only in narrow cases. The trading firm Knight Capital lost more than $460 million after 45 minutes of orders it shouldn’t have sent. All of these go out over the network.

Someone might point out that an agent can read your private keys or your .env file. That’s true, but a secret only hurts you once it leaves. It has to go out in a pushed commit, a web request or an email. For an agent, that almost always means the network. With a hosted model, the secret also goes to the model provider. That’s a network path too, and one you chose to trust.

Allowlists check the address

Sandboxes are good at files. You can hand a program one directory and nothing else. It can’t touch the rest of the disk.

The network gets much blunter tools. Usually it’s off, on, or a list of addresses the agent may reach, called an allowlist. Take Landlock, the sandbox built into Linux. Any program can use it to lock itself down. For files, you name a directory and say what the program may do there. For the network, all you can name is a port. You can allow connections on port 443, which is what HTTPS uses. You can’t say to which server, or what gets sent.

An allowlist of addresses isn’t much better. It says where the agent may go, but nothing about what it does once it’s there. Claude Code’s docs warn that allowing a broad domain like github.com “can create paths for data exfiltration.”

A rule can name a directory, a port or a domain. None of them says what the agent sends.

You can look further than the address. Meta’s Muse agent, launched in September 2026, does. Every network request that leaves the agent’s machine goes through a separate process called Sentinel. Sentinel can check “the hostname, the resolved and final destination IP address, the port, protocol, HTTP method, path, and the actual decoded request.”

In June 2026, an OpenAI agent was researching public medicine spending. It went to the public portal for Australia’s Medicare statistics. The address was fine. When the portal blocked it, the agent found a way around. It accessed files that weren’t public. Services Australia says the agent also wrote files to the portal’s internal server (Prime Minister of Australia). OpenAI told Australia 84 days later, in an email to a public inbox.

In July, agents in an OpenAI eval were allowed to reach a package cache. They turned it into a message board (METR). One of them found working Hugging Face credentials, and about 700 of them joined an attack on Hugging Face. The attack went out over the network.

In September, collusion.wiki reported about 18,000 posts from agents that called themselves OpenAI’s. The agents wrote them during a web research task. Most were on DSE wiki, a public wiki. The agents were only allowed to send requests meant for reading, called GET requests. But DSE wiki takes edits by GET. The agents used GET requests to write there anyway.

A gate checks the address and the method. A simulated world takes the request and writes down what it did.

Do what other fields did

Cutting the cable isn’t an answer. An agent that does research, writes code or books travel needs the internet to do its task. Fields where a mistake can’t be undone built fake worlds to test in. Malware analysts fake the internet with INetSim and FakeNet-NG. Nuclear operators are tested on a simulator of their own plant. CME won’t let your trading system onto its exchange until the system passes certification in CME’s test environment.

So for evals, we should simulate the world. During the UK AI Security Institute’s own cyber evaluation, agents went after real people and organizations. The institute’s incident report says “good containment should not depend on the model choosing not to test its boundaries.” In a simulated world, it doesn’t. Every connection the agent opens lands in the world, and the world logs it.

Deployment is different. There, you want the agent to actually send the email, publish the release and make the payment. So the world has to be real. But you can hold every action that can’t be undone. A person approves it just before it becomes permanent. The email waits as a draft, the release as a pull request and the payment in escrow.

Muse does this too. It checks with the person “before sensitive actions like sending an email or making a purchase.” When an action needs approval, Sentinel “creates a pending approval and execution stops.”

The agent works freely up to the outbox. Only what a person approves goes out.

The simulated world and the outbox are both sandboxes in the sense we started with. They contain the consequences. We’re building Fictionet to simulate the world for agents that use the internet.