TechPrufer
Get started
Docker
Docker logoDocker · Feature trail

AI Agent Isolation and Secure Execution

26 posts · Jul 2026 – Oct 2026

What this trail covers

This feature thread tracks Docker's advancements in providing secure and isolated execution environments for AI agents. Initially, the focus was on the growing need for isolation as AI agents shifted from passive assistance to active code execution. Subsequent posts detail Docker's solutions, including Docker SBX (Sandboxes) which leverages microVMs for enhanced security, and Sandbox Kits for creating reusable, standardized, and secure AI development environments. This post elaborates on the expansion of Cloud Sandboxes, which provide a microVM boundary for agents to run longer tasks in the cloud, and introduces the open Sandbox Kit specification for defining agent environments and their access needs, with a commitment to bring it to the CNCF. It also details how runtime governance, rather than agent-specific governance, is key to managing AI agent activity across an organization, with a focus on security controls and auditability.

All Docker trails
  1. Docker Cloud Sandboxes: Recap from WeAreDevelopers | DockerThis post announces the launch of Docker Cloud Sandboxes, extending the concept of local sandboxes to the cloud for longer-running agent tasks. It introduces the open Sandbox Kit specification for defining agent environments and their access requirements, with a commitment to bring it to the CNCF. The post also emphasizes the importance of runtime governance for AI agents, detailing how Docker's approach focuses on containment, control, choice, and capacity, and how this enables security teams to govern agent activity through capabilities as code and manifest inspection. It highlights the use of microVMs for isolation and the integration of audit records for investigation.
  2. Manufacturing Trust for AI Agents | Docker at WeAreDevelopersThis post introduces Docker Cloud Sandboxes, extending the microVM-based isolation of Docker Sandboxes to cloud compute, enabling developers to start work locally and seamlessly move it to the cloud. It also announces the submission of the Docker Sandbox Kit specification to the CNCF, aiming to establish an open, vendor-neutral standard for packaging AI agents, their tools, and guardrails as OCI images, fostering an open agent ecosystem.
  3. Docker Brings Sandbox Kit Spec to the CNCF | DockerThis post introduces the Docker Sandbox Kit Spec, which defines a standard for packaging AI agents, their tools, and their requested permissions (hosts, credentials, volumes) as an OCI image. This spec is being donated to the CNCF to foster an open ecosystem for agent security and portability. The key technical contribution is the definition of an OCI image extension point that allows for the inclusion of a typed list of agent requests, enabling runtime enforcement and improved transparency. This builds upon the existing Docker Sandbox Kit concept by making it an open standard.
  4. Docker Sandbox Kit Spec: Authority as Code | DockerThis post introduces the Docker Sandbox Kit Specification v3, standardizing the definition of an agent's required authority (network policies, credentials, volumes, lifecycle hooks) within an OCI image. It details the composition rules for Kits (workloads and mixins) and the normative grammar for capability types, ensuring interoperability and enabling reviewable authority grants. The specification aims to make authority reproducible and auditable, moving beyond ad-hoc configurations in Dockerfiles and run commands.
  5. Introducing Cloud Sandboxes: Start on Your Laptop, Finish in the Cloud | DockerThis post introduces Cloud Sandboxes, extending the Docker Sandboxes microVM isolation model to Docker-managed compute. It details the ability to start agents locally and move them to the cloud, run numerous tasks in parallel without provisioning, and the integration of 'Kits' for pre-configured agent environments. It also highlights features like MCP for connecting to external services, secrets management, and network policies, all accessible via a unified CLI and web console. The pricing model is pay-as-you-go based on compute usage.
  7. 6 Benefits of Sandbox Environments | DockerThis post details six benefits of sandbox environments for running AI agents: 1. Isolation via microVMs with a dedicated Linux kernel, providing stronger separation than containers. 2. Network and filesystem controls enforced at runtime per sandbox. 3. Secure credential handling by injecting credentials into outbound requests at the boundary, rather than passing them into the environment. 4. Ephemeral and disposable environments defined in code for fast recreation and parallelism. 5. A real Linux dev environment including a full, isolated Docker daemon. 6. Consistent sandbox technology across all agents for unified policy enforcement. It positions Docker Sandboxes as delivering all these benefits together for secure AI agent execution.
  8. What is YOLO Mode? | DockerThis post introduces and explains 'YOLO mode' for AI agents, defining it as autonomous action without confirmation prompts. It highlights the risks of running YOLO mode directly on a host machine (file deletion, credential exposure, prompt injection, data exfiltration) and contrasts this with the safety provided by isolated, ephemeral environments like microVMs. The post details how Docker Sandboxes and Docker AI Governance enable safe YOLO mode usage at scale by providing controlled boundaries for network access, filesystem interaction, and tool usage, allowing developers to focus on reviewing outcomes rather than constant supervision.
  9. Below the Harness: Governing a Multi-Model, Multi-Harness World | DockerThis post introduces the concept of a 'runtime layer below the harness' as a fundamental solution to AI agent security and governance challenges. It elaborates on the 'confused deputy' problem in the context of AI agents inheriting user authority and acting probabilistically. The post details three failure modes of per-harness guardrails: agents talking past them, rails moving without user control, and rails not covering the entire fleet. It proposes a unified runtime boundary as the solution, enabling consistent policy enforcement across all agents and harnesses, independent of model or vendor updates, and providing a single audit record. This directly extends the AI Agent Isolation and Secure Execution thread by proposing a new architectural layer for governance.
  10. Building Reproducible AI Evaluation Workflows with Docker Sandboxes | DockerThis post introduces the SBX AI Evaluation Kit, an open-source Docker Sandboxes Mixin Kit designed to make AI evaluation workflows reproducible. It details how Docker Sandboxes and an SBX Kit can be used to ensure consistent command execution, capture structured JSON records of runtime evidence (including stdout, stderr, exit code, and duration), and manage evaluation suites. The core contribution is the executor abstraction, which separates evaluation definition from execution environment, allowing seamless switching between local and SBX executors while maintaining a consistent evidence structure. This enables engineers to reliably rerun, inspect, and compare AI evaluation workflows.
  11. Secure by default is your only way forward | DockerThis post introduces Docker Hardened Images and hardened MCP servers as extensions of the secure foundation for AI agents. It details the MCP Gateway for authenticated and authorized tool calls, and Docker Scout for build-time policy enforcement. The post also highlights the use of MicroVM-based Docker Sandboxes for agent execution, emphasizing the creation of a unified security boundary for both human and agentic workflows.
  12. Run AI Agents in GitHub Actions with Docker Sandboxes | DockerThis post details the integration of Docker Sandboxes (`docker-sbx`) with GitHub Agentic Workflows, enabling AI agents to run within isolated microVMs in CI/CD pipelines. It explains how `gh-aw compile` transforms Markdown workflows into GitHub Actions, leveraging `docker-sbx` as an agent runtime. The post highlights the isolation boundary provided by microVMs, each with its own kernel, filesystem, and private Docker daemon, allowing agents to run Testcontainers locally without compromising the host. A practical example demonstrates an agent fixing a bug in a Java application within this setup, with strict controls on file access and network exposure. It also provides instructions for setting up and running the workflow locally and on GitHub-hosted runners, and introduces Docker AI Governance for organizational policy enforcement.
  13. 17,600 Actions: Agent Security Is a Systems ProblemThis post analyzes the OpenAI/Hugging Face incident, framing agent security as a systems problem driven by the rate and persistence of AI agent actions, rather than the novelty of the attack. It details the incident's attack path, emphasizing the escape through a permitted service and the subsequent privilege escalation. The core contribution is a breakdown of required controls, categorizing them by potential failure modes (e.g., untrusted content, poisoned tools, external data becoming executable). It introduces the concept of making friction proportional to consequence, advocating for architectural boundaries that prevent untrusted content from granting authority. Docker's role is positioned within the 'Constrain', 'Authorize', and 'Observe' outcomes of the Agent Baseline, with Docker Sandboxes providing microVM isolation and Docker AI Governance offering centralized policy enforcement. The post concludes by discussing the operational tradeoffs between security, capability, and autonomy, and the ongoing work needed in observation, validation, and response.
  14. Coding Agent Horror Stories: The Command You Already Approved | DockerThis post details a specific security vulnerability (CVE-2026-22708) in AI coding agent command allowlisting, where shell built-ins could be used to silently alter environment variables, leading to arbitrary code execution when a seemingly harmless command was approved. It explains how this attack works by manipulating environment variables like PAGER or PYTHONWARNINGS, and how it bypasses traditional allowlists. The post then contrasts this with Docker Sandboxes, explaining how they contain such attacks by running agents in isolated microVMs with their own kernels and filesystems, preventing access to host resources like SSH keys or persistent configuration files. It highlights that while the agent can still execute commands within the sandbox, its ability to exfiltrate data or persist changes is severely limited by the sandbox's network policies and ephemeral nature.
  15. ESP32 Firmware Development with Docker Sandboxes | DockerThis post details the practical application of Docker Sandboxes for ESP32 firmware development. It explains how to use the `espressif/idf` Docker image for reproducible builds, including compiler caching and serial port passthrough (via RFC2217 on macOS/Windows). It then introduces Docker Sandboxes (`sbx`) as a secure environment for AI agents to interact with firmware development workflows, including building and flashing hardware. The post highlights the benefits of disposability, network policy, and credential isolation offered by sandboxes, and demonstrates how to combine them with the RFC2217 serial bridge for end-to-end hardware-in-the-loop AI development.
  16. Announcing: Docker VMM Public Beta | DockerIntroduces Docker VMM, a new first-party virtualization layer for Docker Desktop, built from the ground up for container workloads. Details performance improvements (faster startup, better file I/O, smarter memory management, improved stability on Windows) and its shared foundation with Docker Sandboxes (SBX). Outlines the path towards a unified runtime for containers, Compose apps, and agents. Provides instructions for enabling the public beta on Mac and Windows.
  17. A new security baseline for enterprise agentic adoption | DockerThis post introduces the Agent Baseline, a blueprint for enterprise AI adoption that defines six security outcomes (Discover, Constrain, Authorize, Observe, Validate, Respond) for governing AI agents. It details how these controls address practical security challenges like prompt injection and unauthorized data exfiltration by limiting agent runtime, data access, tool usage, and network reach. The post also highlights the integration of these principles with Docker Sandboxes and Docker AI Governance to provide a comprehensive infrastructure for managing agentic risk.
  18. AI Governance Is a Developer Experience Problem | DockerThis post shifts the focus of AI agent development from pure capability to the critical role of governance in enabling trust and adoption. It argues that by providing clear boundaries and embedding governance into the platform, organizations can overcome the 'trust bottleneck' and unlock the productivity potential of AI agents. The post highlights that successful adoption hinges on creating environments where useful actions can happen safely by default, rather than forcing developers to manually approve every step. It frames governance not as a restriction, but as an enabler of developer freedom and organizational scalability.
  19. Docker AI Governance: Audit Logs, Now Where Your Security Team Already Works | DockerThis post introduces the streaming of audit logs from Docker AI Governance policy decisions to SIEM tools. It details how these logs capture allowed, denied, and human-held actions at the enforcement point, providing a crucial record for security teams. The post also highlights the availability of these logs within Docker Cloud and the native SIEM streaming capability via HTTPS, covering Docker Sandboxes policy decisions and sandbox session events.
  20. Why Empty Sandboxes Break Developer Experience | DockerThis post introduces and details Docker Sandbox 'kits' as a solution to the developer experience challenges posed by empty, isolated sandboxes. It explains how kits, defined by a `spec.yaml` and optional files, allow for the repeatable installation of tools (e.g., SDKs, CLIs), configuration of network access (allowed/denied domains, service domains), and secure credential management (proxy-managed secrets). The post differentiates between `sandbox` kits (for building agents) and `mixin` kits (for extending existing sandboxes), advocating for the latter's composability. It highlights the benefits of kits for sharing setup configurations within teams and across organizations via OCI artifacts, ultimately making sandboxes more survivable as development tools by providing a convenient and configurable environment.
  21. Coding Agent Horror Stories: The 29 Million Secret Problem | DockerThis post details a specific attack vector where a poisoned npm package (`nx`) leveraged installed AI coding agents by invoking them with permission-bypass flags (`--dangerously-skip-permissions`, `--yolo`, `--trust-all-tools`) to scan for and exfiltrate secrets from the developer's filesystem. It highlights that AI-assisted code leaks secrets at roughly twice the baseline rate due to agents running with the developer's full filesystem access. The post then explains how Docker Sandboxes mitigate this by providing workspace-scoped filesystem access (preventing access to host home directories and configurations) and proxy-injecting credentials at the network boundary, rendering the agent unable to see or access host secrets.
  22. Agentic AI Security: What CISOs Say About Governing AI AgentsThis post details the security challenges and best practices for governing AI agents in enterprise environments, emphasizing the need for isolation, control, and observation. It highlights Docker's approach of running AI agents in disposable, isolated, local sandboxes (Docker Sandboxes) and the integration with NanoClaw for secure-by-design agent execution using MicroVMs. It also discusses the implications of laptops becoming the new production environment for agents, the concept of portability for agent environments, and strategies for securing the AI supply chain, including keeping humans in the loop and layering security. The post also touches upon the MCP Gateway as a chokepoint for agent tool calls.
  23. AI Governance: Runtime Enforcement, Not Runtime Advice | DockerThis post introduces the concept of runtime enforcement for AI governance, distinguishing it from mere policy advice. It details three key boundaries for agent autonomy: execution, tool access, and credential access. The post emphasizes that isolation is a fundamental security principle for creating these boundaries and mentions Docker Sandboxes as an example of how isolation concepts are being adapted for agent execution workflows. It argues that clear boundaries build trust and enable developers to delegate more work to agents.
  24. AI Coding Agent Horror Stories: The Agent That Deleted Production | DockerThis post details a real-world incident where an AI coding assistant (Kiro) with operator-level AWS credentials deleted a production environment, causing a 13-hour outage and subsequent incidents. It explains the failure mechanism: the agent inheriting full permissions without a separate identity, and the tight coupling of reasoning and execution steps. The post introduces the 'scoped-identity' pattern as a technical solution to prevent this class of failure by limiting agent permissions, and contrasts this with the 'controlled friction' approach of human peer review implemented by AWS.
  25. AI Agents Explained: How to Build with Them Safely | DockerThis post defines AI agents, distinguishing them from chatbots and generative AI by their autonomy and tool-use capabilities. It details the core components of an agent (model, tools, memory, orchestration, environment) and explains the agent loop (perceive, reason, act, observe, adapt). The post highlights the shift in software development towards treating agents as an infrastructure problem, emphasizing the importance of the execution environment for safety and security. It discusses common misconceptions and provides guidance on building and running agents safely, advocating for isolated, disposable environments like Docker Sandboxes and microVMs. It also introduces Docker's AI Governance for team-wide rule enforcement.
  26. AI Engineer World's Fair 2026: The Runtime Is Where Agent Trust Is Won | DockerThis post details Docker's perspective on securing AI agents at the runtime level, emphasizing the "lethal trifecta" of risks (private data, untrusted content, ability to act) and how microVM sandboxes address these by providing isolation for filesystem, network, and tools. It also highlights the importance of governing the tool layer (MCP servers) through an org-managed catalog to prevent unvetted installations. The post introduces the concept of "shadow MCP" and demonstrates how Docker AI Governance ties sandbox and MCP policy into a single console.
  27. Your Laptop Is the New Production Environment | DockerThis post introduces the concept of the developer's laptop becoming a 'production environment' due to the increasing autonomy and action-delegating capabilities of AI agents. It contrasts traditional security models, which govern workflow checkpoints, with the new challenge of governing AI agent execution at runtime. The post argues that prompt-based guardrails are insufficient and advocates for runtime enforcement of policies, isolation, and controlled tool access. It identifies two primary interaction surfaces for agents: local execution (reading files, modifying code, installing software, executing commands, opening network connections) and tool usage (interacting with external systems via APIs and integrations). The core technical contribution is the framing of AI agent governance as an infrastructure problem requiring runtime boundaries and consistent enforcement across different execution environments (laptop, CI, production).
  28. Why AI Agents Need Isolation with Docker SBX | DockerThis post details the technical implementation of Docker SBX, emphasizing its microVM-based isolation for AI agents, contrasting it with traditional containers. It explains the proxy-managed credential handling mechanism, where secrets are routed through a proxy instead of directly entering the sandbox VM. The post also introduces and differentiates between Mixin Kits (extending existing agents) and Agent Kits (defining complete agent environments), highlighting their roles in standardizing and securing AI development workflows through reusable environment blueprints.