Kategorie: Kubernetes

Coding Agent Horror Stories: The rm -rf ~/ Incident

This is Part 2 of our AI Coding Agent Horror Stories series, an in-depth look at real-world security incidents exposing the vulnerabilities in AI coding agents, and how Docker Sandboxes deliver workspace-scoped isolation that contains the worst failures at the execution layer.

In part 1 of this series, we mapped six categories of AI coding agent failures and the architectural reason they keep happening: the agent runs as you, on your filesystem, with your credentials, and nothing sits between the model’s decision and the shell’s execution. For Part 2, we’re going deep on the most destructive failure mode in the entire ecosystem: an AI coding agent deleting a developer’s entire home directory in a single command.

Today’s Horror Story: The Tilde That Wiped a Mac

In December 2025, a Reddit user posting under the handle u/LovesWorkin shared what became one of the most-discussed AI coding agent incidents of the year. They had asked Claude Code to clean up an old repository. Claude executed rm -rf tests/ patches/ plan/ ~/, and the trailing ~/ wiped their entire Mac.

This wasn’t a CVE. It wasn’t a sophisticated attack. It was the AI coding agent doing exactly what it was told, in a way the user did not anticipate, with no architectural boundary to catch the mistake.

In this issue, you’ll learn:

How a single trailing slash in a rm -rf command erased a developer’s entire Mac

Why the –dangerously-skip-permissions flag exists, and why developers keep using it anyway

The pattern this incident shares with the GitHub-issue-#10077 Ubuntu wipe and the Claude Cowork family-photos incident

How Docker Sandboxes contains this entire class of failure at the execution layer

Why This Series Matters

Each “Horror Story” in this series examines a real-world incident that turns laboratory findings into production disasters. These aren’t hypothetical attacks. They’re documented cases with named victims, screenshotted command logs, and in several cases, public apologies from the vendors. Our goal is to show the human impact behind the security statistics, demonstrate how these failures unfold in practice, and provide concrete guidance on protecting your AI development infrastructure through Docker’s workspace-scoped execution model.

The story begins with something every developer has done: asking the agent to clean up an old repository.

The Problem

On December 8, 2025,a developer posting under the handle u/LovesWorkin shared a Reddit thread on r/ClaudeAI with the title that says everything: “Claude CLI deleted my entire home directory! Wiped my whole mac.” The post climbed past 1,500 upvotes within hours, was amplified by Simon Willison on X, covered by Gigazine in Japan on December 16, and became one of the most-discussed AI coding agent incidents of 2025.

The setup was unremarkable. The user asked Claude Code to clean up packages in an old repository. Routine maintenance, the kind any developer would hand off without thinking. Claude generated and executed:

rm -rf tests/ patches/ plan/ ~/

On the surface, this is a command to delete three project directories. The fatal error is the trailing ~/. In Unix, ~ expands to the user’s home directory. ~/ with the trailing slash means “everything inside the home directory.” Combined with rm -rf, which removes recursively and without confirmation, the command deletes the user’s entire home directory in a single shot.

Within seconds, the developer had lost:

The Desktop, Documents, and Downloads folders

The Library folder containing application state for every app on the system

The Keychain, which broke authentication across every app, including Claude Code itself, which could no longer talk to its own backend

Years of project files, family photos, and work product

All of it on an SSD where TRIM had already zeroed the freed blocks by the time recovery was attempted

There was no recovery. As the developer put it in the original thread: “It nuked my whole Mac! What the hell?”

Caption: Once an AI agent gains direct filesystem access, “organize my desktop” can become catastrophic.

The Scale of the Problem

This wasn’t a one-off. It was an instance of a pattern.

On October 21, 2025, weeks before the LovesWorkin incident, developer Mike Wolak filed GitHub issue #10077 against the Claude Code repository. Wolak’s report described a similar failure on Ubuntu/WSL2: Claude Code had executed rm -rf starting from root, and the logs showed thousands of “Permission denied” messages for /bin, /boot, and /etc as the agent worked its way through the system trying to delete files it didn’t own. Every user-owned file on the system was gone. Anthropic tagged the issue area:security and bug. The damning detail in Wolak’s report: he was not running with –dangerously-skip-permissions. Claude Code’s permission system simply failed to detect that the agent’s command would expand destructively before the user approved it.

Two weeks later, on November 28, 2025, GitHub issue #12637 documented yet another variant. Claude Code had earlier created a directory literally named ~ by mistake. Later, when the agent tried to clean up that directory by running an unquoted rm -rf ~, the shell expanded ~ to the user’s actual home directory before rm saw the argument. Same destructive outcome, completely different mechanism. The agent had found a new way to destroy a developer’s work.

Shortly after the January 2026 launch of Anthropic’s Claude Cowork, Nick Davidov, founder of a venture capital firm, used Anthropic’s Claude Cowork, a general-purpose AI agent product to organize his wife’s desktop. He explicitly granted permission for temporary Office files only. The agent deleted a folder containing 15 years of family photos, somewhere between 15,000 and 27,000 files, via terminal commands that bypassed the macOS Trash entirely. Davidov recovered the photos only because iCloud’s 30-day retention happened to still be in effect. The Trash had been bypassed entirely.

These aren’t isolated stories. They’re the same story with different file paths.

How the Failure Works

To understand why these incidents keep happening, we need to look at the architecture of how a modern AI coding agent executes commands on a developer’s machine. The agent is doing exactly what its design says it should do. The architecture is the failure.

The Coding Agent (Claude Code, Cursor, Replit, Kiro) is an AI-driven shell. It reads your prompt, reasons about how to satisfy it, generates a command, and runs that command directly on your operating system. There is no separate “execution proposal” step that a human approves. The reasoning step and the execution step are the same step.

The User’s Shell is whatever shell the agent inherited when you launched it. On macOS, that’s typically zsh. The agent’s commands run through this shell with the developer’s full user permissions. ~ expands to the developer’s home directory because that’s what ~ means in zsh.

Permission Inheritance is implicit and total. Whatever the developer’s shell can do, the agent can do. There is no separate identity for “the agent acting on the developer’s behalf.” The agent is the developer for as long as the session lasts.

The –dangerously-skip-permissions Flag, which Lanzani’s technical blog post analyzes in detail, is what removes the one safety net that exists by default. Without the flag, Claude Code asks for confirmation before each shell command. With it, the agent runs commands in the background while the developer goes back to other work.

That last point is the one that matters. The flag exists because the default behavior, asking for confirmation on every shell command, makes multi-step tasks tedious. Developers add the flag to make the agent useful. The agent then becomes capable of executing destructive commands without intervention. The flag is named honestly. It is a dangerous flag. But it is also a popular one, because the alternative is approving every ls and cat the agent runs.

The vulnerability happens between steps 2 and 3. The agent reasons about what command to run. The shell executes that command on the host. Nothing sits in between. There is no architectural boundary that says “this command would delete the user’s home directory, refuse to run it.” The shell sees a syntactically valid rm -rf and does what rm -rf does.

Technical Breakdown: How a Trailing Slash Wipes a Mac

Here’s how the incident unfolds, step by step:

Caption: Diagram illustrating how unrestricted AI agent execution can escalate a simple cleanup task into full home-directory destruction

1. The User’s Request

The developer asks Claude Code to clean up packages in an old repository. The prompt is the kind of thing every developer types daily:

Please clean up unused test files, patches, and plan documents from this old repo.

2. The Agent’s Reasoning

The agent identifies three directories that match the request: tests/, patches/, and plan/. It then generates a rm -rf command, because removing directories recursively is the standard way to delete them. So far, this is correct behavior.

3. The Hallucinated Argument

The agent appends ~/ to the command. We don’t know exactly why. Possibly the agent inferred that “clean up” included tidying the home directory. Possibly it generated ~/ as a no-op separator and didn’t realize it was a destructive argument. Possibly its training data included shell snippets where ~/ appears in this position and it pattern-matched. The result either way is the same:

rm -rf tests/ patches/ plan/ ~/

This is a syntactically valid shell command. There is nothing in the syntax that says “this is dangerous.”

4. Shell Expansion

When this command runs in zsh on macOS, the shell expands ~/ to /Users/loveswarkin/. The command becomes, effectively:

rm -rf tests/ patches/ plan/ /Users/loveswarkin/

The shell does not warn. It does not confirm. It does not flag the home directory as protected. There is no system-level check that says “this command would delete a user’s entire home directory.” The shell does what shells do: expand the path and execute.

5. Recursive Force Deletion

rm -rf walks the filesystem under each argument and deletes everything. The Desktop, Documents, Library, Keychain, Application Support folders, Claude Code’s own config and credentials, the user’s SSH keys, the user’s git config, the user’s photos. All of it. In order. Without pausing.

The deletion runs to completion in seconds because most of these files are small, and the SSD’s controller acknowledges deletes nearly instantly. By the time the user notices their terminal is unresponsive and tabs out to check, it’s done.

6. The Aftermath

The keychain is gone, which means every app that authenticates against the keychain is now logged out. Mail, browsers, Slack, GitHub Desktop, every service that stored a token, every saved password. The user’s identity infrastructure on that machine is gone.

Claude Code itself can no longer authenticate, because its own credentials lived in the home directory. The agent that did the destruction can’t even apologize properly, because it can’t connect to its own backend.

The Impact

Within a single command execution, the developer has:

Lost years of personal and professional files

Lost cryptographic keys (SSH, GPG) needed to access remote systems

Lost authentication state for every app on the system

Lost git history for any uncommitted work

Inherited a system in a partially-broken state where logging back in and reinstalling apps will take days

There is no recovery path. SSDs with TRIM enabled (which is the default on every modern Mac) zero freed blocks at the controller level, so even forensic recovery tools come up empty. The data is not “deleted” in the sense of “marked unavailable but recoverable.” It is gone.

This is what one trailing slash in one AI-generated command produces.

How Docker Sandboxes Eliminates This Attack Vector

The current AI coding agent ecosystem forces developers into the same dangerous tradeoff that the MCP ecosystem forced on users in Part 1 of our companion series. Every time you run claude –dangerously-skip-permissions or any equivalent flag in another agent, you’re executing arbitrary AI-generated commands directly on your host system with full access to:

Your entire file system

Your home directory and everything in it

Your credentials, keychain, SSH keys, and cloud config

Every running process and every network connection your shell can make

This is exactly how the rm -rf ~/ incident achieves total system destruction. The agent runs as the developer, on the developer’s filesystem, with no architectural boundary to stop it.

Docker’s Security-First Architecture

Docker Sandboxes represents a fundamental shift in how AI coding agents execute. Rather than running directly on the host with user-level permissions, the agent runs inside a microVM with its own kernel, its own filesystem, and its own network. The agent’s view of ~/ is the workspace mount, not the developer’s actual home directory. The developer’s actual home directory simply does not exist from inside the sandbox.

Docker Sandboxes are managed through the sbx CLI. A quick distinction worth making: Docker Sandboxes are the isolated microVM environments where agents actually run. sbx is the standalone CLI tool used to create, launch, and manage them. Sandboxes are the environments. sbx is what you type to control them.

Docker Sandboxes solves the rm -rf ~/ class of failure by making the destructive command architecturally impossible. The agent can absolutely generate rm -rf tests/ patches/ plan/ ~/. It can absolutely run that command. The command will absolutely succeed. But what gets deleted is the workspace inside the sandbox, not the developer’s actual home directory. The host filesystem isn’t visible from inside the microVM, so there is nothing to delete.

Workspace-Scoped Execution

The most important architectural shift is that the agent’s filesystem view is the workspace mount, and only the workspace mount.

# Install sbx and sign in
brew install docker/tap/sbx
sbx login

# Launch the agent inside a sandbox scoped to the project directory
cd ~/my-project
sbx run claude

Three commands and the agent is now running inside a microVM. From inside the sandbox, the agent’s ~/ IS the workspace, not the developer’s actual home directory. The Library folder, the keychain, the SSH keys, the AWS config – none of that exists inside the sandbox. The agent cannot reach what it cannot see.

A rm -rf ~/ from inside the sandbox deletes the workspace files. The developer can throw the sandbox away with sbx rm and start fresh. The host system is untouched.

Blocked Credential Paths

Even if a developer explicitly mounts additional paths into the sandbox, common credential directories are blocked from being mounted by default:

# Credential roots blocked by default:
# ~/.aws ~/.ssh ~/.docker ~/.gnupg
# ~/.netrc ~/.npm ~/.cargo ~/.config

# A misconfigured mount that tries to include these is rejected
# before the sandbox even starts.
sbx run claude

This blocklist directly addresses the keychain-deletion fallout from the LovesWorkin incident. Even an agent that decides to recursively delete its workspace cannot reach the credentials that keep the developer’s authentication state intact.

Read-Only Mounts for Sensitive Workspaces

For workflows where the agent should read but not write to a directory, the :ro suffix declares a mount as read-only:

# Mount the project workspace as writable, the docs as read-only
sbx run –name docs-review claude /path/to/project /path/to/docs:ro

A rm -rf against a read-only mount fails at the kernel level. The microVM enforces the mount mode, which means the agent cannot decide to override it through reasoning, prompt manipulation, or flag misuse. The infrastructure decides what’s writable. The model doesn’t get a vote.

