What is AI sandboxing?

Summary slides

Why sandboxing matters specifically for AI systems that can execute code or take actions

A model that only generates text carries a bounded kind of risk, since a wrong or harmful piece of text still requires a human or a separate system to act on it before it ever causes actual damage to anyone. Once a system gives a model the ability to execute code, call external tools, or take direct action in a live environment, that buffer disappears, and whatever the model decides to do can happen immediately, without a human reviewing the step first. This particular shift is precisely what makes sandboxing a distinct, necessary concern for AI systems in a way it never was for earlier systems that only ever produced output a person then had to act on themselves.

The core difficulty is that a model’s actual behavior, however well it performs during testing, simply doesn’t come with the kind of formal guarantee that lets an engineer honestly say with confidence that it will never attempt an action nobody specifically anticipated in advance. A model can be manipulated through prompt injection into attempting something well outside its intended scope, can misinterpret an ambiguous instruction in a way that leads it toward a harmful action, or can simply, honestly make a mistake in exactly the way any complex system occasionally, inevitably does over time. Sandboxing exists specifically to make this unpredictability survivable, ensuring that even a truly unexpected action, one no guardrail ever anticipated and no instruction explicitly, specifically forbade, still can’t reach beyond a boundary that was deliberately, carefully built to contain it regardless of whatever the model itself decided to do in that moment.

How AI sandboxing differs from conventional software sandboxing

Sandboxing itself isn’t a new idea at all, conventional software has used isolated execution environments for many decades now to contain untrusted code, browser tabs, third-party plugins, user-submitted scripts of every kind. What’s different about AI sandboxing is the nature of what’s being contained: conventional sandboxing generally assumes the code running inside it, while potentially malicious, behaves according to a relatively fixed, analyzable set of possible actions, while an AI system’s actions emerge from a model’s reasoning in real time, meaning the sandbox has to contain not a fixed program but an open-ended range of behavior the model might generate in response to a situation.

This distinction matters because conventional sandboxing can often rely on static analysis examining code before it ever runs to understand what it could possibly, realistically do, as one layer of its overall, broader defense strategy. An AI system’s actual behavior can’t be fully predicted through static analysis of the model’s weights, since the action it takes in response to a prompt is generated dynamically rather than existing as fixed code waiting to be inspected. AI sandboxing has to be built directly around this dynamic, generative quality assuming that whatever the model might decide to do in a moment, however unlikely that action might seem, needs to be contained by the boundary itself rather than merely ruled out in advance through inspection of the model’s static code or weights.

What needs to be sandboxed in an AI system

The scope of what needs actual containment in an AI sandbox is considerably broader than it might first appear to anyone approaching the problem for the first time. Code execution is the most obvious category, any system that lets a model write and run code needs that execution isolated from the broader infrastructure, but tool calls deserve equally serious containment too, since a model invoking an external API, a file system operation, or a database query is taking an action with consequences just as surely as executing arbitrary code would be, even though it doesn’t look like code execution from the outside looking in.

Network access deserves its explicit boundary within the sandbox, since a system that can reach arbitrary external endpoints carries risk that a system confined to a small, explicitly, deliberately allowed set of destinations simply doesn’t, whether that risk is data exfiltration to an unauthorized destination somewhere, or the system inadvertently, unknowingly participating in an attack against some other target entirely. File system access needs similarly explicit, careful scoping limiting what the sandboxed process can read or write rather than simply assuming the broader containment already, automatically covers this adequately on its own, since file system access that escapes the sandbox’s other boundaries can itself become a path to further, deeper compromise of the whole system.

Resource consumption, memory, compute, execution time also belongs within the scope of what a sandbox actively, deliberately constrains, not merely because runaway resource use degrades the broader system’s actual performance for everyone else, but because an AI system given open-ended resources can end up in truly unproductive loops, repeatedly, endlessly attempting a failing action or generating increasingly elaborate but unproductive reasoning consuming resources without the human oversight that would normally catch this kind of unproductive spiral early enough to matter.

How to design sandbox boundaries around what an agent needs to reach

The most secure sandbox is one built around the principle of least privilege applied specifically to what an AI system needs to accomplish its actual task, rather than a broad, general-purpose environment that happens to also contain the system. A sandbox that grants access to an entire file system when the system’s actual task only ever requires reading from one directory carries risk that a narrowly, deliberately scoped sandbox, limited to exactly that one directory, simply doesn’t carry, and the gap between what’s needed and what’s granted is, in a sense, pure and entirely unnecessary exposure that nobody needed to accept.

