How should security teams design agent sandboxes when allowing LLMs to write and run code?

Security teams should treat code execution as a controlled runtime, not a convenience feature. The sandbox needs hard limits on CPU, memory, time, filesystem access, and network reach. It should expose only approved data and functions, and it should keep auditable records of what ran. That design reduces exfiltration risk, especially when prompts are manipulated or the agent composes unsafe actions inside the sandbox.

Why sandbox design matters when the model can execute code

Letting an LLM write code is one problem; letting it run code is another. The sandbox becomes the trust boundary that decides whether a bad prompt, a mistaken plan, or a malicious input turns into local damage, data exposure, or network abuse. That means the sandbox should be designed as a constrained runtime with explicit resource ceilings, narrow data access, and observable execution rather than as a general-purpose compute environment.

For agentic workflows, the main failure is not only obviously malicious code. It is also the ordinary-looking snippet that reaches too far, reads too much, or chains together actions the operator did not intend. Current guidance in OWASP Agentic AI Top 10 and NIST AI governance both point to the same practical requirement: constrain tool use, limit authority, and keep human-readable audit trails. In practice, teams usually discover sandbox weaknesses only after an agent has already had enough access to make the failure visible.

How to build the sandbox controls

A useful sandbox starts with least privilege at the runtime layer. Code should run with short-lived execution, capped CPU and memory, bounded storage, and deterministic timeout handling. The filesystem should be isolated from the host, with only specific working directories or read-only inputs mounted. Network egress should default to deny, then open only the exact destinations the workflow needs, because unrestricted outbound access turns a sandbox into a staging point for exfiltration, callback traffic, or dependency fetching.

Just as important is data shaping. The sandbox should not inherit broad secrets, user mailboxes, full repositories, or production databases simply because the agent may need “context.” Instead, expose curated inputs, redacted samples, or purpose-built functions that return only the minimum necessary result. Execution should be mediated through approved APIs or wrappers, not arbitrary shell access, when the task can be expressed that way. For higher-risk workflows, use separate sandboxes for code generation and code execution so a bad model output does not also get privileged access to the runtime that executes it.

Limit CPU, memory, wall-clock time, and process count per run.
Block default network access and allowlist only required endpoints.
Mount only the smallest possible filesystem surface, preferably read-only.
Inject secrets only through narrowly scoped, ephemeral interfaces.
Log prompts, code, outputs, policy decisions, and network calls for later review.

These controls tend to break down when teams mix exploratory development with production-like data, because the pressure to “just make it work” quickly widens the sandbox until it no longer behaves like one.

Common trade-offs and failure cases

Tighter sandboxes often reduce developer friction only after they have reduced debugging convenience, package availability, and execution speed. That trade-off is real, so the right design is usually tiered: low-risk tasks get the smallest sandbox, while controlled exceptions are reserved for specific workloads with stronger review and monitoring. The important judgement is to treat exception handling as a policy decision, not an ad hoc debugging habit.

One common edge case is code that must inspect documents, repositories, or web content to complete a task. The sandbox can support that, but it should do so through pre-approved data feeds or retrieval layers rather than unconstrained network and filesystem reach. Another edge case is prompt injection inside retrieved content, which can steer the generated code toward unsafe reads, writes, or outbound calls. A good sandbox cannot prevent every bad instruction, but it can keep the consequences bounded when the model follows one.

The same caution applies when teams try to rely on static code review alone. Review helps, but sandboxing is the last line of containment when the model synthesises an unsafe command sequence faster than a reviewer can notice it. For agentic systems, the right question is not whether the code looks plausible, but whether the runtime would still be safe if the code were wrong in exactly the way the attacker wants.

Risk and Threat Considerations

Agent sandboxes reduce the blast radius of prompt injection, unsafe tool use, and autonomous code paths that drift beyond the intended task. The material risk is data exfiltration, unauthorized system access, and uncontrolled side effects if the sandbox can reach too much of the host, network, or secret store.

Failure mechanism: An attacker, or a manipulated prompt, induces the agent to generate code that reads sensitive files, calls external endpoints, or uses inherited credentials. If the sandbox permits broad egress, persistent storage, or ambient secrets, that code can exfiltrate data or stage follow-on abuse while appearing to be normal execution.

Impact: Teams can lose confidentiality, contaminate logs or artifacts, trigger unintended production actions, and undermine incident attribution because the dangerous action was executed inside an apparently legitimate automation path.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	A2 — Tool Misuse and Overprivilege	Code-executing agents need tightly bounded tool and runtime authority.
	A6 — Prompt Injection	Sandboxed code can still be steered by injected instructions and hostile inputs.
	A8 — Insecure Output Handling	Generated code becomes dangerous when outputs are executed without containment.
Recommendation — Restrict tool scope and privileges to the minimum required for each run. Treat untrusted inputs as hostile and confine their effects with layered controls. Validate and constrain generated outputs before execution or deployment.
NIST AI RMF	GOVERN — Govern AI risk	Sandboxing code-running agents is an AI governance decision about bounded authority.
	MEASURE — Measure and monitor AI risks	Auditability and runtime logging are needed to detect unsafe agent behavior.
Recommendation — Define governance for agent execution boundaries, approvals, and accountability. Measure sandbox behaviour with logs, alerts, and recurring abuse tests.
CIS Controls v8	6 — Access Control Management	Sandbox design depends on least privilege for code, data, and execution paths.
	8 — Audit Log Management	Auditable execution records are essential when LLM-generated code is run.
	12 — Network Infrastructure Management	Network egress limits are central to preventing sandbox-based exfiltration.
Recommendation — Apply least privilege to every sandboxed process, credential, and data path. Collect and retain execution logs, prompts, outputs, and access events. Segment and restrict outbound network paths from the sandbox by default.
NIST CSF 2.0	PR.AC — Access Control	Sandbox boundaries are an access-control problem for code, data, and network reach.
	DE.CM — Continuous Monitoring	The sandbox must be observable to spot unsafe execution and policy bypasses.
Recommendation — Enforce least-privilege access across execution, storage, and connectivity. Monitor sandbox activity continuously for anomalous commands, data access, and egress.

Practitioner Guidance

What to prioritise: Put network egress, secret handling, and filesystem boundaries ahead of package convenience. Those three controls usually determine whether a bad run becomes a contained error or a real incident.

What to verify: Test the sandbox with deliberately malformed prompts and unsafe code paths, then confirm that the run is still blocked, the audit trail is complete, and no unintended data left the environment. If the sandbox cannot prove those properties, treat it as unfinished.

Decision rule: If a task needs broad host access to succeed, do not “soften” the sandbox by default. Split the workflow, narrow the data input, or move the task to a higher-trust pathway with explicit approval and monitoring.

Practitioner takeaway: The goal is not to make code execution harmless, it is to make every allowed action small enough, visible enough, and reversible enough that a bad agent output does not become a broad compromise.