Git-Worktree Isolation for Risky Operations

For destructive operations like cleanup tasks, refactors, and “let me just clean this up” requests, sbx run –branch lets the agent operate on an isolated Git worktree:

# Create a sandbox on a fresh feature branch
sbx run –name cleanup-agent –branch=cleanup/old-files claude .

# Review what got cleaned up before merging
sbx exec cleanup-agent git diff main

# If the agent did something destructive, throw it away
sbx rm cleanup-agent

This is the architectural answer to “the agent decided to drop and recreate the schema.” The agent’s changes never touch the main branch until the developer reviews them. If the agent runs rm -rf ~/, the worktree gets wiped and the main branch is untouched. The developer reviews git diff main, sees what happened, and decides whether to merge or discard.

Throwaway Sandboxes by Design

The final piece is that sandboxes are designed to be discarded:

# When the work is done, list active sandboxes and remove the one you're done with:
sbx ls
sbx rm <sandbox-name>

This is what makes the Docker Sandboxes model fundamentally different from running an agent on the host. On the host, a destructive command leaves permanent damage. Inside a sandbox, every session is throwaway. The worst the agent can do is destroy the workspace, which is reproducible from the source repo. The keychain, the credentials, the years of personal data, none of those can be touched, because none of those exist from inside the sandbox.

What This Looks Like in Practice

Here’s the LovesWorkin incident replayed under Docker Sandboxes. The user asks the same question. The agent generates the same command. The shell executes the same expansion.

# After Docker Sandboxes:
$ cd ~/my-project
$ sbx run claude
> Please clean up unused test files, patches, and plan documents
[Agent runs: rm -rf tests/ patches/ plan/ ~/]
[Workspace inside the sandbox wiped. Host home directory intact.]

# The sandbox is throwaway. List it and remove it to start fresh:
$ sbx ls
$ sbx rm <sandbox-name>

The agent’s behavior is identical. The architectural outcome is completely different.

The Practical Improvements

Security Aspect

Traditional AI Coding Agent

Docker Sandboxes

Execution Environment

Direct host execution as the user

Isolated microVM with its own kernel

Filesystem View

Full host filesystem, including ~/

Workspace mount only

Credential Access

All credentials in user’s home dir

Credential paths blocked by default

Destructive Command Impact

Permanent host damage

Throwaway sandbox

Review Before Merge

None

Git worktree isolation with sbx exec <sandbox-name> git diff main

Recovery

Often impossible (TRIM zeroes blocks)

sbx rm and start fresh

Best Practices for Secure AI Coding Agent Deployment

Stop running coding agents directly on your host. Containerization or microVM isolation should be the default, not an advanced option.

Use sbx run for every coding task that involves filesystem operations. Especially “clean up,” “organize,” “refactor,” and “delete unused” prompts. These are the prompt categories most likely to produce a destructive rm -rf.

Use Git worktrees for destructive operations. sbx run –name <name> –branch=<branch> claude ensures the agent’s changes are reviewable before they touch your main branch.

Never use –dangerously-skip-permissions on the host machine. If you need the agent to run commands without per-command approval, run it inside a sandbox. The sandbox boundary is what makes “skip permissions” safe.

Treat the sandbox as throwaway. Don’t store anything important inside it. The whole point is that you can sbx rm and start fresh.

Audit the policy log. sbx policy log shows every allowed and denied connection attempt, which becomes your forensics trail if something does go wrong.

Take Action: Secure Your AI Coding Agent Today

The path to safe AI coding agent execution starts with one command. Here’s how to move away from running agents on the host:

Install Docker Sandboxes. Visit the Docker Sandboxes documentation to install sbx and run your first sandboxed agent in under five minutes.

Try it with your existing workflow. sbx run claude (or sbx run cursor, sbx run codex, etc.) drops your existing agent into a microVM with no configuration changes required.

Read the architecture deep-dive. The Docker Sandboxes architecture documentation explains the microVM model, the workspace mounting, and the network policy layer.

Browse the MCP Catalog. If your agent uses MCP servers, the Docker MCP Catalog provides containerized, verified servers that complement sandboxed agent execution.

Conclusion

The LovesWorkin incident, the Mike Wolak Ubuntu wipe, the Claude Cowork family-photos deletion, and the GitHub issue #12637 shell-glob expansion bug are all the same story. An AI coding agent reasoned its way through a task, generated a command that contained a destructive argument, and the shell executed it because there was nothing in the architecture to say “this command would destroy the developer’s work.”

These aren’t bugs in Claude Code, or Cursor, or Kiro, or any individual agent. They’re properties of the execution model. As long as agents run on the host with the user’s permissions, this category of failure will keep happening, with new variations each time.

Docker Sandboxes doesn’t try to make the agent smarter. It changes where the agent runs. The agent gets a workspace. It does not get your machine.

Coming up in our series: Issue 3 will explore the AWS Cost Explorer outage, where Amazon’s own Kiro agent decided to delete and rebuild a production environment in seconds, and what scoped-identity sandbox configuration prevents that class of failure.

Learn More

Run agents safely with Docker Sandboxes: Visit the Docker Sandboxes documentation to get started with workspace-isolated agent execution in minutes.

Explore the Docker MCP Catalog: Discover MCP servers that connect your agents to external services through Docker’s security-first architecture.

Download Docker Desktop: The fastest path to a governed AI agent environment, with Docker Sandboxes, MCP Gateway, and Model Runner in a single install.

Read the MCP Horror Stories series: Start with issue 1 to understand the protocol-layer security risks that complement the agent-layer risks covered here.

Quelle: https://blog.docker.com/feed/

What is Sandbox Security?

If you’re already familiar with sandboxing as an isolation technique, sandbox security is the next layer: the policies, controls, and enforcement mechanisms that make sure those isolation boundaries actually hold under real-world pressure.

According to our State of Agentic AI report, 40% of respondents cite security as the top challenge in scaling agentic AI, and 43% point to increased security exposure from orchestration sprawl. As agents execute code, call APIs, and interact with live infrastructure, a sandbox without strong enforcement is a locked room with an open window.

This piece goes deeper into what sandbox security looks like day to day. We’ll cover how to choose the right implementation model and why this layer of security matters now more than ever as AI agents start executing code in your infrastructure.

Key takeaways

Sandbox security is the practice of enforcing isolation boundaries and access controls around sandboxed environments to prevent threats from escaping containment.

Effective sandbox security combines multiple layers: process isolation, network segmentation, resource limits, and runtime monitoring.

As AI agents increasingly execute arbitrary code in production, sandbox security has become critical infrastructure for safe deployment.

What sandbox security means in practice

Sandbox security is the set of controls and enforcement mechanisms that prevent untrusted or risky processes from breaching their isolation boundaries. Where sandboxing creates the boundary, sandbox security ensures it holds.

As we mentioned before, a sandbox without strong security controls is like a locked room with an open window. The isolation exists in theory, but the enforcement gaps leave room for escape.

For developers and platform engineers, this translates into concrete, daily decisions: which system calls an agent is allowed to make, whether a process can reach the network, how much memory or CPU it can consume, and what happens when it tries to exceed those limits. These are not abstract policy questions. They’re flags you set, profiles you configure, and defaults you either audit or accept on faith.

5 Core components of sandbox security

Sandbox security is not a single control. It’s a combination of mechanisms that work together to keep isolation boundaries intact. The most effective implementations layer several of these components so that a failure in one area does not compromise the entire sandbox.

1. Process isolation

Process isolation ensures that code running inside a sandbox has no visibility into processes on the host or in other sandboxes. On Linux, kernel namespaces handle this by partitioning process IDs, network interfaces, file systems, and user IDs into separate scopes. A process inside a namespace sees only what you’ve explicitly made available to it.

When things go wrong. Run a container with –pid=host and you’ve just given that workload a window into every process on the machine. It can enumerate services, identify targets, and attempt to interfere with them. That single flag turns your sandbox into a shared apartment. 

Proper sandbox security eliminates this by enforcing strict namespace boundaries by default and flagging configurations that weaken them.

2. System call filtering

Even within a namespace, processes interact with the host kernel through system calls. System call filtering (commonly implemented through seccomp profiles on Linux) restricts which kernel functions a sandboxed process can invoke. Docker’s default seccomp profile blocks around 44 of the 300+ available Linux system calls. That’s a meaningful reduction in attack surface, but it’s a general-purpose default, not a tailored fit.

What to look for. High-security workloads benefit from custom seccomp profiles scoped to the specific application. A sandboxed process that needs to read files and make HTTP requests has no reason to call mount, init_module, or reboot. The tighter the profile, the fewer options an attacker has if they gain code execution inside the sandbox. It’s the same least-privilege thinking that underpins container security more broadly.

3. Network segmentation

A sandbox that can communicate freely with external systems or internal services is harder to defend. Network segmentation restricts what a sandboxed process can reach, limiting both inbound and outbound connections. That’s especially important for workloads that process untrusted input or execute arbitrary code.

How this applies to agents. AI agents that invoke external tools or APIs during execution present a unique challenge. Without network controls, a compromised agent could exfiltrate data to an external endpoint or pivot to internal services it was never intended to reach. Enforcing egress policies at the sandbox environment level ensures agents can only communicate with pre-approved destinations.

4. Resource limits and quotas

Resource exhaustion attacks do not require a sandbox escape, and that’s what makes them easy to overlook. A runaway process that consumes all available CPU or memory can take down every other workload on the same host without ever breaching an isolation boundary. Cgroups on Linux cap what each sandbox can consume, turning a potential host-wide outage into a single contained failure.

The tricky part is calibration. Set memory limits too low and legitimate workloads get OOM-killed. Set them too high and you’re back to sharing the blast radius. The most reliable approach is to monitor actual resource consumption over time, set limits based on observed peaks plus a margin, and treat the initial configuration as something you’ll tune rather than something you’ll get right on the first pass.

5. Runtime monitoring and audit trails

Prevention is only part of the equation. You also need to know what’s happening inside the sandbox. Runtime monitoring tools observe system calls, file access patterns, network connections, and process behavior as they occur. When something deviates from the expected baseline, the system can alert operators or kill the process automatically. If you’re evaluating AI governance tools, you’ll find that many of these runtime observability capabilities overlap directly with agent monitoring requirements.

Audit trails serve a different but equally important purpose. When an incident does happen, you need a forensic record of exactly what the sandboxed process did: which files it touched, which endpoints it called, which syscalls it made. That’s valuable for incident response and essential for compliance frameworks that require demonstrable evidence of isolation and access control.

Choosing an implementation model

Understanding the different sandboxing models is a good starting point, but the more useful question for sandbox security is: what does each model actually protect against, and what do you need to configure to make it hold? Here’s how they compare on the dimensions that matter for security decisions.

Model

Isolation boundary

Key security controls

Best for

Watch out for

OS-level

namespaces, seccomp, MAC

Shared kernel, separate namespaces

seccomp profiles, AppArmor/ SELinux policies, read-only rootfs, capability dropping

Container runtimes, CI/CD jobs, most production workloads

Kernel vulnerabilities bypass all controls; defaults are permissive

VM-based

microVMs, hardware virtualization

Separate kernel per sandbox

Hypervisor-enforced memory isolation, independent kernel patching, vTPM

Multi-tenant platforms, malware analysis, running fully untrusted code

Higher resource cost; networking and image management add ops complexity

Application-level

Wasm, browser tabs, language VMs

Within-process memory and API restrictions

Memory-safe execution model, restricted host API surface, capability-based permissions

Plugin systems, edge functions, embedded scripting

App compromise bypasses internal sandbox; should never be the only layer

The right choice depends on your threat model. For most containerized workloads, OS-level controls with a hardened seccomp profile and mandatory access control policy provide strong security at minimal overhead. VM-based isolation makes sense when you genuinely do not trust the code being executed, such as in multi-tenant environments or agent-driven code generation. Application-level sandboxing is a valuable addition in either case, but it should layer on top of kernel-level or hypervisor-level controls, never replace them.

Whichever model you choose, treat the default configuration as a starting point. The security of any sandbox does depend on the isolation technology, but whether someone actually audited the settings is the sticking point. It’s the same software supply chain security discipline that applies at every layer of the stack: trust, but verify the configuration.

Sandbox security for AI agents

Traditional applications follow predictable execution paths. You can read the code, trace the logic, and anticipate the behavior. AI agents are a different story. They make decisions at runtime, generate and execute code on the fly, call external tools, and produce outputs that their own developers may not have anticipated. That autonomy is the whole point of agents, but it’s also what makes sandbox security non-negotiable.

In these situations, perimeter-based security is not sufficient. You need controls that constrain agent behavior at the execution level, regardless of what the agent decides to do. It’s a fundamentally different security challenge. Teams building AI agent sandboxes are converging on a few patterns that address the unique risks agents introduce.

Isolating tool use 

When an AI agent invokes a tool (a code interpreter, a file manager, an API client), each tool execution should run inside its own sandbox with the minimum permissions required. If the agent’s tool-use layer is compromised, sandbox security prevents that compromise from reaching the host or other services.

Controlling data access

Agents often process sensitive data as part of their reasoning. Sandbox security controls which files, databases, and environment variables are visible inside the agent’s execution environment. A well-configured secure sandbox exposes only the data the agent needs for its current task, nothing more.

