Why AI Agents Need Sandboxes

An AI agent that can only generate text is relatively easy to contain.

An AI agent that can read files, execute code, access the network, install packages, call APIs, and modify systems is a different kind of software entirely.

The moment an AI agent can take actions, security becomes an infrastructure problem.

That is why AI agents need sandboxes.

What is an AI agent sandbox?

An AI agent sandbox is an isolated environment where an agent can perform actions without having unrestricted access to the host system or surrounding infrastructure.

Instead of allowing an agent to operate directly on your machine:

AI Agent
   │
   ├── filesystem
   ├── shell
   ├── network
   ├── credentials
   └── host system

you give it a controlled environment:

                 AI Agent
                     │
                     ▼
              ┌─────────────┐
              │   Sandbox   │
              │             │
              │ filesystem  │
              │ processes   │
              │ packages    │
              │ network     │
              └─────────────┘
                     │
              controlled access
                     │
                     ▼
              External systems

The difference is enormous.

The agent can still do useful work, but its blast radius is constrained.

Why normal application security isn't enough

Traditional applications generally follow a predictable execution model.

A request arrives.

Code executes.

The application follows rules written by developers.

An AI agent introduces another decision-making layer.

The developer defines the tools available to the agent, but the model determines which tools to call and in what sequence.

For example:

User
  │
  ▼
Agent
  │
  ├── read_file()
  ├── execute_command()
  ├── install_package()
  ├── HTTP request
  └── write_file()

The model may generate a sequence of actions that the developer did not explicitly anticipate.

That doesn't mean the model is malicious.

It means the system has to assume that the model can make mistakes.

A sandbox provides a boundary around those mistakes.

What should an agent sandbox isolate?

At minimum, there are four important boundaries.

1. Filesystem

The agent shouldn't automatically have access to your entire filesystem.

Instead, give it a dedicated workspace:

/sandbox/workspace

and restrict access outside it.

This prevents an agent working on one project from accidentally reading unrelated files, configuration files, SSH keys, or application secrets.

2. Network

Network access is another major boundary.

A sandbox might allow:

github.com       ✓
npmjs.com        ✓
api.example.com  ✓
internal-db      ✗
metadata-service ✗

The principle is simple:

Allow only the network access the agent actually needs.

OpenAI's current sandbox-security guidance similarly recommends restricting outbound traffic to approved endpoints.

3. Credentials

Never assume that because an agent is inside a sandbox, secrets are automatically safe.

A sandboxed process should not receive every credential available to the host.

Instead:

Agent
  │
  ▼
Credential broker
  │
  ├── GitHub token
  └── deployment token

Credentials should be scoped to the minimum permissions required.

4. Compute resources

An agent shouldn't be able to consume unlimited CPU, memory, disk space, or processes.

You can impose limits such as:

CPU:       2 cores
Memory:    4 GB
Disk:      10 GB
Runtime:   5 minutes
Processes: 20

This protects the infrastructure from runaway workloads.

A sandbox is not just a container

This distinction matters.

You will often hear:

"Just put the agent in Docker."

Docker can be an important isolation layer, but containerization alone isn't a complete security model.

A production agent environment may need multiple layers:

                  Agent
                    │
             ┌─────────────┐
             │ Application │
             │ permissions │
             └──────┬──────┘
                    │
             ┌──────▼──────┐
             │   Sandbox   │
             └──────┬──────┘
                    │
             ┌──────▼──────┐
             │ Container / │
             │     VM      │
             └──────┬──────┘
                    │
             ┌──────▼──────┐
             │ Network     │
             │ isolation   │
             └──────┬──────┘
                    │
             ┌──────▼──────┐
             │ Host        │
             └─────────────┘

The exact architecture depends on the threat model and workload.

For higher-risk workloads, stronger isolation such as dedicated virtual machines may be appropriate.

Why this matters more as agents become more capable

A chatbot usually produces an answer.

An agent can produce a sequence of actions.

Consider an AI coding agent.

It might:

1. inspect a repository
2. modify files
3. install dependencies
4. execute tests
5. start a development server
6. make HTTP requests
7. inspect the results
8. modify the code again

That is extremely useful.

But it also means the agent has become a software execution environment rather than merely a text-generation system.

OpenAI's current sandbox-agent documentation reflects exactly this model: agents can receive files, run commands, install packages, expose ports, create artifacts, and preserve state across work.

The real architecture

A production agent shouldn't look like:

LLM → Shell → Machine

A safer architecture looks more like:

                    User
                     │
                     ▼
                  AI Agent
                     │
                Tool request
                     │
                     ▼
              Policy / Guardrail
                     │
          ┌──────────┴──────────┐
          │                     │
       Allowed                Denied
          │                     │
          ▼                     ▼
       Sandbox               Reject
          │
     ┌────┼─────┐
     ▼    ▼     ▼
   Files Shell Network

The model proposes an action.

The system decides whether that action is permitted.

That distinction is fundamental.

The principle: don't trust the agent

The safest mental model is not:

"The AI should behave itself."

It is:

"The AI may behave unexpectedly, so the system must remain safe anyway."

That is the same philosophy behind many distributed systems and security architectures.

You don't build a system assuming every component will behave perfectly.

You build boundaries.

You limit permissions.

You isolate failures.

You observe what happens.

And you provide a way to stop the system.

The future of agent infrastructure

As AI agents become capable of operating computers, interacting with APIs, and completing multi-step tasks, the sandbox increasingly becomes part of the basic runtime architecture.

The interesting shift is that we're no longer just asking:

"How do we make the model smarter?"

We're also asking:

"How do we give a smarter model enough freedom to be useful without giving it enough freedom to damage the system?"

That is fundamentally an infrastructure problem.

And that's why AI agent security isn't just an AI problem.

It's a systems problem.