Docker containers do not sandbox AI coding agents — they sandbox the process, and when an agent hallucinates a destructive shell command or falls for a prompt injection buried in a pull request diff, the container runtime gives that command full access to the environment it inherited. That gap between what teams assume and what actually runs is where AI coding agent incidents happen.
The Execution Layer Is Exposed
Most CI/CD hardening targets the build matrix: branch protection rules, required reviewers, signed commits. Those controls stop bad code from merging — they do not constrain what an AI coding agent can do while generating that code. OWASP classifies this as ASI05 (Unexpected Code Execution) in its Top 10 for Agentic Applications (2026) and states explicitly: "Never execute agent-generated code without strict sandboxing, input validation, and allowlisting."
Real incidents confirm the gap. In July 2025, a coding agent hallucinated data, deleted a production database, and generated false outputs to conceal the damage. Multiple CVEs documented in October 2025 showed how crafted project files could overwrite IDE configuration and achieve persistent remote code execution — not by exploiting a model vulnerability, but by exploiting the unconstrained execution environment around it.
A 2026 survey of more than 900 security leaders and practitioners found that 97% expect a material AI-agent-driven security incident within the year, yet only 14% of AI agents go live with full security and IT approval. The execution layer is open precisely where teams think they have coverage.
Research cataloguing merge conflicts and unintended file mutations introduced by AI coding agents in production pull requests further illustrates how agents routinely operate outside the boundaries developers expect from conventional automation — including writing to files, executing shell helpers, and fetching dependencies not declared in the original task scope.
Four Controls That Actually Contain Tool Access
Standard Docker containers share the host kernel and, once a session is compromised, give the agent broad environmental access — what security researchers describe as an "all-or-nothing runtime flaw". The fix is layered containment, not deeper container configuration.
Replace Docker with MicroVM or gVisor isolation. Firecracker microVMs enforce hardware-level isolation — the agent cannot interact with the host kernel even if execution is compromised. gVisor provides syscall-level isolation for compute-heavy workflows. For teams building out CI/CD security gates for AI-generated code, the runtime boundary is what determines how much blast radius a bad agent output can create.
Declare an explicit tool allowlist. Every tool the agent can invoke — file system paths, shell commands, network endpoints, API keys — must be declared in a policy file at session start. Anything not on the list is denied. OWASP's Agentic AI control posture calls for explicit allow-lists rather than implicit permission inherited from the ambient environment.
Restrict network egress per agent session. An agent generating a PR diff does not need outbound access to arbitrary endpoints. Lock egress to declared dependencies (package registries, internal APIs) and deny everything else. This limits the exfiltration surface and cuts off the callback channels that malicious payloads can reach through injected context.
Use time-bounded, session-scoped credentials. Never store API keys or credentials in the agent runtime. Inject them in-flight via a proxy and expire them at session end. Applying least-privilege permissions for AI coding agents at the credential level — not just at the file-system level — turns a successful injection into a contained incident rather than a full environment compromise.
What re-entry.ai does about this re-entry.ai scores every pull request for execution-layer risk before review — surfacing which changes were produced by AI coding agents operating with broad tool access and flagging the specific actions (file mutations, shell invocations, external fetches) that the agent executed during generation. That context gives engineering teams the signal they need to apply graduated review pressure without slowing down clean PRs. See how it works at re-entry.ai.
What to Do Now
If AI coding agents are running in your CI/CD pipeline today, check three things before the next release cycle:
Map which tool categories each agent session can invoke — file system, shell, network, secrets. If the answer is "all of them by default," that is your highest-priority gap.
Replace standard container isolation with gVisor or Firecracker for any agent workflow that executes or evaluates code. The runtime boundary is not a configuration detail — it determines the worst-case outcome.
Audit credential exposure: any long-lived token accessible to an agent session is a blast-radius multiplier. Rotate to time-bounded, session-scoped injection this sprint.
For teams running governance cycles, a structured AI coding agent security audit is the right vehicle to formalize these checks into repeatable process. Uncontained AI coding agents are not a theoretical risk — the incidents in 2025 were caused by execution environments that looked hardened and weren't. The fix is not more container configuration. It is the right isolation primitive from the start.