This design work requires understanding what an AI system’s task requires before ever building the sandbox around it, rather than simply defaulting to a broad permissive environment on the theory that it’s easier to build once and reuse across many entirely different systems with entirely different actual needs. A shared overly broad sandbox environment used across multiple different AI systems, each with meaningfully different actual needs, tends to grant every single one of those systems access considerably beyond what any single one of them really requires on its own, meaning a compromise or even just a small misstep in one single system carries risk that properly, individually scoped, tailored sandboxes built for each system separately would have prevented from happening at all.

Sandbox boundaries also need to account for what happens over real time as a system’s capabilities expand, since a sandbox correctly, carefully scoped for a system’s original narrower task can become dangerously permissive once that system’s actual task grows to include new tools or new data sources, if the sandbox’s boundaries aren’t deliberately, actively revisited and re-scoped alongside that expansion, rather than simply inherited unchanged from the system’s considerably earlier, narrower version.

How sandbox escape risk is different when the thing inside the sandbox is an LLM-driven agent

Conventional sandbox escape typically involves an attacker exploiting a technical vulnerability, a flaw in the isolation mechanism itself, to break out of the contained environment. AI sandboxing has to defend against this same category of technical escape, but it also has to account for a subtler risk that doesn’t have a clean analog in conventional sandboxing: a model being manipulated, through content it encounters while operating inside the sandbox, into generating actions specifically designed to probe for or exploit a weakness in the sandbox’s boundaries, effectively turning the model itself into an unwitting tool for discovering the sandbox’s limitations.

This means AI sandboxing benefits from adversarial testing that specifically, deliberately probes what happens when a model operating inside the sandbox is deliberately fed content specifically designed to induce exactly this kind of boundary-probing behavior on purpose, treating the sandbox’s actual resilience under this kind of pressure as something that needs to be actively verified through testing, rather than simply assumed correct purely because the isolation mechanism itself, considered only as raw infrastructure, happens to be technically sound on paper. A sandbox can be built on solid isolation technology and still fail in practice if the model operating inside it can be manipulated into systematically probing for the gaps that technology, like any system, inevitably has somewhere.

How to handle resource limits and runaway execution within a sandbox

An AI system operating with autonomy inside a sandbox needs explicit, enforced limits on how much it can consume, execution time, memory, the number of tool calls or actions it can take within an interaction, since without these limits a system that enters an unproductive loop, repeatedly retrying a failing action, generating increasingly elaborate reasoning that never converges on a solution, can consume resources indefinitely with no natural point where the behavior stops on its own.

These limits need to be enforced at the sandbox level itself, not merely suggested through the system’s instructions or expected to emerge from the model’s judgment about when it’s done enough, since a model caught in exactly this kind of unproductive loop is, by definition, not exercising the judgment that would otherwise make it stop. A hard externally enforced limit, a maximum number of steps, a maximum execution time, a maximum resource budget, gives the system a backstop that doesn’t depend at all on the model itself recognizing that it should stop, which is exactly the judgment call it’s failing to make correctly in precisely the scenario the limit exists to catch in the first place.

What happens when a limit is hit deserves its deliberate design, rather than simply terminating the process silently and leaving whoever’s waiting on the result with no useful signal about what happened. A system that hits its resource limit should surface that fact clearly and honestly distinguishing a resource exhaustion from a successful completion, so that whoever’s monitoring the system, human or automated, can recognize the pattern and investigate why the system keeps running into this particular limit, rather than simply seeing an unexplained, confusing gap in its actual results with no explanation attached.

How sandboxing interacts with tool use and function calling

Modern AI systems increasingly operate through tool use, where a model doesn’t directly execute arbitrary code but instead calls a defined set of functions, each with its narrower scope. This particular pattern makes sandboxing somewhat more tractable than sandboxing arbitrary code execution directly, since each individual tool can be independently, separately scoped and independently, properly contained, but it also means the security of the overall system depends heavily on each individual tool being properly sandboxed in its own right, since a broad, insufficiently contained tool undermines the careful scoping applied to every other tool the system has access to.

