AI Agent Sandboxing: How to Isolate Untrusted Agent Actions

An agent that can execute code is no longer just a text-generation feature.

It is an application that can create files, run commands, install dependencies, access networks, and potentially modify valuable state. Even when the intended workflow is harmless, inputs and generated actions can be manipulated.

Sandboxing provides a second line of defense. Instead of asking the model to behave safely, the runtime limits what its actions can actually reach.

Why prompts are not a sandbox

A system prompt can say never access production credentials or only modify files inside a workspace. Those rules are useful, but they are not a security boundary.

A model can misunderstand them. Retrieved content can conflict with them. A tool can contain a bug. A prompt injection can influence the next action.

A sandbox changes the situation by limiting the environment itself.

What should be isolated?

Sandboxing is particularly valuable for AI coding agents, browser agents, document processors, generated-code execution, data transformation pipelines, agents that install packages, and workflows that process untrusted repositories or uploaded files.

The exact boundary depends on risk.

A research agent may need network restrictions and temporary storage. A coding agent may need process isolation, package restrictions, and much tighter filesystem controls.

Start with filesystem isolation

An agent should not automatically receive the host filesystem.

Give it a temporary workspace. The agent can create and modify files there while sensitive host paths remain inaccessible.

Mount only what is necessary. A repository checkout may be mounted into the sandbox, while operating-system configuration, credentials, and unrelated user directories remain outside it.

Restrict the network

Network access is often overlooked.

If generated code can reach arbitrary hosts, a compromised agent may exfiltrate data even when filesystem permissions look safe.

For higher-risk workflows, use an allowlist or controlled proxy. The agent might reach an approved package registry and one business API while arbitrary destinations are blocked.

Limit resources

An agent can accidentally or intentionally create expensive workloads.

Examples include infinite loops, huge file generation, recursive tool calls, repeated API requests, runaway browser sessions, and expensive model calls.

Use limits for CPU, memory, execution time, output size, tool calls, network bandwidth, and spending.

These controls reduce both security risk and unexpected cost.

Use disposable environments

The safest execution environment is often one that disappears after the task.

Create → execute → collect approved output → destroy.

Do not preserve unnecessary credentials, caches, temporary files, or agent state between unrelated jobs. Persistence increases the amount of state an attacker can influence.

Separate execution from authorization

Sandboxing does not replace authorization.

An agent can be safely isolated and still be authorized to perform an operation it should not perform.

Think about the two questions separately:

• Authorization: should this action happen?
• Sandboxing: where can this action happen?

For example, a coding agent may be allowed to modify a feature branch inside an isolated environment but not push directly to production.

Test the boundary

A sandbox should be tested like any other security control.

Verify that the agent cannot read host secrets, access unrelated files, reach blocked network destinations, consume unlimited resources, persist unexpected state, or modify production resources directly.

Do not only test successful workflows. Test malicious and malformed inputs as well.

A practical architecture

A production flow can look like:

Request → Policy check → Create isolated runtime → Agent execution → Tool authorization → Collect approved artifacts → Security checks → Destroy runtime

The model remains probabilistic, but the environment becomes deterministic about what is reachable.

Sandbox choices

The isolation technology should match the risk. A lightweight process boundary may be acceptable for low-risk transformations. Containers can provide stronger filesystem and process separation. More sensitive workloads may need a dedicated virtual machine or hardened execution service.

Do not treat the word sandbox as proof of safety. Review what the runtime actually isolates, especially kernel access, mounted files, network interfaces, host sockets, environment variables, and package installation.

Handling generated artifacts

The output of a sandbox should pass through another boundary before entering production.

Scan generated files, validate expected file types, check package manifests, and reject unexpected executables or configuration changes. If an agent generates a deployment artifact, do not automatically promote it simply because execution inside the sandbox succeeded.

The sandbox proves containment during execution. It does not prove that the resulting artifact is safe.

Final takeaway

Sandboxing is valuable because it assumes the agent can make a mistake.

Do not build an architecture that requires perfect model behavior. Give the agent the smallest useful environment, restrict the network, cap resources, isolate files, separate authorization from execution, and destroy temporary state when the task ends.

A trustworthy agent system is not one where nothing goes wrong. It is one where a wrong action has a small blast radius.

Source: OWASP AI Agent Security guidance.

A practical rollout plan

Begin by writing down exactly what the agent needs to execute. If it only needs to transform a file, it probably does not need a full shell, unrestricted network access, or access to the host operating system.

Create a minimal runtime around that requirement. Give it a temporary filesystem, a defined working directory, restricted environment variables, and explicit network rules. Then add CPU, memory, time, output, and tool-call limits.

Next, test escape paths. Try reading parent directories, accessing mounted host sockets, discovering environment variables, reaching blocked destinations, installing unexpected packages, and creating very large files. These tests should be automated and repeated whenever the sandbox runtime changes.

Finally, inspect the artifacts leaving the sandbox. A generated deployment file, package, script, or configuration should be validated before it enters a trusted environment. Successful execution inside a sandbox is not proof that the resulting artifact is safe.

The most useful mindset is containment rather than trust. The agent is allowed to be capable inside a small box. The box is what protects everything outside it.