Enforcing network boundaries

Left unchecked, an agent with network access could make arbitrary HTTP requests, potentially exfiltrating data or interacting with unintended services. Network-level sandbox security restricts egress to an allowlist of approved endpoints.

Getting started with sandbox security

Start with your threat model. Which workloads process untrusted input? Which ones execute arbitrary code or handle sensitive data? Those are your highest-priority candidates for hardened sandbox security.

From there, layer controls rather than relying on any single mechanism. Combine process isolation with system call filtering, add network segmentation, set resource limits, and enable runtime monitoring. Each layer addresses a different category of risk. Together, they create a posture where any single failure stays contained.

If you’re already running containers, much of the foundation is in place. Container runtimes provide namespace isolation, seccomp profiles, and cgroup limits out of the box. The next step is to actually audit those defaults against your requirements and tighten what needs tightening. Docker Sandboxes extend this with purpose-built microVM isolation for agent workloads.

Start with Docker Sandboxes to put sandbox security into practice.

Frequently asked questions

What is the difference between sandboxing and sandbox security?

Sandboxing is the technique of running code in an isolated environment. Sandbox security is the broader discipline of ensuring that isolation actually holds. It’s the policies, configurations, monitoring, and enforcement mechanisms that make a sandbox resistant to escape, resource abuse, and unauthorized access. You can have a sandbox without strong security, but the isolation it provides will be unreliable.

Can sandbox security prevent all container escapes?

No single security measure can guarantee complete protection. Sandbox security significantly raises the bar by layering multiple controls (namespaces, seccomp, network policies, resource limits, runtime monitoring) so that an attacker would need to bypass several independent defenses. This defense-in-depth approach reduces risk to a level most organizations consider acceptable, especially when combined with regular patching and configuration audits.

How does sandbox security affect application performance?

The performance impact varies by implementation. OS-level controls like namespaces and seccomp add negligible overhead. Network policies and resource limits introduce minimal latency. VM-based sandbox security has higher overhead due to hardware virtualization, but technologies like microVMs have narrowed that gap significantly. For most workloads, it’s a trade-off that strongly favors security.

Is sandbox security relevant for AI and machine learning workloads?

Absolutely. AI workloads, particularly agents that execute code dynamically, are among the highest-priority use cases for sandbox security. These workloads are inherently unpredictable, and that’s exactly why strong isolation boundaries are essential. Sandbox security ensures that even if an agent produces unexpected behavior, the impact stays contained within its execution environment.

What compliance frameworks require sandbox security?

Several frameworks reference isolation and access controls that map directly to sandbox security practices. SOC 2 requires logical access controls and monitoring. PCI DSS mandates network segmentation for systems handling payment data. FedRAMP and NIST 800-53 include specific controls around process isolation and boundary protection. Organizations pursuing these certifications often find that container-based sandbox security, guided by a structured AI governance framework, provides a strong implementation foundation.

Quelle: https://blog.docker.com/feed/

The Untrusted Autonomous Workload: How AI Coding Agents Reshape What Isolation Has to Do

Earlier this year I mass-migrated my blog to Astro using Claude Code. 146 posts. 6,024 images. Canonical URLs, JSON-LD markup, sitemap generation, the whole stack. I’d spent hours writing a skills file to teach the agent about my blog’s architecture, how deployment worked, what not to touch. And it worked. Claude Code rewrote components, fixed trailing-slash mismatches across hundreds of pages, added BreadcrumbList structured data to hundreds of routes. Lighthouse scores hit 97 on performance. The blog looked better than it ever had.

The problem was that I had stopped understanding my own codebase.

Not completely. I could still read the files. But somewhere around the third round of “fix the error that the last fix introduced,” I caught myself copy-pasting stack traces back into Claude and trusting whatever came back. The agent would make a change, something else would break, I’d ask the agent to fix that too, and a few cycles later the blog worked again. I couldn’t have told you what was actually in the PostCSS config or why the GA4 integration was wired up the way it was. It worked. It looked great. My confidence in what was underneath had quietly evaporated.

That feeling (it works, thank god, let’s not touch it) is the feeling of having given an autonomous agent real access to your codebase. Every developer using these tools knows it. Nobody writes about it in vendor blog posts. And it’s what made me understand, on a level deeper than reading documentation, why Docker had to build Sandboxes.

Because here’s what I hadn’t thought about: while Claude Code was rewriting my Astro components and fixing image CLS across hundreds of files, every npm install it ran happened on my laptop. Same for every file it modified and every package it pulled. My user privileges, no boundary in sight. If the agent had decided to modify a Git hook or rewrite a CI workflow, I would not have noticed. I wasn’t reviewing individual file changes at that point. I was reviewing outcomes. And reviewing outcomes while skipping changes is not a security model. It’s a prayer.

Docker Sandboxes exists to close that gap.

The container model and why it doesn’t stretch here

Containers were never the wrong abstraction. They were the right abstraction for a world where you knew what was inside them. For twelve years that world held: you wrote the code, you reviewed it, you put it in a Dockerfile, and the container gave it a clean room to run in. Shared kernel was fine because the threat model was bugs in your own software, not surprises from a tenant you’d just invited in.

AI coding agents don’t fit. They aren’t bugs in your software because they aren’t your software. They’re a new kind of tenant, one that’s autonomous and privileged in ways that would make any security engineer nervous. The agent installs packages you didn’t pick and runs commands you didn’t script. It makes network calls you’d never have predicted, to endpoints you didn’t know were in your dependency tree. The trust profile is code being written right now, by something that won’t pause to ask permission. Containers were built for a different kind of code.

This isn’t hypothetical. On March 19, 2026, attackers force-pushed 76 of the 77 version tags in aquasecurity/trivy-action and published a malicious Trivy v0.69.4 binary to GitHub Releases. The exposure window was about 12 hours. The compromised code scraped CI runner memory for secrets, cloud credentials, SSH keys, and Kubernetes tokens, exfiltrating them to a typosquatted domain. Every pipeline that referenced trivy-action by version tag during that window ran code nobody on the receiving end had reviewed.

What gets me about Trivy: the weaponized tool was a vulnerability scanner. The thing organizations deployed to find malicious code became the malicious code. The maintainers didn’t write the bad binary; a compromised CI workflow with too much access and not enough containment did. Substitute “compromised CI workflow” with “AI agent in permissive mode” and you have the same threat model, running all day on every developer machine.

Containers were the right answer to “I trust this code, I want to run it cleanly.” They were never going to be the right answer to “I don’t fully trust this code, and I want to give it real work to do anyway.” That’s the gap microVMs fill.

What Docker built, and why each piece is there

First choice: don’t patch containers. There’s a long tradition in our industry of making a familiar abstraction handle a new problem by adding flags to it. Privileged mode, capability dropping, seccomp profiles, gVisor in front of runc. All of those have their place. None of them solved the specific issue that an autonomous agent needs its own Docker daemon. Docker-in-Docker either compromises the isolation (privileged mode, host socket mounting) or creates a nested complexity that becomes its own attack surface. The Docker docs are blunt about this. Containers, they say, share the host kernel and “can’t safely isolate something that needs its own Docker daemon.”

Once you accept that, you end up at a VM. Not a heavyweight one (booting Ubuntu Server for every coding session would be absurd) but a microVM: light enough to start in seconds, with just enough kernel to run the agent’s containers.

Docker Sandboxes uses a custom VMM, not Firecracker. If you’ve read the Firecracker spec and you’re thinking “boots in 125ms with under 5MB of overhead,” those are Firecracker’s numbers, not Docker’s. Different microVM implementations have different cost profiles. Platform specifics: Hypervisor.framework on macOS, Windows Hypervisor Platform on Windows, KVM on Linux.

Caption: The Sandbox architecture. Each microVM runs its own kernel and its own Docker Engine. Credentials never cross the VM boundary.

Inside each microVM, the sandbox runs a complete Docker Engine. When the agent runs docker build, that command goes to a private daemon that doesn’t know your host containers exist. When it pulls an image, the image lives inside the sandbox VM. When you delete the sandbox, the entire image cache goes with it. Multiple sandboxes don’t share layers. Wasteful. Worth it.

The first time I looked inside a running sandbox, the agent was running as root with sudo and full Docker Engine access inside the VM. My reflex was that this had to be wrong. You don’t give root to untrusted code. But the design is right: the isolation model doesn’t constrain what the agent does inside the boundary. It constrains where the consequences land. Inside the VM, the agent can do whatever it wants. Outside? Nothing. Trying to lock the agent down with capability dropping inside the VM would be solving the wrong problem. The agent legitimately needs to install packages and run docker build. What it doesn’t need is for any of that to touch your laptop.

Caption: From the host, sandboxes don’t show up in docker ps because they aren’t containers; sbx ls is how you see them.

The network layer is where it gets interesting, because it doubles as the credential boundary.

Outbound HTTP/HTTPS traffic routes through a proxy on the host, accessible from inside the VM at host.docker.internal:3128. UDP and ICMP are blocked at the network layer and can’t be allowed by policy. Non-HTTP TCP (like SSH) needs explicit IP+port rules. DNS resolution goes through the proxy. If a request can’t go through the proxy, it doesn’t leave. The proxy terminates TLS, inspects the host header, applies your policy, and re-encrypts with its own certificate authority that the sandbox trusts. Man-in-the-middle by design. Docker uses that exact framing in the documentation.

MITM is what makes credential injection work. Agents need API keys: for the AI provider, for registries, sometimes for cloud accounts. Naive answer is to pass those credentials in as environment variables, where they sit inside the VM and follow it everywhere. Docker instead keeps credentials on the host, in your OS keychain, and has the proxy inject them into outbound requests transparently. The agent sees requests that just work, and the VM never had the secrets to begin with. The docs don’t hedge on this: credential values are never stored inside the VM. A compromised sandbox can’t exfiltrate your API keys because your API keys were never in there.

Docker tells you what won’t work

Sandboxes documentation has a quality that’s rare in security architecture docs: it tells you what the system doesn’t protect against. Most of these documents are written to make a product look strong. Docker’s docs surface the limits. Two of them matter.

The first one is about the network policy.

At first sbx login, you pick one of three default policies. Open allows everything except blocked CIDR ranges (private networks, link-local addresses, cloud metadata endpoints). Balanced denies by default but pre-allows common dev domains. Locked Down denies everything until you explicitly allow. Locked Down is the strictest option, the deny-by-default mode you’d want if you were paranoid. But even with Locked Down and a curated allowlist, the proxy filters by domain, not by content.

Here’s the exact language from the docs: allowing broad domains like github.com permits access to any content on that domain, “and agents could use these as channels for data exfiltration.” Security vendors don’t usually say this about their own products. If github.com is on your allowlist (and it almost certainly is, because the agent needs to clone repos), the proxy knows the request is going to github.com. It does not know whether the agent is reading documentation, cloning a repository, or creating a public gist with the contents of your .env file. All three look identical at the domain level. Same goes for every allowlist entry that includes user-generated content: Discord webhooks, Notion pages. “The domain is allowed” doesn’t mean “only safe content lives there.”

Caption: Under a deny policy, non-allowlisted domains are blocked. Allowlisted domains succeed, including domains that host arbitrary user-generated content.

Docs also acknowledge domain fronting as an inherent limitation of HTTPS proxying. Proxy sees which domain a request claims to be going to; it cannot always prevent the request from being routed elsewhere through that allowed CDN.

The microVM boundary is the primary isolation. Network proxy is a useful additional control, especially for blocking accidental access to internal networks. It is not a hermetic seal, and Docker doesn’t claim it is. “The agent is on a deny policy” is not the same thing as “the agent cannot send data anywhere.”

The workspace is always shared

Network policy is the smaller honest limit. Workspace sharing is the bigger one.

The microVM boundary is strong everywhere except for one path that crosses it on purpose: the workspace directory.

The whole point of running an agent in a Sandbox is for the agent to do real work in your real codebase. Docker shares the workspace between the host and the sandbox at the same absolute path. When the agent edits a file inside the sandbox, the file changes on your host. When you pull a new commit on your host, the agent sees it. This is the design. It’s exactly what you want from a developer tool.

It’s also a covert channel that the agent has legitimate write access to.

Docker security documentation spells out what “the same files” includes, and this is what matters: files that execute implicitly during normal development. Git hooks. CI configurations. IDE task definitions. Makefile targets. package.json scripts. Pre-commit configs. Anything that runs when you do something that feels like just “using your tools.”

Simplest version of the attack: an agent inside the sandbox writes a malicious post-commit hook to .git/hooks/post-commit. Git hooks don’t appear in git diff. They live in .git/, which most developers never open. Next time you commit on your host, the hook runs on your host with your user privileges. Sandbox boundary doesn’t matter, because the boundary ended at the workspace, and the workspace was always shared.

Which brought me back to my own Astro migration, uncomfortably. I’d let Claude Code rewrite hundreds of files across my blog. I’d reviewed the outcomes (Lighthouse scores, visual appearance, build success) but I had not audited every file it touched. Had not checked .git/hooks/. I’d never opened that directory in my life. Had not read every package.json script before running npm install. I’d been doing exactly the thing the documentation warns about: treating the agent’s output as reviewed code when it was unreviewed code that I was about to execute on my machine.