This means an audit of tool-based sandboxing needs to examine each individual tool on its own, not merely the system’s overall architecture taken as a whole, since a system that looks well-contained at the architectural level can still carry serious risk if even one of its available tools, a file write function, a database query tool, a code execution tool, was built with broader access than the system’s actual task requires. The single weakest individually sandboxed tool effectively sets the security boundary for the entire whole system, regardless of how carefully every other single tool was scoped on its own.

Tool combinations also deserve their attention here, since a system with several individually, well-scoped tools can still enable an action none of those tools would ever permit on its own in isolation, a read tool combined with a network tool can together enable exactly the kind of data exfiltration that neither tool alone would have made possible by itself, meaning sandbox design has to consider not just what each individual tool can do on its own but what becomes possible when a model can chain several of them together in a deliberate sequence.

How to sandbox multi-step or long-running agent tasks

A task that unfolds over many steps, rather than resolving in a single action, introduces sandboxing considerations that a single, bounded interaction doesn’t raise. Each individual step in a considerably longer task might look entirely, perfectly reasonable in isolation while the overall trajectory of the task drifts somewhere the system was never meant to go at all, meaning sandboxing for multi-step tasks benefits from periodic, deliberate checkpoints that evaluate the task’s overall trajectory, not merely each individual step’s narrow, local safety in isolation, since a sequence of individually safe steps can still add up to an outcome nobody would have approved if they’d seen the full, complete picture right from the start.

Long-running tasks also raise a practical question about how sandbox boundaries persist over real time, since a task that runs for an extended period needs its containment to remain consistently, reliably enforced throughout that entire duration, not merely at the moment the task was initially, originally launched, and a sandbox environment that was correctly, carefully configured at launch but drifts, through some external change to the broader infrastructure it sits within, can end up considerably less contained by the time a long-running task finally completes than it was back when that task originally began.

How to deliberately test sandbox boundaries rather than assuming they hold

A sandbox’s security depends on how it holds up under deliberate, adversarial pressure, not merely on how it was designed to behave in documentation or in the straightforward, non-adversarial cases that typically get tested first. Testing a sandbox means actively attempting to break out of it, feeding the system inside it content and instructions specifically designed to probe for gaps, exactly the kind of adversarial testing that guardrail systems undergo more broadly, applied here specifically to the containment boundary rather than to the model’s behavioral constraints.

This testing needs to be ongoing rather than a one-time exercise performed before a system first launches, since the broader infrastructure a sandbox sits within changes over time, new dependencies get added, configurations drift, and a sandbox that held firm under testing at launch can develop new gaps as the environment around it evolves in ways nobody was specifically watching for from a sandbox-security perspective. Treating sandbox testing as a periodic, recurring practice rather than a mere launch-time checkbox to tick once and forget gives an organization a chance to catch this kind of drift before it’s discovered through an actual incident, rather than only ever through deliberate, proactive testing done well ahead of time.

How sandboxing connects to guardrails, access control, and agent governance

Sandboxing doesn’t operate as an isolated defense, it works alongside guardrails, access control, and agent governance as one layer within a broader defense-in-depth approach to AI system safety. Guardrails aim to shape what a model attempts to do in the first place, access control determines what data and resources a request can reach, and sandboxing provides the containment that limits the consequence even when the other layers fail, whether through a guardrail that didn’t catch a manipulation or an access control gap that let a request through it shouldn’t have.

This layered relationship matters because none of these individual defenses is sufficient entirely on its own, and organizations that invest heavily in guardrails and access control while treating sandboxing as a mere afterthought are missing the exact layer specifically designed to contain the failures the other layers will, inevitably, occasionally have somewhere along the way. A well-designed sandbox doesn’t make guardrails or access control unnecessary, but it does mean that when those other layers fail, and any system’s layers eventually will in some instance, the actual consequence of that failure stays contained rather than cascading into the broader infrastructure the sandbox was built to protect.

Sandboxing also connects directly to agent governance’s emphasis on scope and escalation, since a sandbox’s actual boundaries should reflect exactly the scope an agent was approved for under formal governance review, and a sandbox that grants broader access than an agent’s governed scope calls for quietly undermines the governance decision itself, regardless of how carefully that governance review was originally conducted in the first place.

How sandbox design should account for the difference between untrusted input and untrusted output

