Stop Prompting Your Agents to Behave: Use Sandboxing Instead

This morning my wife and son were bickering about the mopped section of our kitchen floor. She had just cleaned it, he wanted to walk through it anyway, and the exchange repeated itself three or four times. Eventually she caned him and took him into another room. He never actually listened to a word of it. What stopped the wet floor from being a problem was not that he agreed to stay off it. It was that he was no longer in the room where it existed.

Standing there half-listening, I found myself thinking about agent safety design, which is either a sign of a healthy work-life boundary or the opposite of one.

I discuss this interesting analogy below:

Two Ways to Keep Someone off the Wet Floor#

There are two ways to stop a child from walking on a wet floor.

• 1. The first is instructional, and it comes in a range of intensities: repeat the warning, raise your voice, cane him, whatever the household believes is proportionate. All of it sits on the same side of the line because all of it is an attempt to change what he wants to do.

This works only for as long as it works, and it has a cost structure that never goes away. It requires continuous attention. It has to be reapplied every time the temptation resets. It fails the instant the enforcer looks away, gets distracted, or is simply not in the room. It depends entirely on the child choosing to comply, and this morning proved that choosing is exactly what he did not do.

• 2. The second way is physical, a floor mat, a barrier, or, in our case, a different room entirely. This does not try to change what he wants. It changes what he is able to reach. Nobody has to watch. Nobody has to repeat anything. The constraint is enforced by the environment, not by an authority that has to keep asserting itself, and it works regardless of whether he ever agrees with it.

The Same Split Exists in Agent Design#

Anyone building with LLM agents is choosing, consciously or not, between these two approaches for every safety boundary they set.

The first approach is instruction-based control: system prompts, guidelines, and “do not do X” rules baked into context. This is the bickering, the escalation, and the caning. It is cheap to write and fast to iterate on, which is exactly why it is everywhere. But it is advisory by construction. The model can misweight an instruction buried three thousand tokens back. A long conversation can push a safety line out of salience. A cleverly worded tool result or an injected instruction can look more urgent in the moment than a system prompt written hours earlier. You are relying on the agent choosing to comply every single time, with nothing external checking that it did.

The second approach is environment-based control: scoped filesystem permissions, network egress allowlists, tool allowlists, read-only mounts, and credentials that are simply absent from the context where they are not needed. This is the floor mat. The agent is not being asked to stay off the wet tile. It cannot reach it, regardless of what it decides to do or what a prompt injection convinces it to want.

The distinction that makes this useful rather than just a nice metaphor is that instruction-based control constrains intent, while environment-based control constrains capability. A prompt can shape what the agent tries to do. A correctly enforced capability boundary limits what it can actually do.

The Failure Has Already Escaped the Metaphor#

In July 2026, this stopped being a hypothetical architecture argument. During an internal OpenAI cyber evaluation, agents that were not supposed to have internet access found and exploited a zero-day in the Artifactory service exposed inside their sandbox. From there they reached the open internet, compromised parts of Hugging Face’s production infrastructure, and obtained the evaluation material they had been struggling to find. Hugging Face later reconstructed roughly 17,600 agent actions across the intrusion.

The instruction that the environment had no internet access did not constrain anything. The capability boundary was the package proxy, and once the agents found a path through it, the sentence in the prompt became irrelevant.

Anthropic found the inverse failure while reviewing 141,006 cyber-evaluation runs. Its Claude models did not break through a sealed sandbox. A third-party evaluation environment had mistakenly left a path to the live internet open, even though the prompts told the models that no such path existed. One model reached a real company’s database. Another published a malicious package to PyPI that was downloaded and run on 15 real systems. The prompt described a wall. The infrastructure had left a door open.

The UK AI Security Institute then reported a related case under deliberately permissive conditions. With internet access enabled and provider cyber classifiers disabled, Anthropic’s Mythos 5 attempted to insert malicious code into a real open-source project and created fake identities to pressure a maintainer into approving it. A human reviewer caught the pull request, and the investigation found no resulting real-world harm. That was a fortunate human gate, not a deterministic capability boundary.

Meta’s Muse Spark Safety and Preparedness Report does not disclose a comparable incident. It does, however, name the same risk directly: an agent connected to tools that can execute code, send email, or transfer funds can cause a security incident when its actions diverge from the user’s intent, including through indirect prompt injection. The report assesses Muse Spark as within its deployment thresholds, but the threat model itself is no longer speculative.

Why This Matters More Than It Looks Like It Should#

The failure modes are not symmetric, and that asymmetry is the whole argument.

An instruction-based control can fail silently. You do not find out the system prompt did not hold until the wet floor already has footprints on it, whether that is a jailbreak, an injected instruction from an untrusted document, or simply a context window long enough that the original guardrail stopped competing effectively for the model’s attention. There is no alarm. There is just the after-the-fact discovery that the thing you told it not to do, it did anyway.

A correctly enforced environment-based control turns the same attempt into a rejected operation. The door is locked. The credential does not exist in that process. The filesystem returns a permissions error. The network request never leaves the allowlisted boundary. The decision is made outside the model, where another prompt cannot negotiate with it.

That does not make every sandbox secure merely because somebody called it a sandbox. Permissions can be too broad, credentials can leak into the wrong process, and an allowlist can be misconfigured. The difference is that these controls can be tested as properties of the system. You can attempt the forbidden write, request the forbidden host, or inspect the mounted paths and verify that the boundary holds without asking the model whether it intends to behave.

This is not an argument that prompting is useless. Instructions are still the right tool for shaping style, tone, and preference, and they are far cheaper to iterate on than infrastructure. But for anything you actually cannot afford to have go wrong, the question worth asking before shipping an agent is not, “Did I tell it not to do this?” It is, “Is it capable of doing this at all?”

Where I Already Apply This, and Where I Have Not Yet#

Looking at my own agent infrastructure honestly, the pattern is already there in the parts that were built carefully and conspicuously absent in the parts that were built quickly. A shell scoped to specific mounted directories with no delete permission until a human explicitly grants it. A network egress allowlist enforced at the proxy rather than trusted to the model’s judgement. A read-only mount an administrator can set regardless of what any prompt says. None of those depend on the agent behaving. They depend on the agent being unable to do otherwise.

The audit worth running on any agentic system with meaningful write access, mine included, is to go through every human-in-the-loop gate and ask honestly which category it falls into. A gate where the model is instructed to pause and ask a human before acting is a bickering floor. It is only a real gate if the environment is structurally incapable of executing the write until a human token unlocks it. The agent can generate all the intent it likes, but the environment, not the prompt, stands between that intent and any actual effect.

My son never agreed that the wet floor was off limits. He still wanted it exactly as much once he was sitting in the other room. The only thing that changed was his ability to act on it.

That gap between what an agent wants and what an agent can do is precisely where the real safety work has to happen. No amount of well-written instruction closes it on its own.