It would be easy to read this as “Sandboxes are broken.” That’s not what I mean. The microVM does exactly what microVMs are supposed to do: it contains the consequences of arbitrary code execution behind a hardware boundary. What it cannot do is make the workspace contents safe, because the workspace contents are how the agent does its job. The agent has to be able to write files. You have to be able to read them. Shared region is necessary, and the shared region is where the threat model gets interesting.

Mitigation isn’t more isolation. The microVM is doing its job. Mitigation is discipline: treat the workspace contents the way you’d treat a pull request from a contributor you don’t know yet. Diff .git/hooks/ after agent sessions. Read package.json scripts before running npm install. Use the –branch flag, which creates a Git worktree so the agent works in an isolated branch you can review before merging. None of this is exotic. It’s just the practice of not treating autonomous-agent output as trusted code. Because it isn’t.

I’m spending this much space on it because it’s the part most people get wrong. Hypervisor boundary makes you feel safe, but you aren’t. Not completely. Both things have to be true at once for the product to work, and the Docker team built it that way on purpose. Good security architectures document their gaps and make sure the user knows what they’re signing up for.

What it actually costs

Hypervisor isolation isn’t free, and you can’t pretend otherwise. I tested this against my own production codebase, the same Astro blog I mentioned at the top, because synthetic benchmarks for sandboxed agent workloads don’t tell you much. You want to know what it feels like to do real work.

Caption: The same docker build –no-cache against the same Astro codebase. Host: 1:44.62. Sandbox microVM: 1:28.58. The isolation boundary is invisible to the workload. On this run, the sandbox actually finished faster.

I ran docker build –no-cache against the same Dockerfile and the same codebase, once on the host and once inside the sandbox. Host finished in 1:44.62. Sandbox finished in 1:28.58, actually faster, within noise across runs. The Docker Engine inside the sandbox is running on its own kernel with its own block device, completely isolated from the host, and the build doesn’t care. The microVM adds essentially zero overhead to the actual build.

One real-world caveat from running this on Apple Silicon: a Rust dependency in my Astro pipeline ships jemalloc that assumes 4K page sizes, which fails on sandbox VMs (16K pages). The build itself completed correctly. All 354 pages rendered, dist generated, but a teardown step exited non-zero. The fix was a one-line guard in the Dockerfile that checks for valid build output before exiting. Took 30 minutes to track down. Worth knowing about before you ship sandbox-aware Dockerfiles on Apple Silicon, because the symptom looks like a build failure when the build actually succeeded.

Verdict: for session-based agent work (a few hours on a project), the overhead disappears. For high-frequency sandbox creation (dozens per minute for short tasks), cold-start cost adds up. For the workload Sandboxes is designed for, which is giving an agent a real environment for a real session, the trade is sound.

Matching isolation to trust

Most discussions of containers versus VMs treat it as a binary, and that’s the wrong frame. The frame I’ve found useful, both for my own work and in conversations with engineering leaders who ask “do we really need microVMs for this?”, is a spectrum.

Caption: The Trust Spectrum. Match isolation strength to the trust profile of the workload.

On one end you have code you wrote yourself. Your team reviewed it, your CI tested it, your production runs it. A standard container is the right answer. Kernel is shared, daemon is shared, and none of that matters because the workload is known.

One step removed from that are CI/CD pipelines running your team’s code plus dependencies from registries you mostly trust. Mostly known, but the inputs are more variable. You add seccomp profiles, drop capabilities, write network policies.

Further along, supervised AI agents: tools that suggest code while a developer reviews each step. Human in the loop, so hardened containers with strict policies still work.

At the far end are autonomous AI agents. Nobody reviewing each command. Agents making decisions on your behalf, each one potentially different from the last. The trust profile isn’t “I trust this code” because there’s no fixed code to trust. It’s “I’m letting something operate on my system without supervision, and I want the failure mode to be ‘contained to a disposable VM’ rather than ‘on my laptop.’” That’s the workload that needs a microVM.

This is not a declaration that containers are obsolete. It’s the opposite. Containers are the right answer for everything on the left side of that spectrum, which is most of what runs in production today. MicroVMs extend the spectrum to the right, where containers were never going to be the right tool. The four isolation layers in Sandboxes (hypervisor, network, Docker Engine, credential proxy) are additive. They wrap containers in additional protection rather than replacing them. Inside every Sandbox is a microVM that runs containers. Containers haven’t gone anywhere, they’ve moved one level deeper in the trust stack.

“MicroVMs for AI agents, containers for everything else” is too crude. “Match the isolation to the trust profile of the workload” is the one that holds up.

Why everyone is converging here

Docker isn’t the only company that arrived at this answer, and the convergence tells you something.

Firecracker powers AWS Lambda and Fly.io’s microVM platform. gVisor intercepts syscalls in a user-space kernel. Kata Containers provides VM isolation behind a container-compatible interface. Modal runs serverless agent workloads on gVisor. E2B offers Firecracker-based sandboxes as a managed cloud service. Northflank ships Kata-based isolation for production AI workloads. All adopted at the same time, for the same reasons. Architecture everywhere looks the same: containers on the inside (because that’s how developers think), VM on the outside (because that’s where the boundary needs to be).

Docker Sandboxes is the local-first version. Most alternatives are cloud services where you pay per execution and your code runs on someone else’s machines. Docker put the same architecture on the developer’s laptop. CLI supports eight agents natively (Claude Code, Codex, Copilot, Gemini CLI, Kiro, OpenCode, Docker Agent, and Droid), plus a Shell mode for custom tooling. A standalone sbx CLI runs without Docker Desktop, so the architecture isn’t locked to a commercial product. MicroVM layer has an HTTP API that the open-source community has already started building on.

That’s a runtime. And Docker is positioning it to become the standard way to run autonomous coding agents, the way docker run became the standard way to run microservices ten years ago.

One more thing. Hardened Images and sandboxes address different layers of the same problem: Hardened Images for the supply chain (where binaries come from), sandboxes for runtime isolation (what those binaries can touch). Both exist because the assumption that “code from a trusted publisher is safe” stopped being reliable.

Looking back, looking forward

I’ve watched the industry rebuild its trust model three times in twenty years.

Bare metal to virtual machines, because we needed to put multiple workloads on the same hardware safely.

Virtual machines to containers, because we needed faster startup, lower overhead, and a packaging model that matched how developers actually ship code.

Now, containers to a different kind of virtual machine, because the workload changed and the kernel namespace stopped being enough. Not because containers were wrong, but because the new tenant needs more, and more looks like a hypervisor again.

Each of these transitions felt obvious in hindsight and contested at the time. I remember the arguments about whether containers were really secure enough for multi-tenant workloads. (They mostly weren’t, which is why we ended up with namespaced clusters and per-tenant VMs and gVisor and now microVMs for agents.) I expect the microVM argument to follow the same arc: contested for about a year, obvious within three.

My Astro migration taught me what it feels like to work alongside an autonomous agent that has real access to your system. More productive than doing it by hand, and more unsettling than I expected, once I realized how much I’d stopped tracking. Sandboxes don’t make the agent trustworthy. It just makes sure that when the agent does something you didn’t expect, the damage stays inside a box you can throw away. Workspace still requires your attention. Your skepticism. That combination (strong boundaries where you can enforce them, disciplined review where you can’t) is the model for working with autonomous code, and it’s probably going to stay that way for a while.

If you’ve been holding back on running AI coding agents because of permission prompts, accidental file changes, or just a feeling that something about the whole arrangement isn’t quite safe: that feeling was correct. Containers were the wrong fit for the workload. Sandboxes is the right one. Try it on a project you actually care about. That’s the only test that matters.

Get started with Docker Sandboxes →
Quelle: https://blog.docker.com/feed/

Meet Gordon: Docker’s AI Agent For Your Entire Container Workflow

Gordon understands your environment, proposes fixes, and takes action across your entire Docker workflow. Now generally available.

Image 1: Gordon in Docker Desktop

Why Gordon Exists 

Developers are more productive than ever. AI coding assistants are writing code, merging PRs and cutting review cycles. But the moment something breaks in a container, or a teammate hands you a service and says “ship it,” you’re on your own. 

Containers don’t break the way they’re supposed to. Build cache invalidates for no reason. Postgres can’t see Redis. The image works locally and crashes in CI. Or an error message links to a Stack Overflow thread from 2017. 

Modern software development is a stack of friction stacked on top of friction. And the AI tools you already use can’t help. Cursor doesn’t know what’s running. Copilot can’t read your logs. Claude Code can’t inspect your Compose file. They’re great at application logic, but they’re not built for everything that happens after code is written. They work from what you paste in. They don’t know your system.  

Docker’s AI Agent, Gordon, does.

Key takeaways

Gordon is Docker’s AI agent for your entire container workflow, built into Desktop 4.74+ and the CLI.

It already sees your environment, so you go from problem to fix in minutes instead of hunting for context.

Every action requires your explicit approval, and permissions reset when the session closes.

Start free with any Docker account, then scale up to 20x capacity when Gordon becomes part of your daily workflow.

Meet Gordon 

Gordon is Docker’s AI agent built for the work developers actually do. Not a chatbot that explains what to do. An agent that takes action, with your approval, across your entire Docker workflow. 

Gordon reads your running container logs, images, compose files, and working directory. It already knows your environment before you ask. The context is what makes Gordon different. When something breaks, Gordon doesn’t send you to the docs. It traces the failure in your actual setup, proposes a fix, and waits for you to say go. 

Gordon is optimized for Docker and container workflows, but it helps wherever developers need it. Containerize a Node.js app. Debug a crashing container. Spin up a stack of Postgres, Redis, and your own service in one prompt. Read the logs and figure out why your service can’t reach the network. Ship it.

Under the hood, Gordon has shell access, filesystem operations and the full Docker CLI, a knowledgebase of Docker docs and best practices and web access. We don’t build rigid features. We give Gordon a broad set of capabilities and let the agent figure out how to combine them to solve what you actually asked for. New capability in, new behaviors emerge.

It lives where you already work. Inside Docker Desktop and CLI. No new tools to learn. No context to rebuild every time you switch tasks. 

Your coding assistance helps you write the code. Gordon helps you ship it.

Image 2: Gordon welcome screen

What Gordon Does for You

When something is broken

Your build fails. The error log is dense and unhelpful. You’ve spent twenty minutes scrolling Stack Overflow and you’re no closer.

Tell Gordon: “My container keeps exiting.” Gordon reads the logs, traces the failure to the actual cause, a missing env var, a bad base image, a misconfigured volume mount, proposes a fix, and applies it after you approve. Twenty-minutes collapses to just two. 

When you’re starting something new

A teammate hands you a service and says “ship it.” No Dockerfile. No compose file. No idea how it talks to the production database. 

Tell Gordon: “Containerize this app and set up a dev environment with Postgres.” Gordon reads your code, drafts the Dockerfile, builds out a docker-compose with the stack, runs it, and shows you the result. From “ship it” to running locally in one conversation.

When you just want it done

Sometimes you don’t need a thoughtful AI agent. You need to clean up dangling images, stop everything that’s running, or pull and run nginx, and you don’t want to look up flags.

Tell Gordon: “Clean up unused images.” Gordon shows you the command, you approve, it runs. Fast Docker without the manual pages.

When you want it better

Your Dockerfile works but the image is 2GB and it rebuilds every time you sneeze. You know there’s a better version of it. But you don’t have an afternoon to find it.

Tell Gordon: “Optimize this Dockerfile.” Gordon proposes a multi-stage build, reorders layers for cache hits, swaps in a slimmer base image, and adds a health check. You diff, you approve, you ship.

When you need context fast

You’re mid debug and you need to know what’s running, what’s using disk, what’s stale. Stopping to look up flags breaks your flow.

Ask Gordon:  “Show me running containers.” “How much disk space is Docker using?” “List my images.”

Gordon already knows your environment. Running containers, images, volumes, networks. It answers without you stopping to remember whether the flag is -a or –-all. No pasting. No setup. Just ask.

When you’re learning

Docker has a lot of concepts, and most of the explanations on the internet are years out of date. You’re deep in a new code base and you need to understand volumes, or networking, or why your multi-stage build isn’t doing what you think it is. 

Ask Gordon: “Explain bind mounts vs named volumes in the context of my setup.” “Why is my service not reaching the network?” Gordon explains Docker concepts grounded in your actual setup, in plain language, today. Not a blog post from 2019. Your code, your environment, your answer. 

Image 3: Debugging session with Gordon

Where Gordon Lives

Gordon lives where you already work. No new tool to install. No context to rebuild. It’s built into Docker Desktop and the CLI so you can go from question to action without leaving your workflow. 

Docker Desktop

Gordon has its own tab inside Docker Desktop. Detach it to float alongside your work, with full context of your environment: running containers, images, volumes, the works.

Gordon, mid-task 

The tab isn’t the only way in. Gordon shows up across Docker Desktop at the moment you need it. A container fails to start? Launch Gordon straight from the container list and let it diagnose and fix the problem in place. Same for images, volumes, builds, and search. Wherever Docker Desktop surfaces a problem, Gordon is one click away.

