Definitions only get you so far. To really understand a sandbox, you need to see it doing work, and you need to see what specifically made it succeed or fail in each setting. Abstractions hide the detail that matters; examples surface it.
This article walks through six concrete scenarios drawn from how teams actually use AI sandboxes. Each one names the situation, what the sandbox did, and the single decision that determined the outcome. The goal is not breadth for its own sake but pattern recognition: after six examples, you start to see the shape of when a sandbox helps and how it can quietly fail.
If you want the conceptual foundation first, the complete guide covers it. Here we stay concrete.
Example 1: A coding agent that rewrites files
A team builds an agent that refactors code across a repository. Left loose, the agent could overwrite the wrong files or run a destructive command. So they run it in a container with a copy of the repo and no access to anything else.
What made it work: The agent operated on a copy, not the real repository, and the container was destroyed after each run. When the agent made a bad edit, it cost nothing. The team reviewed the diff, kept the good changes, and discarded the rest.
The detail that mattered: A read-only mount of the original plus a writable copy. The agent could not corrupt the source even if it tried.
Example 2: Testing a customer-facing chatbot
Before a support bot goes live, it has to be probed for bad behavior: leaking data, giving dangerous advice, falling for manipulation. Doing this against real customers is unthinkable.
The team runs the bot in a sandbox loaded with synthetic customer profiles and a battery of adversarial prompts. They watch how it handles attempts to extract other users' data or to be talked into off-policy responses.
What made it work: Synthetic profiles meant that even a successful data-leak attack exposed nothing real. The team could be aggressive in their testing precisely because there was nothing to lose.
Where this can fail: If the synthetic data is too clean, the bot looks well-behaved in the sandbox and stumbles on the messiness of real inputs. Fidelity has to match the threat you are testing for.
Example 3: Evaluating a new model before adoption
A company wants to switch model providers but cannot risk a regression in a live product. They stand up a sandbox that replays a recorded set of real tasks, with all sensitive values masked, against both the old and new models.
What made it work: Masked replay let them compare models on realistic workloads without exposing customer data. The comparison was apples-to-apples because both models saw identical inputs.
The detail that mattered: Determinism. By fixing the input set, they isolated the model as the only variable, which made the evaluation trustworthy. Our framework article covers this kind of controlled comparison in more depth.
Example 4: An autonomous agent that spends money
The riskiest category: an agent authorized to make purchases or call paid APIs. A loop bug here is not a wrong answer; it is a bill.
A team building a procurement agent runs it first in a sandbox where the payment tool is a mock that logs intended purchases without executing them. They review what the agent would have bought before ever connecting real money.
What made it work: Mocking the dangerous capability. The agent believed it was buying things; nothing was actually bought. The team caught two cases where the agent would have ordered duplicates.
The lesson: For high-stakes actions, simulate the action rather than perform it. The sandbox lets you watch intent without consequence.
Example 5: Letting non-engineers experiment safely
A marketing team wants to try AI for generating campaign drafts but should not be able to touch production systems. The organization gives them a sandboxed playground: a no-network environment, synthetic brand data, and a hard spend cap.
What made it work: The guardrails were invisible to the users. They just experimented, and the walls quietly contained everything. Non-technical people got to be creative without anyone fearing what they might break.
Where this can fail: If the spend cap is too low, legitimate experimentation hits the ceiling and people get frustrated. If too high, a runaway session gets expensive. Calibration matters, as our common mistakes guide details.
Example 6: Running untrusted, AI-generated code
The hardest case: an agent generates code from open-ended prompts, and that code must actually execute. Generated code from untrusted prompts can do genuinely hostile things.
A team running this uses a microVM rather than a plain container, giving a stronger kernel-level boundary, plus default-deny networking and aggressive teardown.
What made it work: Matching the isolation strength to the trust level. Untrusted generated code earned the stronger boundary; trusted internal code would not have needed it.
The detail that mattered: They tested the boundary adversarially before trusting it, instructing generated code to attempt a breakout. It failed, as designed, which is exactly the result you want from such a test.
A counter-example: when the sandbox gave false confidence
It is worth studying a failure, because the absence of an incident is not proof that the sandbox worked. A team built a sandbox for an agent that summarized internal documents. They isolated execution, denied outbound networking, and felt secure. The agent ran for weeks without incident.
The problem surfaced only when an auditor asked a simple question: what data was the agent actually seeing? It turned out that someone had, months earlier, swapped the synthetic document set for a real export "to test summary quality," and never swapped it back. The sandbox's walls were genuinely strong. The data inside them was real, sensitive, and exactly what the sandbox was supposed to keep out.
No alarm fired because nothing leaked. The isolation held. But the entire premise, that a breach would be harmless, had quietly become false. This is the most instructive kind of failure precisely because it produced no incident. The lesson: verify what is inside the box as rigorously as you verify the walls, since a perfect wall around real data is a perfect way to feel safe while being exposed. Our common mistakes guide treats this failure mode in depth.
What the examples have in common
Reading across all of these, a single discipline separates the successes from the near-failures: the safe version of each scenario tailored both the strength of isolation and the fidelity of data to the specific risk at hand. Nobody applied a generic template. The coding agent earned a writable copy; the money-spending agent earned a mocked tool; the untrusted code earned a microVM; the document summarizer should have earned a verified synthetic dataset and did not.
When you study your own use case, resist the urge to copy a sandbox that worked elsewhere. Ask instead what specifically can go wrong here, and shape the isolation around that answer.
Frequently Asked Questions
What is the common thread across these examples?
Each one matches the isolation strength and data fidelity to the specific risk being managed. A coding agent gets a writable copy; a money-spending agent gets a mocked payment tool; untrusted code gets a microVM. The sandbox is tailored to the threat, not applied as a single generic template.
When did synthetic data help and when did it hurt?
It helped whenever the test did not depend on real-world messiness, such as checking an agent's core logic. It hurt when the test was specifically about handling messy inputs, where overly clean data made systems look more robust than they were. Match data realism to what you are actually testing.
Why mock a payment tool instead of using a small real budget?
Because a mock removes the downside entirely while still letting you observe the agent's intent. A small real budget still permits real, if bounded, mistakes, and a looping agent can exhaust even a small budget surprisingly fast. Simulation gives you the observation without any of the spend.
How do I decide between a container and a microVM from these examples?
Match the boundary to trust. Code your team wrote and reviewed runs fine in a container. Code an AI generated from open-ended prompts deserves the stronger kernel boundary of a microVM. The deciding question is always how much you trust what runs inside.
Can these patterns combine in one system?
Absolutely, and mature setups do. A single platform might use copies for file edits, mocks for dangerous actions, masked data for realistic evaluation, and microVMs for untrusted code, all at once. The examples are building blocks, not mutually exclusive choices.
Key Takeaways
- A coding agent stays safe by operating on a writable copy with a read-only original, so bad edits cost nothing.
- Testing chatbots and models against synthetic or masked data lets you be aggressive precisely because nothing real is at stake.
- For high-stakes actions like spending money, mock the dangerous capability so you can observe intent without consequence.
- Match isolation strength to trust level: containers for trusted code, microVMs for untrusted, AI-generated code.
- The unifying pattern is tailoring isolation and data fidelity to the specific risk, then testing the boundary adversarially before trusting it.