Build a Sandboxed AI Agent on Ubuntu Using Docker

You can run an AI agent on Ubuntu today in a Docker container that cannot touch your home directory, your SSH keys, or your Docker daemon. It takes about 15 minutes.

You need Ubuntu 24.04, Docker 24 or later, and a workspace folder. No Kubernetes, no special kernel modules.

Table of Contents

Quick Answer: How Do You Sandbox an AI Agent with Docker?

Create one workspace directory and keep secrets outside it. Run the container as a non-root UID with –read-only, –cap-drop ALL, –network none, memory and CPU limits, and only the input mounted read-only plus one writable output folder. Verify the limits from inside the container, then delete the container when done. Fifteen minutes, no Kubernetes.

Key takeaways:

Never mount the Docker socket, host root, home directories, or live Git checkouts into an agent container.
Runtime writes go to one output folder only. Dependencies belong in the image build, not in agent runtime.
Test the cage before trusting it: failed writes and failed pings are the proof it works.

1. Create an isolated workspace

Give the agent one directory and nothing else. The host keeps secrets outside it:

mkdir -p /srv/agent-work/input /srv/agent-work/output
echo "test task" > /srv/agent-work/input/task.txt
ls -R /srv/agent-work
docker --version

We tested these steps with Docker 29.1.3 on Ubuntu 24.04. Keep your .env, ~/.ssh, and cloud credentials outside /srv/agent-work.

2. Run the agent container with limits

This starts Ubuntu with no network, read-only root filesystem, no extra Linux capabilities, and your workspace mounted read-only except for an output folder:

docker run --rm -it 
  --user $(id -u):$(id -g) 
  --read-only 
  --cap-drop ALL 
  --network none 
  --pids-limit 128 
  --memory 1g --cpus 1.0 
  -v /srv/agent-work/input:/work/input:ro 
  -v /srv/agent-work/output:/work/output:rw 
  -w /work 
  ubuntu:24.04 bash

Inside the container, verify the limits:

whoami; id
touch /should-fail 2>&1 | head -1
ping -c1 8.8.8.8 2>&1 | head -2

The touch should fail (read-only root) and ping should fail (no network). That is the point.

3. Allow network only when the task needs it

If the agent needs to call a model API, do not open full internet. Run with no network by default, then allow only the API host when required. Docker documents why broad daemon access and host mounts are dangerous (Docker Engine security). For stronger VM-level isolation, Docker now documents Docker Sandboxes with microVMs, which is worth reading before you give an agent full sudo.

# Example: allow network only for this run, then stop the container
docker run --rm -it --user $(id -u):$(id -g) 
  --cap-drop ALL --read-only 
  -v /srv/agent-work/input:/work/input:ro 
  -v /srv/agent-work/output:/work/output:rw 
  ubuntu:24.04 bash

Give the agent one API host without opening the internet

Sooner or later the agent needs to call a model API, and --network none starts feeling absolute. The pattern that holds up is an allowlist proxy: the container gets a network that can reach exactly one egress proxy on the host, and the proxy forwards only to the API hosts you name. The agent never sees raw internet, DNS still resolves through your controlled path, and every outbound call shows up in one proxy log.

# A dedicated bridge keeps agent traffic separate from everything else
docker network create agent-net

# Point the agent at your allowlist proxy, not at the internet
docker run --rm -it --user $(id -u):$(id -g) 
  --cap-drop ALL --read-only 
  --network agent-net 
  -e HTTPS_PROXY=http://host.docker.internal:3128 
  -e HTTP_PROXY=http://host.docker.internal:3128 
  -v /srv/agent-work/input:/work/input:ro 
  -v /srv/agent-work/output:/work/output:rw 
  ubuntu:24.04 bash

Run any small forwarding proxy on the host with an allowlist of model API domains, and reject everything else. If a prompt injection ever tells the agent to download something from a strange domain, the proxy says no and the attempt lands in your logs instead of on your network.

4. Never mount these into an agent

/var/run/docker.sock ? gives container control of the host Docker daemon.
/ or /home ? exposes SSH keys and cloud credentials.
Write access to your Git checkout ? lets the agent modify hooks and workflows. Use a copy instead.

FAQ

Does read-only break apt and pip? Yes, by design. Install dependencies in your image build step, not at agent runtime. Runtime should only write to /work/output and /tmp.

Can I use this with Ollama? Yes. Run Ollama on the host and expose only the API port to the container, or run the model fully local. See Run an Open-Weight LLM on Ubuntu With Ollama.

How do I clean up? docker rm the container and delete /srv/agent-work/output when done. Nothing else on the host was writable.

What if the agent needs to install packages at runtime? Rebuild the image with the packages baked in instead. Runtime installs need network and write access, which defeats the two strongest limits in this setup. Treat the image as the dependency manifest.

Does this work on Docker Desktop for Mac and Windows? The flags are the same, but mounts and user mapping behave differently outside Linux. For agents with real credentials, prefer an Ubuntu host or VM where --user, read-only roots, and capability drops behave predictably.