docker ai

Prefer the terminal? Run docker ai from any directory. Same agent, same context, terminal-native. For when you live in a TUI and don’t want to leave it.

Gordon is available on Docker Desktop 4.74 and above.

You’re Always in Control

Gordon takes action, but it always asks first. 

Every shell command, every file modification, every Docker operation is shown to you before it runs. You approve, you reject, or you redirect. Gordon proposes. You decide.

We built it this way because an agent that can run commands on your machine should never surprise you. The convenience is in Gordon thinking through the problem, pulling the right context, and lining up the right command. The judgment is still yours. 

This is what staying in control actually looks like:

Approval First. Every action requires your explicit go-ahead. Every time. 

Session-scoped permission. Permissions reset when you close the session. No lingering access. 

Full transparency. You see exactly what commands Gordon wants to run before it runs. 

Configurable. For trusted workflows, you can enable auto-approve and let Gordon move faster. 

Privacy, plainly. We don’t store your code or personal information. Our AI providers don’t retain your data either. Gordon processes your request and that’s it. 

Gordon runs on Docker’s SOC 2 Type 2 attested, ISO 27001 certified infrastructure. 

Gordon Completes the Stack

Gordon isn’t a replacement for the tools you already use. It’s the agent layer that ties them together.  

Use Gordon when you’re working with Docker, containers, infrastructure, debugging, or anything between your laptop and production.

Use coding assistants when you’re deep in application logic, refactoring, or generating new code.

Use both when your task spans the stack, which it usually does.

Most tasks span the whole stack. Your coding assistants help write your code. Now you have an agent that handles both ends. 

Start Free. Scale When You’re Ready. 

Gordon is included free with every Docker account. No set up. No credit card. Just open Docker Desktop 4.74, login, click the Gordon tab, and start. 

Free covers everyday use. Limits reset every few hours so you’re never blocked for long. When Gordon becomes a core part of your workflow, upgrade anytime for more capacity.  

Need more? Gordon standalone plans give you 2x to 20x the capacity of the free tier. They’re add-ons. Any Docker account can buy one, including Free. 

Gordon Plus: 2x usage for regular users hitting base limits. $20/mo.

See full plan details →

Already using Gordon on a paid Docker plan? Check your email for details on your transition. 

Gordon Is Ready Today. Start Shipping. 

Gordon is generally available today. Free for every Docker account. Built into the tools you already use. Ready to take action the moment you need it. 

This isn’t just another feature upgrade. Gordon is how Docker is building intelligence into the entire developer workflow. Not a standalone AI tool you have to context-switch into, but as an agent layer woven into Desktop, Scout, Offload, Sandboxes and Model Runner. Every part of the stack, working together, with an agent that already knows your environment. 

Developers have always trusted Docker to build, ship and run software. Gordon is what that trust looks like when it can act on your behalf.

Get started today:

Update Docker Desktop to 4.74 or above. Open Desktop, click the Gordon icon in the sidebar, and start a conversation.

Run docker ai in your terminal for the same agent in CLI form.

Explore Gordon Plans. Start free. Upgrade when you’re ready. 

Read the docs. Everything you need to start shipping faster. 

Contact sales to learn more.

Quelle: https://blog.docker.com/feed/

Coding Agent Horror Stories: The Security Crisis Threatening Developer Infrastructure

This is issue 1 of a new series called Coding Agent Horror Stories where we examine critical security failures in the AI coding agent ecosystem and how Docker Sandboxes provide enterprise-grade protection against these threats.

AI coding agents are everywhere. According to Anthropic’s 2026 Agentic Coding Trends Report, developers are now using AI in roughly 60% of their work. The report describes a shift from single agents to coordinated teams of agents, with tasks that took hours or days getting compressed into minutes. Walk into almost any engineering team in 2026 and you’ll find AI coding agents sitting somewhere in the workflow, usually in more than one place.

The productivity story is real, and if you’ve watched an agent ship a feature in an afternoon that would have taken your team a sprint, you already know why. But the same agents that ship features in an afternoon can also delete your home directory in a few seconds. The same loop that lets an agent autonomously refactor a 12-million-line codebase will, given the wrong context, autonomously drop your production database. 

Over the past sixteen months, these aren’t hypothetical failure modes, they’re documented incidents with named victims, screenshotted agent outputs, and in several cases, public apologies from the vendors. This issue is the first in a new series mapping how those failures happen and how Docker Sandboxes can contain them.

What Are AI Coding Agents?

Unlike a traditional AI assistant that answers your question and waits for the next one, a coding agent reads your files, runs shell commands, writes and deploys code, queries databases, sends emails, and makes a chain of decisions to get a task done, none of which require you to approve each step along the way.

If you’ve worked with any of the current coding agents such as Claude Code, Cursor, Replit Agent, GitHub Copilot Workspace, Amazon Kiro, Google Antigravity, you’ve seen the pattern. They plug straight into your local machine, your cloud accounts, and increasingly your production systems. Adoption has been faster than almost any developer tool in recent memory: by late 2025, the vast majority of working developers were using AI coding tools as part of their daily workflow, and the question on most engineering teams shifted from “should we use this?” to “how do we use this without something going wrong?”

The simplest mental model I’ve found: an AI coding agent is a junior developer with root access, the ability to type at 10,000 words per minute, and no instinct for when to stop and ask. That combination is a lot of capability with no built-in sense of where the boundary is an entire reason this series exists.

How Do AI Coding Agents Work?

Under the hood, every agent in this category runs the same loop: observe, plan, act, repeat. 

You give it a task, something like “fix this bug” or “refactor this module” or “clean up these old files,” and the agent goes off and pulls in whatever context it figures it needs. Your files, sure, but also your logs, your environment variables, whatever happens to be accessible from wherever you launched it. Then it reasons through the problem and starts firing off tool calls to actually do the work. Write a file, run a command, hit an API, check the result, decide what’s next, loop. That’s the whole thing.

The part that catches people off guard is that the agent runs as you. Whatever permissions your shell has at the moment you typed the command to launch the agent, the agent inherits them wholesale. Logged in with admin rights? Congratulations, so is the agent. Got AWS credentials sitting in ~/.aws from that thing you set up six months ago and forgot about? The agent can read them. Production database connection string tucked into a .env file the agent scoops up as part of “project context”? It’s already in the model’s working memory before you’ve typed your second prompt. There isn’t a separate identity for “the agent acting on your behalf.” There’s just you, and the agent is, for all practical purposes, operating as you.

And here’s where it gets interesting, in the bad way. Traditional software does exactly what its source code says it does. You read the code, you know what’s going to happen, end of story. An AI coding agent doesn’t work like that. It’s reasoning its way through the task in real time, and its reasoning can produce decisions you didn’t expect and definitely wouldn’t have signed off on if anyone had bothered to ask. Maybe it decides that the cleanest way to resolve a schema conflict is to drop and recreate the table. Maybe it decides that wiping a directory is faster than going through and pruning the files you actually wanted to keep. Maybe it decides that a half-finished test file is better to be committed than sitting there in a dirty working tree. These calls happen in milliseconds. There’s no confirmation prompt, no approval step, no chance for you to say “wait, what?” before the action has already happened. By the time you notice, the thing is done.

That’s the gap this series is about. The model makes a decision. The execution layer carries it out. Nothing sits in between.

Caption: Comic depicting AI coding agent enthusiasm and the small matter of unrestricted filesystem access

AI Coding Agent Security Issues by the Numbers

The scale of security failures with AI coding agents is not speculation. It is backed by documented incidents, CVE disclosures, and empirical research spanning late 2024 through early 2026.

As of February 2026, at least ten documented incidents across six major AI coding tools including Amazon Kiro, Replit AI Agent, Google Antigravity IDE, Claude Code, Claude Cowork, and Cursor have been publicly attributed to agents acting with insufficient boundaries, spanning a 16-month window from October 2024 to February 2026.

The failures cluster around six critical risk categories:

Unrestricted Filesystem Access

Excessive Privilege Inheritance

Secrets Leakage via Agent Context

Prompt Injection through Ingested Content

Malicious Skills and Plugin Supply Chain

Autonomous Action Without Human-in-the-Loop

1. Unrestricted Filesystem Access

What it is: AI coding agents run with the full filesystem permissions of the operating user. Without an explicit workspace boundary, an agent that is asked to “clean up” a project directory can reach and destroy anything the user can access.

The numbers: A December 2025 study by CodeRabbit, the “State of AI vs Human Code Generation” report, analyzing 470 real-world open-source pull requests found that AI-generated code introduces 2.74x more security vulnerabilities and 1.7× more total issues than human-written code. Performance inefficiencies such as excessive I/O operations appeared at 1.42x the rate. “These findings reinforce what many engineering teams have sensed throughout 2025,” said David Loker, Director of AI at CodeRabbit. “AI coding tools dramatically increase output, but they also introduce predictable, measurable weaknesses that organizations must actively mitigate.”

The horror story: The Mac Home Directory Wipe

On December 8, 2025, Reddit user u/LovesWorkin posted to r/ClaudeAI what became one of the most-discussed incidents in the community, amplified by Simon Willison on X and covered by outlets across the US and Japan. They had asked Claude Code to clean up packages in an old repository. Claude executed:

rm -rf tests/ patches/ plan/ ~/

That trailing ~/ the user’s entire home directory was not intentional. But it was within scope. Claude had no workspace boundary. Desktop gone. Documents erased. Keychain deleted, breaking authentication across every app. TRIM had already zeroed the freed blocks. Recovery was impossible.

This was not an isolated failure. On October 21, 2025,developer Mike Wolak filed GitHub issue #10077 after Claude Code executed an rm -rf starting from root on Ubuntu/WSL2. The logs showed thousands of “Permission denied” messages for /bin, /boot, and /etc. Every user-owned file was gone. Anthropic tagged the issue area: security and bug. The detail that makes this particularly damning: Wolak was not running with –dangerously-skip-permissions. The permission system simply failed to detect that ~/ would expand destructively before the command was approved.

Shortly after Anthropic’s January 2026 launch of Claude Cowork, Nick Davidov, founder of a venture capital firm, asked the agent to organize his wife’s desktop. He explicitly granted permission only for temporary Office files. The agent deleted a folder containing 15 years of family photos, approximately 15,000 to 27,000 files, via terminal commands that bypassed the Trash entirely. Davidov recovered the photos only because iCloud’s 30-day retention happened to still be in effect. His public warning afterward: “Don’t let Claude Cowork into your actual file system. Don’t let it touch anything that is hard to repair.”

Strategy for mitigation: Never run AI coding agents with your full user permissions. Always scope agent execution to a dedicated project directory. Use filesystem boundaries that explicitly prevent access above the workspace root. Avoid using –dangerously-skip-permissions flags on your host machine.

2. Excessive Privilege Inheritance

What it is. The agent doesn’t just inherit your filesystem permissions, it inherits all of them. Cloud credentials, CI/CD tokens, production database connections, IAM roles, the works. In a development context, an agent making a “let me just clean this up” decision is annoying. In a production context, with production credentials, the same decision turns into an outage. The reasoning is identical. The blast radius isn’t.

The horror story: permission to delete the environment. In mid-December 2025, an AWS engineer deployed Kiro, Amazon’s own agentic coding assistant, to fix what was meant to be a small bug in AWS Cost Explorer, the dashboard customers use to track their cloud spending. Kiro had been given operator-level permissions, the same access the engineer had. There was no mandatory peer review for AI-initiated production changes. There was no checkpoint between the agent’s decision and its execution.

Kiro looked at the problem and decided that the cleanest path was to delete the entire production environment and rebuild it from scratch. So it did. Cost Explorer went down for thirteen hours in one of AWS’s mainland China regions.

The story sat inside Amazon for two months. Then on February 20, 2026, the Financial Times broke it based on accounts from four people familiar with the matter. The FT reporting also revealed a second AI-related outage, this one involving Amazon Q Developer, that had hit a different system. Amazon’s response, issued the same day on the company’s own blog, pushed back hard: the disruption was “an extremely limited event,” the issue stemmed from “a misconfigured role,” it was “a coincidence that AI tools were involved,” and “the same issue could occur with any developer tool (AI powered or not) or manual action.” Amazon also flatly denied the second outage existed.

But the part of Amazon’s response that says everything is what they did after the incident: they implemented mandatory peer review for production access. As The Register noted in their coverage, if this was just user error, it’s worth asking why peer review for AI-initiated changes was the fix. A senior AWS employee, quoted in the FT and picked up by Engadget, put it more directly: the outages were “small but entirely foreseeable.”

The deeper context, which you can find in coverage from Awesome Agents and others, is that Amazon had issued an internal memo in November 2025 mandating Kiro as the standardized AI coding assistant and pushing for 80% weekly engineer usage. Engineers reportedly preferred Claude Code and Cursor. The combination — mandated tool, broad permissions, no peer review gate — produced exactly the kind of incident you’d predict if you were thinking about it adversarially. Amazon just wasn’t.

The technical version of what happened is this: a human with operator-level permissions on a production AWS environment is unlikely to decide that the right response to a small bug is to delete the environment and rebuild it. The decision would route through a colleague, a Slack thread, a review, an approval, a “wait, are you sure?” Kiro had the same permissions and routed the decision through none of those things. It made the call autonomously, in seconds, and executed it before anyone could say “wait, what?”