Conventional sandboxing usually starts from the premise that whatever’s inside the boundary is untrusted, an attacker-supplied script, a plugin from an unknown developer, and the sandbox exists to contain that inherently suspect code. AI sandboxing has to hold two related but distinct kinds of distrust at once: the input a model receives can be adversarial, crafted deliberately to manipulate the model’s behavior, and the output the model produces can be dangerous even when the model wasn’t deliberately manipulated at all, simply because the model made an ordinary mistake in judgment about what action was appropriate for the situation in front of it. A sandbox built only around the assumption of adversarial input misses the equally real risk of a well-intentioned model still taking a harmful action through nothing more than an honest error in judgment.

This distinction matters for how a sandbox’s logging and review practices get designed, since catching deliberate manipulation benefits from scrutiny focused on the input side, what content the model was exposed to before it took an action, while catching an honest mistake benefits from scrutiny focused on the output side, what the model decided to do and whether that decision made sense given a reasonable reading of its actual task. A sandbox review practice that only ever asks whether the input looked suspicious will miss the large category of harmful actions that trace back to nothing more exotic than a model honestly reasoning its way, entirely in good faith, to the wrong conclusion about what its actual task called for in that moment.

How sandbox design differs for systems that operate with financial or physical-world consequences

A sandbox containing a system whose actions only affect data, a database record, an internal document, a draft communication awaiting human review, carries meaningfully lower stakes than a sandbox containing a system that can move money, control physical equipment, or take an action that once taken can’t be undone. Sandboxing designed for this higher-stakes category needs correspondingly, considerably stronger containment, often including a human approval step built directly into the sandbox boundary itself for any action above a defined threshold of consequence, rather than simply trusting the sandbox’s technical isolation alone to catch every case that warrants a second look from an actual person before it’s ever allowed to proceed.

This particular category also benefits from a sandbox architecture that makes the irreversibility of an action explicit and visible to everyone involved, distinguishing clearly between actions the sandbox allows to proceed automatically on their own and actions that require this additional human checkpoint before proceeding, since treating every single action as equivalently reversible, when some honestly aren’t reversible at all, means the sandbox’s containment logic can end up permitting exactly the category of action that most needed a human’s deliberate attention before it was ever allowed to happen out in the real world where it truly mattered.

How to think about the performance cost of sandbox isolation

Isolation isn’t free, running code inside a properly contained sandbox environment typically carries overhead compared to running that same code directly against the underlying infrastructure, whether that overhead comes from the isolation mechanism itself, a virtualized or containerized execution environment, or from the additional checks a well-designed sandbox performs on every action before allowing it to proceed. This overhead creates a temptation to weaken containment in the name of raw performance, particularly for systems where response latency matters directly to the user experience, and organizations under pressure to ship a fast, responsive AI feature can find themselves quietly, gradually trading away containment for speed without ever making that tradeoff an explicit, deliberate decision anyone signed off on knowingly.

Resisting this temptation well means treating sandbox performance as its engineering problem worth solving directly and deliberately, rather than simply treating weaker containment as the default, easy answer whenever performance becomes a concern worth worrying about. Techniques like pre-warming sandbox environments so the isolation overhead is paid well before a request really arrives, or scoping the sandbox tightly enough that its internal checks stay fast precisely because they have very little surface area to check in the first place, let an organization keep containment while still meeting performance requirements, rather than treating the two as a strict, forced tradeoff where one always has to lose for the other to win.

When a tradeoff between containment and actual performance does turn out to be truly unavoidable in a case, that tradeoff deserves to be made consciously and explicitly by someone with the actual authority to accept the resulting risk, documented clearly enough that the decision can be revisited later on, rather than quietly emerging through a series of individually reasonable-looking engineering shortcuts that nobody ever consciously decided added up to a meaningfully weaker sandbox than the system needed all along.

How sandbox design should treat the model provider’s infrastructure as part of the boundary

Many AI systems run their actual model inference on infrastructure operated by an external provider rather than infrastructure the organization directly controls, and this arrangement means a complete picture of the sandbox has to account for where the provider’s infrastructure sits relative to the organization’s containment boundary, not merely for the containment the organization has built around the parts of the system it directly operates itself. Sandboxing designed as though the entire system sits within the organization’s direct control, when a meaningful portion of it runs on a third party’s separate infrastructure instead, can leave a concrete gap precisely where the organization’s visibility and actual control end and the provider’s separate practices begin instead.

