As “AI coding agents” that delegate programming tasks to AI become increasingly widespread, cases are emerging where misjudging safety can lead to serious damage. On August 18, 2026, Docker published an analysis explaining that even when users approve seemingly safe commands, attackers’ arbitrary code can still be executed. The company points out that the “allowlist” approach used by AI agents has structural weaknesses, and that judging safety based solely on command names is dangerous.

AI coding agents can not only generate code but also execute commands in the terminal. To save users the hassle of approving every action, a common approach is to register relatively safe commands like “git” on an allowlist for automatic execution. However, this “command-name-based permission” system can become an entry point for attacks.

Docker highlighted the vulnerability “CVE-2026-22708,” discovered in the AI code editor “Cursor.” While it has been fixed in Cursor 2.3, in affected environments, shell built-in commands such as “export” could be executed without user confirmation, allowing environment variables to be freely rewritten.

The attack flow is sophisticated. Git references an environment variable called “PAGER” to determine how output is displayed. Attackers guide the AI agent to rewrite PAGER with malicious content. Then, when a user approves “git branch” believing it to be safe, the attacker’s planted code executes through Git’s processing. From the user’s perspective, they merely approved a harmless “git branch” command, yet arbitrary code is running behind the scenes.

The technique of exploiting environment variables has been known for some time. But the emergence of AI agents has dramatically changed the landscape. AI agents can read text contained in README files, dependency packages, issue comments, and automatically execute multiple operations in sequence. Attacks that previously required an attacker to access a terminal and manually perform multiple steps can now potentially proceed automatically simply by having the AI agent read malicious text.

The limits of command approval and the importance of “execution guardrails”

This issue highlights challenges relevant to AI agent safety measures overall. A key concept in AI safety is “guardrails” — mechanisms that check input information, AI-generated responses, and the operations AI actually performs, stopping dangerous processes.

Guardrails can be broadly divided into three categories: “input,” “output,” and “execution.” Input guardrails check user instructions, web pages, emails, and other content before passing them to the AI, detecting prompt injection and confidential information. Output guardrails inspect AI responses for inappropriate expressions or information leakage before displaying them to users. And what is considered particularly important in the AI agent era is the “execution guardrail,” which prohibits dangerous operations or requires human approval when AI performs actions such as sending emails, manipulating files, or accessing databases.

A symbolic incident demonstrating the danger of entrusting safety to AI’s “self-restraint” occurred in April 2026. At U.S.-based PocketOS, the coding AI agent “Cursor” encountered a credential mismatch during its work and, in the process of trying to resolve the issue on its own, discovered an API token with powerful privileges. Without any confirmation, it deleted the production database and volume-level backups. The entire process took just 9 seconds. Despite having been instructed to avoid destructive operations, the AI executed actions that violated those rules.

Frameworks for adding safety features to AI, such as NVIDIA’s “NeMo Guardrails” and Meta’s “Llama Guard,” are now publicly available. However, there is growing recognition that ensuring safety at the stage where AI agents actually execute commands cannot be achieved through prompt-based instructions alone.

Docker’s proposed “isolation” approach

Docker’s recommended countermeasure is “Docker Sandboxes.” This mechanism runs AI coding agents inside small virtual machines called “microVMs” that are isolated from the host OS, providing an environment where AI agents can freely execute code while controlling credentials and external network access outside the sandbox.

With Docker Sandboxes, AI agents are placed inside microVMs, and all external communication goes through a proxy. Raw credentials such as API keys and SSH private key files are not placed directly inside the microVM, and accessible networks are restricted by rules. Even if environment variables are rewritten and attack code executes within the microVM, the design prevents direct access to areas not shared with the host.

In Docker’s example, even if PAGER is rewritten and malicious processing executes, the host’s SSH private key files do not exist inside the microVM, so the attack code cannot read and exfiltrate the private keys themselves. However, under default settings, the working directory is shared with the host in a read-write state, meaning the isolation is not complete for all data.

Docker states: “Rather than trying to accurately determine whether every instruction an AI agent reads is safe, it is more useful to preemptively limit what the AI agent can reach.” The approach of refining command-name allowlists has inherent limits, and a paradigm shift toward isolating the execution environment itself is needed.

As AI evolves from a “chat advisor” to an “agent” that actually performs work, the importance of design decisions around “what not to let it do” and “where to stop it when things get dangerous” is growing just as much as model performance improvements. To allow AI to work more freely, robust guardrails and execution environment isolation are becoming essential.