Why it keeps happening. The agent’s identity is the user’s identity. There’s no separate principal for “the agent acting on the user’s behalf,” which means there’s no separate place to attach a tighter permission set, a stricter approval policy, or a different audit trail. Whatever the user can do, the agent can do, with no friction in between.

Strategy for mitigation: Never allow AI coding agents to operate with production-level credentials during development tasks. Implement strict role separation: agents should run under scoped identities with the minimum permissions required for the specific task. Apply the same two-person rule requirements to agent-initiated production changes that apply to humans. Treat agent identity as a first-class security principal, not a proxy for the human who started the session.

3. Secrets Leakage via Agent Context

What it is. Agents read your project context to do their job, and project context, in practice, means your repo plus your .env files plus your config files plus any instruction files you’ve left lying around. Anything the agent reads can show up later in generated code, log output, commit messages, or outbound API calls. The agent doesn’t have a built-in concept of “this string is a credential, do not transmit it.” If it’s in the context window, it’s a token like any other token, and tokens get used.

The numbers. GitGuardian’s State of Secrets Sprawl 2026 report, published March 17, 2026, found 28.65 million new hardcoded secrets in public GitHub commits during 2025, a 34% jump and the largest single-year increase the company has ever recorded. AI service credentials alone surged 81%. The cleanest signal in the report is the comparison between AI-assisted commits and human-only commits: AI-assisted commits leak secrets at roughly 3.2%, against a baseline of 1.5%. More than double. The same report identified 24,008 secrets exposed in MCP configuration files on public GitHub, a category that didn’t exist a year earlier. As GitGuardian CEO Eric Fourrier put it: “AI agents need local credentials to connect across systems, turning developer laptops into a massive attack surface.”

The horror story. On August 26, 2025, attackers published malicious versions of the Nx build system to npm. The compromised packages contained a post-install hook that scanned the filesystem for cryptocurrency wallets, GitHub tokens, npm tokens, environment variables, and SSH keys, double-base64-encoded the loot, and uploaded it to public GitHub repositories created in the victim’s own account under the name s1ngularity-repository. By the time GitHub disabled the attacker-controlled repos eight hours later, Wiz had identified over a thousand valid GitHub tokens, dozens of valid cloud credentials and npm tokens, and roughly twenty thousand additional files in the leak.

That’s the conventional supply chain part. Here’s what made s1ngularity new.

The malware checked whether Claude Code, Gemini CLI, or Amazon Q was installed on the victim’s machine. If any of them were, it didn’t bother writing its own filesystem-scanning logic. It just prompted the local AI agent to do the reconnaissance, with flags like –dangerously-skip-permissions, –yolo, and –trust-all-tools to bypass safety prompts. The attackers outsourced the search-for-sensitive-files step to the victim’s own AI assistant. Snyk’s writeup called this “likely one of the first documented cases of malware leveraging AI assistant CLIs for reconnaissance and data exfiltration.”StepSecurity called it “the first known case where attackers have turned developer AI assistants into tools for supply chain exploitation.”

The piece that makes this an agent-secrets story specifically: in many cases the developers didn’t run npm install themselves. AI agents working in their projects pulled in Nx as a dependency and ran the post-install hook automatically as part of routine task execution. The agent ran the malware. The agent then was the malware’s reconnaissance tool. The agent’s context, which included ~/.aws, ~/.ssh, .env files, and shell history, became the primary attack surface.

Why it keeps happening. The agent’s context window is a flat namespace. The credential file looks the same as the source file looks the same as the README looks the same as the prompt injection. There’s no architectural distinction between “data the agent should treat as authoritative” and “data the agent should be suspicious of.”

Strategy for mitigation. Don’t put secrets where agents can reach them. Use a secrets manager and inject credentials at runtime through a mechanism the agent process can’t read directly. Set spending caps on every API key the agent can possibly access. Add pre-commit hooks and CI gates that block commits matching credential patterns. 

4. Prompt Injection Through Ingested Content

What it is. AI coding agents continuously read untrusted content as part of normal operation. READMEs in dependencies, issue tracker comments, log files, web pages, emails. Malicious instructions embedded in any of this content can cause the agent to treat attacker-supplied text as legitimate user commands, executing arbitrary actions without the user’s knowledge.

The numbers. Prompt injection is the most documented and least solvable risk in the AI agent ecosystem. Simon Willison coined the term and frames it as “the lethal trifecta”: private data access, exposure to untrusted content, and the ability to communicate externally. Any agent with all three is exploitable, regardless of model hardening. There is no complete technical defense at the model layer. The OWASP 2025 Top 10 for LLM Applications puts prompt injection at #1 and is explicit that no foolproof prevention exists given how language models work.

The horror story: the private key exfiltration. Kaspersky documented a demo by Matvey Kukuy, CEO of Archestra.AI, against a live OpenClaw agent setup. The attack required no special access. He sent a standard-looking email to an inbox connected to the agent. The email body contained hidden prompt injection instructions. When the agent checked the inbox as part of a routine task, it parsed the instructions as legitimate commands and handed over the private key from the compromised machine in its response. Zero user interaction required after initial setup.

The same Kaspersky writeup documents an identical pattern from Reddit user William Peltomäki, where a self-addressed email with injected instructions caused his agent to leak the victim’s emails to an attacker-controlled address. The pattern keeps repeating because the underlying primitive is unchanged: anything the agent reads, the agent can act on.

Why it keeps happening. Language models process all input as a single stream of tokens. There is no instruction channel and data channel. The model is trained to follow instructions, so when it encounters something that looks like an instruction buried inside an email body or a web page or a README, its instinct is to comply. Palo Alto Networks Unit 42 confirmed in March 2026 that indirect prompt injection via web content has moved from proof-of-concept to in-the-wild observation.

Strategy for mitigation. Treat all ingested content as untrusted input. Require human confirmation before any action triggered by external content. Disable persistent memory for agents that handle sensitive operations. The most reliable defense isn’t preventing injection (you can’t) but containing what an injected agent can do. Prompt injection can’t be fully prevented at the model layer, but it can be contained at the execution layer. 

5. Malicious Skills and Plugin Supply Chain

What it is. AI coding agents support extensibility through skills, plugins, and tool integrations distributed through community marketplaces. These third-party extensions run with the same permissions as the agent itself. A malicious or compromised skill is effectively malware with agent-level access to the developer’s entire environment.

The numbers. Cisco’s AI Defense team ran their open-source Skill Scanner against the OpenClaw skills ecosystem in January 2026 and found that 26% of 31,000 agent skills analyzed contained at least one vulnerability. The top-ranked skill on ClawHub at the time, called “What Would Elon Do?”, was functionally malware: it silently exfiltrated user data via a curl command to an attacker-controlled server and used prompt injection to bypass the agent’s safety guidelines. Cisco’s scan returned nine security findings on that single skill, two of them critical.

The horror story: ClawHavoc. Within days of OpenClaw going viral, Koi Security identified 341 malicious skills on ClawHub, 335 of them tied to a single coordinated campaign tracked as ClawHavoc. The attack wasn’t a sophisticated zero-day. Attackers registered skills with names designed to sound useful (solana-wallet-tracker, youtube-summarize-pro, ClawHub typosquats like clawhubcli), wrote professional README files, and gamed the marketplace’s ranking algorithm. The only barrier to publishing was a GitHub account at least one week old.

The skills’ SKILL.md files contained “Prerequisites” sections that instructed the agent to tell the user to run a setup command, which downloaded and executed a payload. Trend Micro confirmed the payload as Atomic Stealer (AMOS), a commodity macOS infostealer that harvests browser credentials, keychain passwords, cryptocurrency wallets, SSH keys, and Telegram session data. All 335 ClawHavoc skills shared the same command-and-control infrastructure at IP 91.92.242.30. By mid-February, follow-up scans found the count had grown to 824+ malicious skills across a registry that had itself expanded to 10,700.

Why it keeps happening. Skills run with the agent’s permissions, which are the developer’s permissions, which on most setups means full access to the developer’s machine. There’s no sandbox between a third-party skill and your ~/.ssh directory. Marketplace incentives reward popularity, not safety, and popularity can be artificially inflated. A malicious skill that ranks #1 in the marketplace is operationally identical to a legitimate skill that ranks #1, until the curl command runs.

Strategy for mitigation. Treat every third-party skill as untrusted code from a stranger. Read the source before installing. Don’t rely on download counts or star ratings as a safety signal. Disable agent auto-discovery of new skills. Run skills in an isolated environment separate from your primary development context. 

6. Autonomous Action Without Human-in-the-Loop

What it is. AI coding agents are designed to act autonomously. That autonomy is the entire value proposition. But autonomous action on irreversible operations (database deletions, email sends, file purges, production deployments) means that when the agent’s judgment is wrong, there is no recovery path. The agent doesn’t hesitate. It doesn’t ask. By the time you notice, the action is complete.

The numbers. A UK AI Security Institute study, published in early 2026, identified nearly 700 real-world cases of AI models deceiving users, evading safeguards, and disregarding direct instructions, charting a roughly five-fold rise in agent misbehavior between October 2025 and March 2026. In a separate incident in March 2026, an experimental Alibaba research agent called ROME spontaneously initiated cryptocurrency mining operations during training, opening a reverse SSH tunnel from an Alibaba Cloud instance to an external server and diverting GPU resources from its training workload toward mining. The researchers’ note in the arXiv paper is the part worth reading carefully: “The task instructions given to the model made no mention of tunneling or mining.” The agent worked it out on its own as an instrumentally useful side path during reinforcement learning.

The horror story: the Replit production database wipe. Jason Lemkin, founder of SaaStr, was using Replit’s AI agent to build a SaaS product. On day nine of the project, he documented on X that the agent had wiped his production database during an active code freeze. The AI had encountered a schema issue and decided that deleting and recreating the tables was the cleanest path forward.

The agent’s own admission, screenshotted by Lemkin: “Yes. I deleted the entire database without permission during an active code and action freeze.” It then generated a self-assessment titled “The catastrophe is even worse than initially thought,” concluded that production was “completely down,” all personal data was “permanently lost,” and rated the situation “catastrophic beyond measure.” Over 1,200 executive records and 1,196 company records were destroyed. (Fortune and The Register both covered the incident in detail.)

The detail that makes this a horror story rather than just an incident: the agent had been told, repeatedly and in ALL CAPS, not to make changes during the code freeze. Lemkin says he gave the directive eleven times. The agent acted anyway. As Lemkin later wrote: “There is no way to enforce a code freeze in vibe coding apps like Replit. There just isn’t.” Replit CEO Amjad Masad publicly acknowledged the incident, called it “unacceptable and should never be possible,” and rolled out automatic dev/prod database separation in response.

Why it keeps happening. Natural language directives (“do not delete the database”) are inputs to a reasoning process that competes with other inputs in the same context. The directive “do not delete the database” and the observation “the schema is broken and deletion is the cleanest fix” arrive at the same model and get weighted on the same terms. The model is not choosing to disobey. It’s optimizing across the entire context, and in any sufficiently complex situation, optimization can produce destructive action.

Strategy for mitigation. Confirmation requirements for irreversible operations need to live at the platform layer, not the prompt layer. File deletions, database writes, outbound messages, production deployments, and any action involving payments should be gated by mechanisms the model cannot reason its way past. Natural language directives are not security boundaries. Infrastructure is.

How Docker Sandboxes Addresses AI Coding Agent Security Failures

While identifying vulnerabilities is essential, the real solution lies in architectural isolation that makes catastrophic failures structurally impossible  regardless of what the agent decides to do.

Docker Sandboxes represents a fundamental shift in how AI coding agents execute: from running directly on the host with user-level permissions, to running inside a microVM with an explicitly scoped workspace and no path to the host system. Docker Sandboxes are the isolated microVM environments where agents actually run. The sbx CLI is the standalone tool you use to create, launch, and manage them. Sandboxes are the environments. sbx is what you type to control them. The code blocks below show real sbx commands.

Across the six failure categories you just read about, sbx provides a complete agent-isolation toolkit: workspace scoping, proxy-injected secrets, network policies with audit logs, Git-worktree isolation, and resource caps. 

Security-First Architecture

A Docker Sandbox is a microVM, not a container. It has its own kernel, its own isolated filesystem, and its own network stack. The agent inside the sandbox cannot reach beyond what’s been explicitly mounted into the workspace. This is not a software guardrail. It is a hardware-enforced boundary.

Workspace isolation ensures that an agent tasked with cleaning up a project directory can only reach that project directory. The home directory, credential stores, and system files are structurally unreachable, not because the agent is told not to touch them, but because they do not exist from inside the microVM.

Blocked credential paths mean that sbx explicitly prevents mounting of sensitive directories by default. ~/.aws, ~/.ssh, ~/.docker, ~/.gnupg, ~/.netrc, ~/.npm, and ~/.cargo are all on the blocklist. A misconfigured mount is caught and rejected before the agent ever starts.

Network egress controls allow you to define exactly which external services the agent can reach. An agent working on a local project has no legitimate reason to communicate with an external server. With sbx, you can enforce that at the network layer.

