Containers Don't Make Your AI Agent Safe

Core problem: AI agents + untrusted code (especially npm)

• Users worry that AI agents might delete data or damage computers.
• Two risky options are commonly discussed:
  1. Strict permission prompts from the AI (too slow, interrupts productivity).
  2. Allow-all execution (no safety boundaries → risk).
• Additional warning: npm has frequent security vulnerabilities. Malicious packages can steal API keys and cause damage—even if you aren’t “using AI.”

Proposed solution: Docker Sandboxes (secure execution via isolation)

The video’s solution is to run AI/agentic coding (and regular coding) inside sandboxes implemented as microVMs (small, fast-to-start VM layer).

Key security properties

• The sandbox is isolated from the host OS, so code can’t access system credentials/files/databases unless explicitly allowed.
• This insulates you from npm package attacks because credentials and host resources are not reachable from inside the sandbox.

Promised benefit

• You can run with no permission babysitting while remaining protected.

---

Tutorial / setup workflow (Docker Sandbox + agentic coding)

1) Install and authenticate

• Go to Docker Sandbox “Getting Started”.
• Run the install command (downloads an spx tool).
• Use spx login, which opens Docker and authenticates with a Docker account.

2) Understand “sandbox vs container vs VM”

• A container may run your agent/code, but the key protection is that it sits inside a microVM sandbox.
• microVM:
  • faster/lighter than traditional full VMs,
  • isolated so the sandbox can’t reach host resources by default.

3) Create a sandbox for an AI agent (example: GitHub Copilot)

• Create a sandbox using spx run ... with Copilot agent config.
• On first run, the tool asks about network policy:
  • Open: allow all network (not recommended)
  • Balanced: default deny, but allow common dev sites (recommended)
  • Locked down: block everything unless allowed (most restrictive)
• After initial setup (slow due to downloads), subsequent runs are quicker.

4) Secure credential handling (avoid putting real tokens into the sandbox)

The speaker warns against logging in inside the sandbox because it would expose credentials to code running there.

Instead, inject credentials using sandbox secrets:

• Use spx secret ... to set a global secret (example: GitHub token).
• They demonstrate reading a token via git/CLI + echo (command) so the token isn’t typed into the sandbox context.

Important mechanism described

• The sandbox does not directly see the real token.
• A proxy/middleman intercepts requests, injects the credential externally, then forwards the request to GitHub.
• Result: even if malicious code tries echo $GitHub_token, it won’t reveal the real token.

5) File system isolation and demo

• Inside the sandbox, ls shows only sandbox workspace files.
• Attempts to cd to host paths or delete outside files fail.
• A “nested” sandbox example shows the sandbox can be restricted to a subfolder (can’t access sibling/outside files).

---

Extra hardening option: cloned sandboxes (git worktree isolation)

In the default (non-clone) mode, changes can mirror back into your local project subset, which can still be risky.

• Example risk: malicious code adding Git hooks could run on your normal machine.

Clone mode: d-clone

• Uses git worktrees to create a separate tree inside the sandbox.
• Changes won’t appear in your normal workspace until you explicitly pull/checkout them.

Recommended work pattern

• Commit sandbox changes to a sandbox-backed branch.
• From the host, fetch/checkout that sandbox branch.
• Review as if it were a PR before running anything locally.

Tradeoff

• Safer, but more cumbersome; recommended when pre-commit/hooks risk is high.

---

Network security policies (allow/deny specific domains)

By default, external access is heavily restricted.

• Example: querying ESLint docs fails with “fetch failed” due to locked-down external API routes.

Network policy commands

• spx policy ls network — list allowed network targets
• spx policy allow ... <domain> — allow a domain globally (example: eslint.org)
• spx policy rm ... — remove a rule (domain no longer accessible)

They demonstrate restarting and then re-running the doc fetch successfully after allow-listing.

---

Advanced feature: custom sandboxes (“kits”) for local AI (PI)

Create a custom kit template

Docker Sandbox supports custom templates via a kit folder.

For a Pi-based local agent, the tutorial:

• Creates a folder (example: pi)
• Adds spec.yaml defining:
  • schema version
  • agent name (used as the command name for spx run <name>)
  • entrypoint (e.g., run pi)
  • persistence
  • allowed network domains (for PI update checks)
  • install command (installs PI via npm install)
  • user permissions (recommend 1000 instead of root)

Run the kit

• Use d-kit <directory> to reference the kit directory.
• If schema fields differ across versions, the tutorial mentions persistence may need removal.
• Result: you land in a Pi terminal inside the sandbox.

Configure local models (LM Studio) inside the sandbox

You need to allow network access to the local model endpoint:

• allow localhost (and the port noted, example 127.0.0.1:1234)

Add model config files into the kit so they’re copied into the sandbox:

• Use a files/home/ directory naming approach.
• Provide:
  • off.json for LM Studio provider settings
  • models.json listing model IDs, context window, etc.

Docker networking detail:

• Use host.docker.internal instead of localhost so the container can reach the host’s LM Studio.

Demonstrate local model usage

• Recreate the sandbox after adding model config files.
• The first prompt may be slow (“warm up” / GPU load), later prompts are quicker.

---

Reusable “skills” via mixins (modular add-ons)

Another kit type concept is introduced: skills as mixins (plugin-like installers).

• Purpose: install common tools/extensions/skills across multiple agent types (Pi, Copilot, Claude Code, etc.).

Steps described

• Create a skills kit using a spec.yaml that mainly installs skills via:
  • npx skills add <URL> --global -y
• Add the kit to an existing sandbox project using kit commands (kit add).
• Example shows installing a “fine skills” default skill set.

Kits stored on GitHub + combining kits

• Kits can be referenced by URL (git repo) with:
  • git+<url>#dir=<folder>
• Show how to:
  • run Pi from a GitHub kit URL
  • add another kit (e.g., skills kit) on top
  • run both together to get Pi + installed skills

---

Main speakers / sources

• Speaker: Kyle (host of WebDev Simplified)
• Product / tool source: Docker Sandbox (Docker-sponsored)
• Referenced technologies/services: GitHub Copilot, npm, Git, LM Studio, PI (local AI via Pi.dev / Pi npm package), plus ESLint docs for network-policy testing.