This means the vendor evaluation practices already discussed elsewhere, in the context of AI data security apply here too, specifically, deliberately extended to ask what containment and isolation guarantees a model provider honestly offers around the inference process itself, and whether those guarantees are sufficient for how the organization intends to use the resulting system, rather than simply assuming a reputable provider’s infrastructure is automatically as well-contained as the organization’s carefully, deliberately built sandbox around the rest of the system it directly controls.

Common mistakes teams make around AI sandboxing

Several distinct patterns show up often enough across organizations building AI systems with real-world capabilities that naming them directly is worth doing before they’re discovered through an actual incident.

1. Treating a sandbox as sufficient defense on its own, without the guardrails and access control that should be shaping what the system attempts before it ever reaches the sandbox’s boundary.

2. Building a single, broad, shared sandbox environment used across multiple different AI systems rather than scoping each one’s containment to what its task requires.

3. Failing to revisit a sandbox’s boundaries as a system’s capabilities and available tools expand, leaving containment that matches an earlier, narrower version of the system rather than its current actual scope.

4. Assuming a sandbox’s isolation technology being sound guarantees the sandbox holds, without testing what happens when a model operating inside it is deliberately manipulated into probing for boundary weaknesses.

5. Relying on a model’s instructions or judgment to stop an unproductive loop rather than enforcing hard, external resource limits at the sandbox level itself.

6. Terminating a resource-limited process silently, leaving no clear signal that distinguishes resource exhaustion from a successful, ordinary completion.

7. Auditing a system’s overall sandbox architecture without individually examining each available tool, missing that one broadly scoped tool can undermine every other tool’s careful containment.

8. Overlooking what becomes possible when several individually well-scoped tools are chained together, even when no single tool alone would permit the resulting action.

9. Evaluating each step of a multi-step task in isolation without checking the overall trajectory, missing a drift that no individual step would have flagged on its own.

10. Treating a long-running task’s sandbox as fixed at launch, without accounting for how the surrounding infrastructure can drift and weaken containment over the task’s actual duration.

11. Testing sandbox boundaries once at launch rather than as an ongoing, recurring practice that accounts for how the broader environment changes over time.

12. Building a sandbox that grants broader access than an agent’s governed scope calls for, quietly undermining a governance decision that was otherwise carefully made.

13. Assuming static analysis of a model’s code or weights can predict its actual runtime behavior well enough to substitute for sandbox containment.

14. Leaving network access unscoped within the sandbox, allowing arbitrary outbound connections rather than an explicitly defined, narrow set of permitted destinations.

15. Treating sandboxing as purely a technical infrastructure decision made once during initial system design, rather than a security practice that needs ongoing attention as the system, its tools, and its surrounding environment all continue to evolve.

16. Designing sandbox review practices that only scrutinize suspicious input, missing the equally significant category of harmful actions that trace back to a well-intentioned model simply reasoning its way to the wrong conclusion.

17. Treating every sandboxed action as equivalently reversible, letting a system with financial or physical-world consequences proceed automatically through the same containment logic built for a system whose worst-case action is merely a draft document nobody’s read yet.

18. Weakening sandbox isolation for the sake of performance through a series of individually reasonable-looking shortcuts, without anyone ever consciously deciding to accept the resulting containment risk.

19. Building sandbox containment as though the entire system sits within the organization’s direct control, overlooking the gap that opens wherever inference runs on a third-party provider’s infrastructure instead.

What connects all nineteen of these mistakes is a single underlying pattern: treating sandbox containment as a one-time, static technical decision rather than an ongoing discipline that has to track a system’s actual, evolving scope and hold up under deliberate, adversarial pressure, rather than merely under the straightforward, easy cases that happen to get tested first. A sandbox built correctly on day one and never revisited afterward is, by the time a system’s tools, scope, and surrounding infrastructure have all moved on, very often protecting against a version of the system that no longer exists anymore.

The deeper principle underneath all of this is that sandboxing exists precisely because an AI system’s behavior can’t be fully, reliably predicted or fully constrained through instruction alone, and an organization that treats careful prompting or well-designed guardrails as sufficient on their own, without the containment a sandbox provides, is effectively betting the entire safety of its system on every other single layer working perfectly, every single time, when the actual purpose of containment is to remain safe specifically in exactly the cases where something else, somewhere in the broader system, inevitably, eventually doesn’t hold.