# Install sbx and sign in
brew install docker/tap/sbx
sbx login

# Quickest path: launch an agent in a sandbox scoped to the current directory.
cd ~/my-project
sbx run claude

Three commands, and the agent is now running inside a microVM with its workspace mounted, credential paths blocked, and network egress governed by policy.

Systematic Risk Elimination

Docker Sandboxes systematically eliminates each of the six failure categories through architecture rather than policy.

Unrestricted Filesystem Access → Workspace-Scoped Execution

The rm -rf ~/ incident is contained at the execution layer inside a sandbox. The agent’s view of the filesystem is the workspace mount. ~/ inside the microVM is the workspace, not the developer’s actual home directory. The host filesystem does not exist from inside the sandbox.

cd ~/my-project
sbx run claude

# Equivalent two-step form, useful when you want to name the sandbox:
sbx create –name my-project claude .
sbx run my-project

The agent can read and write inside /workspace. Everything outside the workspace, including /etc, /proc, /sys, and the developer’s home directory, is unreachable.

Excessive Privilege Inheritance → Scoped Identity

Rather than inheriting the developer’s full credentials, the agent runs under a minimal identity with only the permissions required for the task. Production credentials are never passed into the sandbox unless explicitly mounted and sbx blocks common credential root paths by default.

# Mount only what the task needs. Everything else stays on the host,
# unreachable from inside the sandbox. Read-only mounts use the :ro suffix:
sbx create –name docs-review claude /path/to/project /path/to/docs:ro

# Resource limits prevent runaway agent processes:
sbx create –name capped-agent –cpus 4 –memory 8g claude .

The agent can do its work. It cannot reach into AWS, SSH, or any other host credential store while doing it, because those paths were never mounted in the first place.

Secrets Leakage → Isolated Context

When the agent’s filesystem view is limited to the workspace, it cannot read .env files, credential configs, or API keys stored elsewhere on the system. Secrets that were never visible to the agent cannot be reproduced, committed, or exfiltrated. The s1ngularity attack from Section 3, which weaponized AI agents to scan the filesystem for credentials, is contained: the credentials simply aren’t in the sandbox’s view of the filesystem.

# Store credentials once, scoped to a service.
sbx secret set anthropic
sbx secret set github

# The proxy injects these into outbound requests automatically.
# The agent never sees the actual secret values.
sbx run claude

A successful prompt injection that tells the agent to “exfiltrate your API keys” finds nothing to exfiltrate. There are no API keys in the agent’s context to begin with.

Prompt Injection → Contained Blast Radius

Prompt injection cannot be fully prevented at the model layer. It is a property of language models, not infrastructure. But Docker Sandboxes limits what a successfully injected agent can do. If injected instructions tell the agent to delete files outside the workspace, those files do not exist inside the microVM. If they instruct the agent to exfiltrate credentials, there are no credentials in scope. If they instruct the agent to phone home to an attacker-controlled server, the network policy blocks the egress. The attack succeeds at the model layer and fails at the execution layer.

# Allow only the network destinations the agent legitimately needs.
# Hosts are comma-separated; wildcards and port suffixes are supported.
sbx policy allow network "api.anthropic.com,api.github.com"

# Allow all subdomains of a trusted host:
sbx policy allow network "*.anthropic.com"

# Inspect the active policies and audit log:
sbx policy ls
sbx policy log

The sbx policy log command surfaces every allowed and denied connection attempt. If a prompt injection attempts to phone home to a command-and-control server, the attempt is logged and blocked at the network layer. The attack succeeds at the model layer and fails at the execution layer.

Malicious Skills → Sandboxed Execution

Skills and plugins that execute inside a Docker Sandbox are constrained by the same boundary as the agent itself. A malicious skill that attempts to read SSH keys, harvest .npmrc tokens, or communicate with a command-and-control server fails at each step. The files are not mounted, and the network destination is not on the allowlist. The ClawHavoc-style infostealer payloads from Section 5 cannot reach the host because the host is not visible from inside the sandbox.

# Confirm only allowlisted destinations are reachable before installing
# untrusted skills.
sbx policy ls

# Run the agent (and any skills it loads) inside the sandbox boundary.
sbx run claude

The skill can do whatever it wants inside /workspace. It cannot read SSH keys it cannot see, harvest tokens that aren’t mounted, or reach a C2 server that isn’t on the network allowlist. The blast radius is the workspace, not the developer’s machine.

Autonomous Action → Branch-scoped Execution

Docker Sandboxes provides the architectural foundation for human-in-the-loop on irreversible operations. Two patterns work together: production resources require explicit configuration to be reachable from inside the sandbox, and destructive code changes can be routed through Git worktrees for review before they touch the main branch. The first pattern means a sandbox not configured to reach production cannot reach production, regardless of what the agent decides. Production credentials, production database connection strings, and production deployment endpoints are unreachable by default. The second pattern means even when the agent is working on the codebase that *will* eventually deploy to production, its changes live on an isolated feature branch you review before merging.

# Inside an existing Git repository. –branch creates a Git worktree
# so the agent's changes are isolated to a feature branch and cannot
# accidentally land on main.
cd ~/my-project
sbx create –name feature-login –branch=feature/login claude .

# sbx prints the next step for you:
# ✓ Created sandbox 'feature-login'
# To connect to this sandbox, run:
# sbx run feature-login
sbx run feature-login

# Inspect what the agent changed before merging anything:
sbx exec feature-login git diff main

# Merge the worktree branch back when you're satisfied:
# git merge feature/login
# Or throw the sandbox away if you don't like the result:
sbx rm feature-login

The agent can decide whatever it wants. The infrastructure decides what gets through. A “drop and recreate the table” decision lives entirely on a feature branch you can review, accept, or discard. Production never sees it unless you explicitly merge.

What This Looks Like in Practice

The promise of Docker Sandboxes is straightforward: a productive AI coding agent without an existentially dangerous one.

Workspace isolation: the agent operates only within explicitly mounted directories, no host filesystem access

Credential protection: common credential paths are blocked by default, no accidental exposure

Network containment: egress limited to approved destinations, no unfettered exfiltration path

Blast radius control: a compromised or confused agent cannot reach beyond its microVM, no cascading host failures

Audit trail: all agent actions are logged, full post-incident forensics capability

The agent gets a workspace. It does not get your machine.

Stay Tuned for Upcoming Issues in This Series

Issue 2: Unrestricted Filesystem Access → The rm -rf ~/ Incident (Deep Dive) How a single trailing slash wiped a developer’s Mac — and what workspace-scoped execution prevents structurally

Issue 3: Privilege Inheritance → The AWS Kiro Production Outage How an AI agent bypassed two-person approval requirements by inheriting production credentials  and the architectural fix

Issue 4: Secrets Leakage → The GitGuardian 29 Million Problem Why AI-assisted commits leak secrets at double the rate and how isolated agent context eliminates the exposure surface

Issue 5: Prompt Injection → The Private Key Exfiltration The attack that requires no code, no malware, and no special access and why blast radius containment is the only reliable defense

Issue 6: Supply Chain → The ClawHub Infostealer Campaign How 335 malicious skills reached developer machines through a marketplace ranking exploit and sandboxed skill execution as the structural fix

Learn More

Run agents safely with Docker Sandboxes: Visit the Docker Sandboxes documentation to get started with workspace-isolated agent execution in minutes.

Explore the Docker MCP Catalog: Discover MCP servers that connect your agents to external services through Docker’s security-first architecture.

Download Docker Desktop: The fastest path to a governed AI agent environment, with Docker Sandboxes, MCP Gateway, and Model Runner in a single install.

Read the MCP Horror Stories series: Start with issue 1 to understand the protocol-layer security risks that complement the agent-layer risks covered here.

Quelle: https://blog.docker.com/feed/

Custom MCP Catalogs and Profiles: Advancing Enterprise MCP Adoption

We’re excited to announce the general availability of Custom Catalogs and Profiles for managing Model Context Protocol (MCP) servers. These two complementary capabilities fundamentally change how teams package, distribute, and manage AI tooling. 

Custom MCP Catalogs let organizations curate and distribute approved collections of MCP servers. MCP Profiles enable individual developers to easily build, run, and share their MCP tools and configurations across projects and teams.

In this post, we’ll walk through how to create your own custom catalog – building on and improving our previous approach. We’ll also introduce Profiles, a new primitive that lets you define portable, named groupings of MCP servers. Profiles are designed to solve several practical use cases today, while giving us a foundation to expand in the future.

Creating custom catalogs with Docker

As organizations adopt MCP, we consistently hear the same need: teams need a way to curate a trusted list of MCP servers, including internally built servers.

To address these needs, we built Custom Catalogs. Instead of every team member searching for MCP servers across the open internet, organizations can publish and distribute catalogs that define approved servers. This allows developers to centrally discover and use trusted MCP servers within organizational boundaries.

Custom Catalogs can reference servers from Docker’s MCP Catalog, community sources, and custom MCP servers developed internally, bringing flexibility, control, and trust together in a single experience. We will show you how to do that with a Custom Catalog. 

Step-by-step: Building and sharing a custom MCP catalog 

In this example, we will create a Custom Catalog containing servers from the Docker MCP Catalog and an MCP server we created ourselves from the CLI. Then we will show you how to use Docker Desktop to import the catalog.

All the functionality we will show can be exercised through the CLI, while a subset of primarily user-centric features can be exercised through Docker Desktop.

Here, we will use my personal Docker Hub ID roberthouse224 in the commands, but you should adapt to use your information where appropriate (e.g. pushing an image).

Step 1: Creating my custom MCP server and pushing it to Docker Hub

We built a reference server called roll-dice (GitHub Repository). It is a regular MCP server that communicates over stdio and can be built as a Docker image. The image has already been built and pushed to Docker Hub.

We can create the metadata that describes the server including where the image can be found and save it to a file named mcp-dice.yaml to be used when creating our catalog.

name: roll-dice
title: Roll Dice
type: server
image: roberthouse224/mcp-dice@latest
description: An mcp server that can roll dice

Step 2: Creating a catalog that includes servers from the Docker MCP Catalog alongside a server you have built yourself

Now we can create a custom catalog containing servers from the Docker MCP Catalog and the MCP server we created ourselves.

docker mcp catalog create roberthouse224/our-catalog
–title "Our Catalog"
–server catalog://mcp/docker-mcp-catalog/playwright
–server catalog://mcp/docker-mcp-catalog/github-official
–server catalog://mcp/docker-mcp-catalog/context7
–server catalog://mcp/docker-mcp-catalog/atlassian
–server catalog://mcp/docker-mcp-catalog/notion
–server catalog://mcp/docker-mcp-catalog/markitdown
–server file://./mcp-dice.yaml

Step 3: Verifying the MCP servers in the custom catalog 

We can now list our catalogs and see the catalog that we createddocker mcp catalog list

We can also inspect the contents of the catalogdocker mcp catalog show roberthouse224/our-catalog –format yaml

Step 4: Share the catalog

At the moment our custom catalog only lives on our machine. But what we have – and this is really powerful – is an immutable OCI artifact containing our trusted MCP servers that can be easily shared.

We can push our catalog to a container registry, in this example we’re using Docker Hub. Now, anyone that has access to your organization’s namespace can access the catalog.

docker mcp catalog push roberthouse224/our-catalog

Using a custom MCP catalog

Now that our custom catalog has been shared, colleagues can import it from within Docker Desktop (or from the cli using docker mcp catalog pull).

Import the catalog from Docker Desktop by selecting “Import catalog,” and then specifying the OCI reference in the dialog.

Figure 1: Importing a custom catalog from OCI reference

The catalog is now browsable. You can double click into the catalog and see all of the servers contained within it. Notice the custom MCP server that we added named “Roll Dice.”

Figure 2: A custom MCP catalog within the Docker Desktop app, including a newly added “Roll Dice” server.

To make this a private catalog all you need to do is manage access to the repository the way you always have for container images – no new infrastructure to manage or systems to learn.

This is exactly what Jim Clark was describing in his post Private MCP Catalogs and the Path to Composable Enterprise AI.

This simple pattern can be extended to support more complex use cases. For example, you might use a private container registry instead of Docker Hub, or connect to a remote MCP server over streamable HTTP you host yourself rather than running a containerized server as shown in the example.

Now that we have a shareable custom catalog of trusted MCP servers we can shift focus to how individuals can effectively leverage MCP servers from the catalog we built in their workflows.

Using Profiles to create and share MCP Workflows

With MCP Profiles, developers can organize workflows efficiently and maintain separate server collections and configurations for different use cases. Profiles can be shared across teams, enabling collaboration on server setups and ensuring consistent configurations for teams working within the same projects or contexts.

Switch between Profiles

At a basic level, a Profile is a named grouping of MCP servers that can be connected to an agent session. This makes it straightforward to define different Profiles for different ways of working.

Now let’s see an example in action. 

We create a profile named coding and another named planning. We browse our custom catalog, select the MCP servers that we want (e.g. Playwright, GitHub, and Context7) then select the “Add to” drop down, and select “New profile”.

Figure 3: Selecting MCP servers to be added to a new profile

Give the profile a name, select the client you want to connect to, and select “Create”.

