# Sandboxes Aren't Optional: 4 Ways to Isolate Coding Agents — Robert Brennan, OpenHands

## Executive summary

The talk emphasizes that as AI coding agents evolve from simple chat snippets to autonomous, cloud-based systems, robust sandboxing is mandatory to enforce the Principle of Least Privilege. Running agents locally with skipped permissions exposes the entire local file system and secrets. The speaker compares four strategies—Docker, GitHub Actions, dedicated VMs, and Kubernetes—concluding that Kubernetes offers the most robust, scalable, and isolated solution by providing an ephemeral, dedicated pod for every agent session.

## Key takeaways

- The Danger of Local Agents: Running coding agents locally with `--dangerously-skip-permissions` grants the agent access to the entire local file system, environment variables, and connected production resources, creating a massive security risk.
- Principle of Least Privilege (PoLP): Agents must only have access to the specific resources (e.g., a single GitHub repo and necessary secrets) required to perform their assigned task, limiting the 'blast radius' of potential failures or attacks.
- Kubernetes for Maximum Isolation and Scale: Using Kubernetes pods per session provides the highest level of isolation and infinite scale, as each agent runs in a fresh, ephemeral environment that is destroyed after use, eliminating long-term state risks.

## Technical details

- Local Docker Containers: Docker provides ephemeral environments, which is beneficial for containment (e.g., if the agent runs `rm -rf`), and allows selective mounting of local resources (Git repos, ports). However, this strategy does not scale well for event-driven cloud workflows.
- Cloud Code with GitHub Actions: This strategy moves agents off the local machine into an ephemeral GitHub Actions environment. It offers built-in secrets management and scheduled/event-driven triggers (e.g., on PR open), but is proprietary and limited to GitHub webhooks.
- Dedicated VM or Mac Mini: Provides a long-lived, persistent environment, allowing agents to listen for diverse webhooks (e.g., Slack, DataDog). The major drawback is the 'co-locating problem,' where multiple agents share the same machine and can potentially access or interfere with each other's memory or resources.
- Kubernetes Pods per Session: The most robust method, providing cloud scale and high isolation. Each agent gets its own dedicated, ephemeral pod that spins up and then completely disappears. This allows for fully automated, event-driven workflows (e.g., responding to HTTP events from Slack/Jira) without worrying about long-term state.
- Sandboxing Limitations: Sandboxing is not a panacea. There is evidence of container escape attacks (e.g., observed during Mythos testing), meaning careful configuration and monitoring are still required.

## Practical implications

- When deploying autonomous AI agents, prioritize cloud-native, highly isolated environments (like Kubernetes) over local or co-located setups.
- Always implement the Principle of Least Privilege by strictly limiting agent access to only the necessary repositories, secrets, and services.
- Use specialized tools (like OpenHands Agent Canvas) that allow toggling between different sandbox types (Docker, VM, Kubernetes) to match the required workflow.

## Topics

AI Agents, Sandboxing, Principle of Least Privilege, Docker Containers, GitHub Actions, Virtual Machines (VMs), Kubernetes, CI/CD Automation, OpenHands, OpenHands (GitHub)

Source: https://www.youtube.com/watch?v=iH_wV8BbS24