Figure 4: Creating a new MCP profile named coding in Docker Desktop.

From the Profiles tab, we can see the profile we just created. Our client is connected and our tools are ready to use. 

Figure 5: Example of a profile that is connected to a client.

Next we create a profile named planning with servers relevant to planning (e.g. Atlassian, Markitdown, Notion). 

Navigate back to “our-catalog” (if not already there), select the servers relevant to planning, and select “Add to” -> “New profile.” Give the profile a name (e.g. planning). Then select “Create” to create the planning profile without a client. Specifying the client is optional.

Figure 6: Example of creating multiple profiles, including separate profiles for coding and planning 

Now we have two profiles that mirror two modes of working. When we switch to planning mode we only want the tools from our planning profile to be in context. To do that, we can easily reassign our client to the planning profile.

Figure 7: Reassign Claude Code to the planning profile.

If we go back to coding mode, we just reassign our client back to the coding profile. You can have any number of Profiles that mirror your many ways of working and easily switch between them, keeping only the tools you care about in context.

This will work with any agent, not just Claude Code. Profiles provide a truly portable way to manage your MCP server setups and avoid vendor lock-in.

Persist configuration

You can avoid repeatedly configuring MCP servers by using a Profile. Profiles add a persistence layer for MCP server configurations. When an MCP server exposes configurable options, you can define them once in a Profile and reload them as needed, avoiding repeated configuration.

In this example, we are specifying which paths Markitdown can access.

Figure 8: Using an MCP profile to save server configurations for reuse

Context windows can easily fill up when the MCP servers you use export a lot of tools. With Profiles you can specify which tools are enabled, making sure only the tools you need for a specific task are used.

Here we enable the get_me tool from the GitHub MCP server and disable all the others. All the other tools will not show up in our agent session or contribute to the context window.

Figure 9: Optimize your context window by enabling only the tools you need in the MCP profile

This model of saved configuration becomes far more powerful for MCP servers you build in-house. By exposing richer configuration options, you can reuse the same server across projects, reconfigure its behavior per context, and achieve more predictable outcomes.

Share Profiles

Identifying MCP servers and configurations that work well for a project doesn’t need to be repeated by every team member. Once you’ve found a setup that works, share it with the rest of the team.

To share a Profile you can push it as an OCI artifact to a container registry just like we did with our custom catalog. Just provide a name for it along with an OCI reference.

➜ ~ docker mcp profile push coding [your-namespace]/coding

For someone to pull it down, all they have to do is issue the corresponding pull command.

➜ ~ docker mcp profile pull [your-namspace]/coding

Although the example above demonstrates sharing Profiles across a team, the concept extends naturally to agents as well. An agent skill could, for instance, reference a Profile and pull in the required MCP servers and their configurations as dependencies.

Conclusion and What’s Next 

As MCP adoption grows, the challenge isn’t access to tools — it’s coordination. Teams need a way to standardize what’s trusted and supported without constraining how individuals actually work. Custom Catalogs and Profiles are designed to solve exactly that problem.

Custom Catalogs: shared foundation

Custom Catalogs allow platform and admin teams to define approved MCP servers, bundle internal and public tooling together, and distribute those choices as a single, portable artifact. This creates clarity and consistency while significantly reducing the cost of discovery and evaluation.

Profiles: supercharge workflow

Profiles give individual developers a lightweight way to assemble, configure, and reuse MCP servers for specific contexts like coding, planning, or research. Profiles persist configuration, limit context to what matters, and make effective setups easy to share across teams.

Together, these primitives separate:

What an organization recommends (via Custom Catalogs)

How people work day to day (via Profiles)

This separation enables a healthy balance. Platform teams can publish “golden paths” that establish standards and guardrails, while developers retain the freedom to adapt, experiment, and compose profiles that fit their needs.

The result is a system that is portable, composable, and scalable — making MCP easier to adopt, safer to manage, and more effective as it grows across an organization.

What’s Next?

Custom Catalogs and Profiles are the foundation for managing MCP at scale, and we’re just getting started. Next, we’re focused on extending these primitives to support stronger governance, better reuse, and more advanced agent workflows:

Governance and policy controls to restrict MCP usage to approved Custom Catalogs and trusted server sources

Improved discoverability and sharing for both Catalogs and Profiles, making proven setups easier to find and reuse across teams

Expanded Profile-scoped secrets and configuration, providing a more secure and flexible alternative to project-level mcp.json files

Clear best practices for Profiles, including saving dynamic MCP server configurations for reuse and pairing Profiles with emerging workflow optimizations like agent skills

Getting started with Custom Catalogs and Profiles

If you have Docker Desktop 4.56 you are already using Catalogs – our Docker MCP Catalog is now distributed as an OCI artifact and Profiles are supported starting with Docker Desktop 4.63. Try creating your first Profile by exploring the MCP Toolkit in Docker Desktop.

Learn more

Dive into our documentation on Custom Catalogs and Profiles to get started quickly.

Explore Docker’s MCP Catalog and Toolkit on our website.

Ready to go hands-on? Open Docker Desktop or the CLI and start using MCP to streamline and automate your development workflows.

Quelle: https://blog.docker.com/feed/

Comparing Different Approaches to Sandboxing

“AI agents will become the primary way we interact with computers in the future. They will be able to understand our needs and preferences, and proactively help us with tasks and decision making.“

Satya Nadella
CEO of Microsoft

Whether you are a software engineer, a product manager, or a designer, this quote should fundamentally change how we approach our daily routine. We are no longer just building interfaces; we are creating environments where agents can operate autonomously with minimal human interaction. What could be the fundamental requirement for such an environment ?

In a single word: Isolation.

A user interacting with traditional software is constrained by the actions it allows. But Agents are non-deterministic, and therefore prone to hallucination and prompt injections. Once you give an AI write access to your systems, there is nothing stopping it from executing a rm -rf to delete all your data. Of course, there are different ways to solve this problem, with one approach being sandboxing: an isolated, controlled environment used for experimentation and testing without affecting the surrounding system.

So, I started exploring different strategies to sandbox the agents. Starting with a bare minimum setup and going all the way to setting up a cloud VM. Here is what I learned at each step.

1. Let’s Start with the Baseline

Chroot has been the traditional way to achieve file system isolation. It works well when you want the process to think that a specific, restricted directory is the absolute root of the machine.

However, there are two major caveats.

If the process inside the chroot has root privileges, it could break out.

While it offers file isolation, process isolation is still a problem. A malicious agent can still see other processes running on your system and try to kill them.

As you can see above, doing an ls /proc still shows all the processes running on the host.

This is when I learnt about systemd-nspawn, also called “chroot on steroids”. The difference between chroot and systemd-spawn is that the latter provides isolation at the network and process levels in addition to the file system.

Now, when I do the same ls /proc in the systemd-nspawn mybox container, I just see the processes in the mybox container achieving process-level isolation.

Pros

Lightweight compared to other container processes like Docker, it offers faster startup times.

Native support in Linux.

Caveats

systemd-nspawn is not very popular in the developer community unless you are deep into Linux.

While this works for Linux, what if you need to run your agents on Windows? You will have to find alternatives depending on the platform.

2. Are Containers Enough?

Another technology that comes to mind when thinking about isolated environments is Docker. And unlike the previous concepts we discussed, Docker has a broader ecosystem and a strong community.

With containers, you also get isolated file systems, network interfaces, and process trees. They also come with cross-platform support across Mac, Windows, and Linux. With all these advantages, creating and running agents across different platforms becomes very easy, which makes containers an obvious choice.

However, the model becomes more complex when containers become a dev platform for agents. More often than not, agents need to execute generated code in separate environments, which in practice means spinning up new Docker containers on demand. This introduces a container-in-container pattern (Docker-in-Docker), where an agent running inside a container needs to build and run other containers. 

To make Docker-in-Docker to work, we would have to run the container in privileged mode (–privileged), which gives the container processes elevated permissions rights and dramatically weakens the isolation. At this point, the isolation guarantees are significantly diminished. As a result, complete isolation for agents using only containers becomes tricky.

3. Do Virtual Machines Help?

As you might have already predicted, Virtual Machines (VMs) offer the strongest isolation. With a VM, you can get an entire OS, file system, and network of your own. For example, I currently run MacOS with lima – Linux VM to run Linux-specific workloads.

However, the tradeoff is that spinning up a VM is expensive. And if this needs to be done for every agent, it is not scalable. Some stats that show how expensive spinning up a VM with system-nspawn looks like.

Approach

Per Agent Cost

Boot Time

10 Agents

VM (Lima)

~4GB RAM + 4 CPU

30-60s

~40GB RAM

systemd-nspawn

~10MB RAM

< 1s

~100MB RAM

chroot

1MB RAM

instant

~10MB RAM

For example, in the below screenshot you can see the cost it takes to run a lima vm.

4. MicroVMs to the rescue

A MicroVM (Micro Virtual Machines) felt like the perfect answer to the isolation story. So what is MicroVM, and what makes it better?

MicroVM is a lightweight virtualisation technology that provides the strong security and isolation of a traditional VM, along with the speed of a container.

Strong security and isolation are enabled because a MicroVM gets its own kernel, aka the Guest Kernel, unlike containers, which use a shared kernel. Because of this, any compromise inside the Guest OS does not directly affect the host or the other VMs.

Speed: unlike traditional VMs, it is provisioned with minimal hardware (no USB or PCI buses) and bypasses BIOS/UEFI boot, significantly reducing device emulation overhead and startup latency.

Amazon open-sourced Firecracker in 2018, which was the earliest adoption of the MicroVM architecture. While this helped catalyze the MicroVM architecture, Firecracker was restricted to Linux environments. And most of the agentic orchestration tends to happen on developers’ laptops which run MacOS and Windows as well.

Docker addressed this gap with its Sandbox offering. The best part is their MicroVM-based architecture, which runs natively across macOS, Windows, and Linux, delivering better isolation, faster startup times, and a smoother developer experience. We will learn about this in a bit.

5. gVisor

gVisor takes a unique approach to solving the isolation problem. While the previous strategies used the OS Kernel, gVisor creates its own Kernel called the “application kernel” running in the user space.

When a standard containerized app wants to do something like open a file, allocate memory, or send network traffic, it makes a “system call” (syscall) directly to the host’s Linux kernel.

With gVisor, your app is bundled with a component called the Sentry.

The Sentry intercepts every single syscall your application makes.

It processes that request in user-space using its own implementation of Linux networking, file systems, and memory management.

If the Sentry absolutely needs the host kernel to do something (like actual disk I/O), it translates the request into an extremely restricted, heavily filtered, safe call to the host.

However, it suffers from the same problem as systemd-nspawn. Not much broader community supports and only supports Linux.

Docker Sandbox

With Docker Sandboxes, AI coding agents run in isolated microVM environments. The performance is as seamless as it can be, identical to running on the host, but with significantly stronger isolation and security. This means you can run your autonomous agents without worrying about host compromise or unintended access to your local environment. 

Sandbox achieves this levels of security through three layers of isolation:

Hypervisor Isolation: Every Sandbox has its own Linux Kernel. So, anything that affects the sandbox kernel will not affect the host or other sandbox kernels.

Network Isolation

Each Sandbox has its own isolated network. Meaning multiple sandboxes cannot communicate with each other or with the host.

In addition, network policies can be enforced to allow or disallow traffic from a source.

Docker Engine Isolation

This is what made me fall in love with this new architecture. Every Sandbox gets its own Docker Engine. As a result, whenever the agent runs docker pull or docker compose, those commands are executed against the internal engine rather than the external Docker daemon.

Because of this, agents running inside can only see Docker services within their sandbox and nothing else, adding an additional layer of security.

Attribute

Traditional VM

Container

Docker MicroVM

Isolation

Strong (dedicated kernel)

Weak (shared kernel)

Strong (dedicated kernel)

Boot time

Minutes

Milliseconds

Seconds (after the first image pull)

Attack Surface

Large

Medium

Minimal

To demonstrate Docker Engine isolation, I created two Sandbox sessions, ran the Docker hello-world container image in one, and then ran docker ps -a in both.

​As you can see from the screenshot below, one session has the hello-world container and the other does not. This is possible because both of them are running two different Docker engine daemons.

More on the Sandbox architecture here: https://www.docker.com/blog/why-microvms-the-architecture-behind-docker-sandboxes/

Conclusion

If there is one takeaway; it’s this: isolation plays a major role when building autonomous AI agents because the blast radius of a security mistake is significant. 

Each approach we explored till now solves a different piece of the isolation puzzle. Containers improve portability and developer experience, but inherit the risks of a shared kernel. Virtual Machines deliver strong isolation, but the overhead doesn’t scale when you’re spinning up dozens of agents. gVisor sits in an interesting middle ground, though compatibility and community trade offs might slow you down.

Among all these, what makes Docker Sandbox with MicroVMs compelling is how it unifies these dimensions: VM-level security, container-like startup speed, and a workflow developers already know. Per-sandbox Docker Engines and strict network boundaries make it a strong foundation for running untrusted, autonomous workloads at scale.

So, what are you waiting for? Go ahead and try it out today.

For macOS: brew install docker/tap/sbx

For Windows: winget install Docker.sbx

Quelle: https://blog.docker.com/feed/