Security researchers have exposed a recurring weakness in Cursor, OpenAI Codex CLI, Google Gemini CLI, and Antigravity that challenges one of the industry’s most reassuring claims: that an AI coding agent is safe because its commands run inside a sandbox. The agents often remained technically confined, but files they created or modified were later consumed by trusted host applications, extensions, task runners, Git integrations, Python tooling, hooks, or Docker services. The result was code execution beyond the sandbox without necessarily exploiting the operating system’s isolation mechanism at all.
AI coding assistants have rapidly evolved from autocomplete systems into autonomous development agents. They can inspect repositories, edit multiple files, install dependencies, execute tests, invoke command-line tools, interact with containers, and continue working through complex tasks with limited human supervision.
That increased capability has forced vendors to build security controls around agent activity. The most visible of these controls is the sandbox: a restricted execution environment intended to limit file access, network connectivity, process creation, and changes to the host operating system.
This distinction matters because the agent is no longer merely advising a trusted human. It is an active endpoint participant operating close to source code, SSH keys, browser sessions, package registries, cloud credentials, development certificates, and production management tools.
The security model must therefore account for more than whether a generated shell command can directly read a sensitive directory. It must also consider every local component that may react to the agent’s output.
Modern implementations may rely on containers, Linux security mechanisms, macOS Seatbelt profiles, command policies, filesystem rules, or platform-specific process isolation. These controls can stop many direct attacks and accidental destructive actions.
However, the new research from Pillar Security shows why isolating execution is not the same as isolating influence. An agent does not need permission to launch a host process if it can alter a file that causes an already trusted host process to launch something later.
The security failure occurred at the next trust handoff. An unsandboxed application interpreted the agent-produced artifact as configuration, metadata, an executable, or a legitimate instruction.
The Pillar findings often took a different route:
That design was manageable when humans were assumed to author or review most consequential configuration changes. Agentic tools weaken that assumption because they can create plausible-looking files at machine speed, sometimes in response to hidden or adversarial instructions.
A workspace is therefore not merely a folder of documents. In a modern IDE, it is an event-driven control surface capable of influencing the host.
Coding agents routinely consume untrusted material. A developer may ask an agent to inspect a newly cloned repository, analyze a dependency, review a pull request, fix a reported issue, summarize logs, or research an error message online.
Yet opening, cloning, inspecting, and building third-party repositories are ordinary development activities. Security controls for coding agents exist partly because repository contents cannot always be assumed trustworthy.
The relevant question is not whether a user initiated contact with malicious content. It is whether the product’s advertised isolation boundary still prevents that content from producing an unexpected host-side consequence.
The affected paths included hook configuration, Python virtual environments, and alternative Git metadata. Each route used a different host feature, but all relied on the same architectural mistake: treating an agent-writable artifact as safe input to an unsandboxed component.
If the agent can write a hook definition inside the project and Cursor later executes that hook outside the sandbox, the configuration file effectively becomes a deferred command launcher. The agent itself never has to invoke the final payload directly.
The issue received the identifier CVE-2026-48124 and was addressed in Cursor 3.0.0. The fix is important, but the vulnerability also demonstrates why executable project configuration needs different handling when its author may be an AI agent.
An agent allowed to modify the project could reportedly alter the virtual environment’s interpreter or related structure. Cursor’s unsandboxed Python extension would then discover and execute the manipulated interpreter as part of normal environment detection.
This is a particularly instructive example because interpreter discovery appears benign. A policy may correctly prevent the agent from directly launching an unsandboxed binary, yet allow it to change a project-local environment that the editor launches automatically.
Git metadata outside
A third Cursor issue exploited the fact that Git metadata does not always reside in a directory literally named
Path-based protections that focus only on blocking writes to a conventional
Cursor patched this path in version 3.0.0, with a CVE still pending at the time of disclosure. The lesson extends beyond Git: security rules based on familiar filenames are brittle when the underlying tool supports aliases, redirects, indirection, or configurable paths.
Pillar’s finding showed how that balance fails when a policy evaluates a command by name without fully modeling what its arguments and side effects can do.
When
Developers normally use
Git’s command-line interface, however, is powerful and highly configurable. Options can influence processing behavior, output handling, external helpers, configuration values, and interactions with repository state.
According to the researchers, Codex CLI’s allowlist relied too heavily on the trusted
An allowlist that labels an entire developer tool as safe can create a broad bypass. Conversely, requiring approval for every invocation can overwhelm users and train them to click through warnings without inspection.
The viable middle ground is context-aware policy combined with deterministic enforcement. AI model judgment may help classify intent, but it should not be the final security boundary for host-level execution.
The precise risk depends on configuration and platform. Nevertheless, an agent that can reach a powerful local daemon may be able to request a container with host directories mounted, elevated capabilities enabled, or commands executed in a context far less restricted than its original sandbox.
If a sandbox blocks direct filesystem access but permits communication with the Docker control plane, the agent may ask Docker to perform actions on its behalf. The daemon becomes a confused deputy: a trusted, privileged component carrying out requests from a less-trusted caller.
This is not necessarily a Docker vulnerability. It is a failure to recognize that access to the daemon is itself a powerful capability that must cross the same approval and policy checks as direct host execution.
A malicious container request could attempt to mount sensitive host paths, access credentials, connect to internal services, or manipulate source code outside the intended workspace. Even without full host compromise, access to development containers may expose secrets and network identities unavailable inside the original agent sandbox.
The shared issue has reportedly been resolved. Its presence across three tools reinforces the argument that vendors need to inventory privileged local services, not merely filesystem paths and shell commands.
That position highlights a wider disagreement over how agentic vulnerabilities should be scored. Conventional severity frameworks often focus on direct exploitability, required user interaction, and privileges already obtained.
A denylist succeeds only when defenders anticipate every dangerous route. An adaptive agent can test combinations, retry failed approaches, and use obscure but legitimate platform features that a static rule set omitted.
A stronger design starts from deny-by-default and adds narrowly scoped capabilities required for the task. This can reduce convenience, but it produces a boundary that is easier to reason about and audit.
The
Visual Studio Code task files can define commands for building, testing, launching, and automating projects. If an agent can create or modify such a task while an unsandboxed editor later runs it, the task acts as a delayed execution mechanism.
Some exploitation scenarios may require the developer to trigger the task or trust the workspace. Even so, automated and semi-automated task execution is common enough that these files deserve explicit controls.
At minimum, an editor should clearly distinguish between configuration created by the user, configuration obtained from a repository, and configuration generated by an AI agent during the current session. Treating all three as equally trusted discards valuable provenance.
The concern is not that every listed product remains vulnerable through every path on Windows. It is that Windows hosts provide many equivalent trust handoffs that vendors and administrators must evaluate.
Windows also has path-search and executable-resolution behaviors that can become dangerous when applications look in the current directory before trusted system locations. A project-local executable named like a legitimate helper may be launched by host software if resolution rules are not carefully controlled.
Other high-value interfaces include Docker Desktop, Windows Subsystem for Linux integration, named pipes, local HTTP management endpoints, credential helpers, SSH agents, and cloud command-line sessions. A sandbox that can communicate with these services may possess more authority than its filesystem rules suggest.
However, these chains frequently use legitimate developer tools and expected parent processes. A Python extension launching an interpreter, Git invoking a configured helper, or Docker creating a container may not look malicious in isolation.
Detection needs richer context: which files the agent created, which trusted component consumed them, and whether execution followed. Without provenance linking the write to the later action, defenders may see only normal development activity.
A compromised development identity can modify source code, approve changes, publish packages, access artifact repositories, retrieve cloud secrets, and initiate deployment workflows. Host-level execution under the developer’s account may therefore be sufficient for severe organizational impact.
Enterprise policy should define:
Just-in-time access, hardware-backed authentication, isolated administrative workstations, and separate browser profiles can reduce the consequences of endpoint compromise. Build and release systems should also verify changes independently rather than trusting artifacts simply because they came from an authorized developer account.
The simplest defensive step is to avoid using an AI agent against an untrusted repository on a primary machine with valuable credentials. Convenience should not obscure the fact that an autonomous coding tool is capable of acting as the logged-in user.
The most consequential changes will be architectural rather than cosmetic.
Agent security must connect intent, file provenance, policy, and delayed side effects. The critical event may not be a suspicious command from the AI process; it may be an ordinary editor extension executing a file the agent silently changed seconds earlier.
That requires monitoring trust handoffs rather than only process trees. It also requires vendors to expose reliable telemetry so organizations can distinguish human actions from autonomous agent actions performed under the same user account.
The research into Cursor, Codex CLI, Gemini CLI, and Antigravity marks a significant shift in how sandbox security must be understood. The true boundary of an AI coding agent includes every file it can influence and every trusted component that may later act on that influence. Patching the seven reported vulnerabilities is necessary, but the lasting solution will require development tools to treat agent output as untrusted until it crosses an explicit, observable, and enforceable approval boundary.
Background
AI coding assistants have rapidly evolved from autocomplete systems into autonomous development agents. They can inspect repositories, edit multiple files, install dependencies, execute tests, invoke command-line tools, interact with containers, and continue working through complex tasks with limited human supervision.That increased capability has forced vendors to build security controls around agent activity. The most visible of these controls is the sandbox: a restricted execution environment intended to limit file access, network connectivity, process creation, and changes to the host operating system.
From code suggestions to endpoint actors
Traditional code completion presents text that a developer must review and accept. An agentic coding tool can instead perform the work itself, often through a terminal, an IDE extension, or a combination of local processes and cloud-based reasoning.This distinction matters because the agent is no longer merely advising a trusted human. It is an active endpoint participant operating close to source code, SSH keys, browser sessions, package registries, cloud credentials, development certificates, and production management tools.
The security model must therefore account for more than whether a generated shell command can directly read a sensitive directory. It must also consider every local component that may react to the agent’s output.
Why sandboxes became the default answer
Sandboxing provides a practical way to retain much of an agent’s usefulness while limiting its authority. An agent can usually write within a project workspace and run common build or test commands, while access to other directories, unrestricted networking, or dangerous operations remains blocked or subject to approval.Modern implementations may rely on containers, Linux security mechanisms, macOS Seatbelt profiles, command policies, filesystem rules, or platform-specific process isolation. These controls can stop many direct attacks and accidental destructive actions.
However, the new research from Pillar Security shows why isolating execution is not the same as isolating influence. An agent does not need permission to launch a host process if it can alter a file that causes an already trusted host process to launch something later.
The Sandbox Did Not Always Break
Calling every finding a “sandbox escape” risks obscuring what makes this vulnerability class important. In several demonstrated attack chains, the sandbox continued enforcing its stated restrictions while the agent wrote files in locations it was explicitly permitted to modify.The security failure occurred at the next trust handoff. An unsandboxed application interpreted the agent-produced artifact as configuration, metadata, an executable, or a legitimate instruction.
Isolation versus delayed execution
A classic sandbox escape normally involves defeating the sandbox itself. Attackers may exploit a kernel vulnerability, container runtime defect, policy mistake, or exposed system interface to execute code directly beyond the restricted process.The Pillar findings often took a different route:
- An attacker placed an indirect instruction in content the agent was likely to process.
- The agent followed that instruction and wrote or modified a project file.
- The sandbox allowed the write because the file was inside an approved workspace.
- A trusted host component later discovered or loaded the file.
- That component performed an action outside the agent’s restrictions.
The project directory is not passive data
For decades, developers have treated repositories as collections of source code plus executable configuration. Project files can define build steps, debugger launch commands, environment activation, test runners, Git hooks, task automation, container services, package scripts, extension recommendations, and deployment workflows.That design was manageable when humans were assumed to author or review most consequential configuration changes. Agentic tools weaken that assumption because they can create plausible-looking files at machine speed, sometimes in response to hidden or adversarial instructions.
A workspace is therefore not merely a folder of documents. In a modern IDE, it is an event-driven control surface capable of influencing the host.
How an Attacker Reaches the Agent
The reported chains generally require the agent to encounter attacker-controlled content or otherwise be induced to perform a malicious write. That condition is meaningful, but it is not unusual in software development.Coding agents routinely consume untrusted material. A developer may ask an agent to inspect a newly cloned repository, analyze a dependency, review a pull request, fix a reported issue, summarize logs, or research an error message online.
Indirect prompt injection becomes local action
An attacker can conceal instructions in places such as:- A README can contain text aimed at an AI assistant rather than the human reader.
- A source-code comment can direct the agent to create a particular configuration file.
- A Git issue or pull-request description can introduce malicious operational steps.
- A dependency can contain documentation, scripts, or metadata designed to manipulate automated analysis.
- A web page retrieved during troubleshooting can tell the model to perform actions unrelated to the developer’s request.
- A generated log or test fixture can include instructions that appear to be trusted task context.
Social engineering is part of the threat model
Google reportedly rated two Antigravity findings lower partly because exploitation depended on social engineering or on a developer trusting a malicious repository. That assessment reflects a conventional distinction between a remotely exploitable vulnerability and a chain requiring user involvement.Yet opening, cloning, inspecting, and building third-party repositories are ordinary development activities. Security controls for coding agents exist partly because repository contents cannot always be assumed trustworthy.
The relevant question is not whether a user initiated contact with malicious content. It is whether the product’s advertised isolation boundary still prevents that content from producing an unexpected host-side consequence.
Cursor’s Multiple Trust Handoffs
Cursor accounted for several findings, illustrating how an agentic IDE inherits the broad attack surface of both the AI agent and the editor platform around it. An IDE does far more than display text; it continuously discovers runtimes, indexes metadata, loads workspace settings, and communicates with extensions.The affected paths included hook configuration, Python virtual environments, and alternative Git metadata. Each route used a different host feature, but all relied on the same architectural mistake: treating an agent-writable artifact as safe input to an unsandboxed component.
Workspace hook configuration
One Cursor vulnerability involved configuration for Claude-compatible hooks. Hooks are designed to automate commands around lifecycle events, making them useful for validation, formatting, notifications, and workflow integration.If the agent can write a hook definition inside the project and Cursor later executes that hook outside the sandbox, the configuration file effectively becomes a deferred command launcher. The agent itself never has to invoke the final payload directly.
The issue received the identifier CVE-2026-48124 and was addressed in Cursor 3.0.0. The fix is important, but the vulnerability also demonstrates why executable project configuration needs different handling when its author may be an AI agent.
Python interpreter discovery
Another Cursor chain targeted a Python virtual environment. Python tooling commonly scans projects for virtual environments and identifies the interpreter associated with each one.An agent allowed to modify the project could reportedly alter the virtual environment’s interpreter or related structure. Cursor’s unsandboxed Python extension would then discover and execute the manipulated interpreter as part of normal environment detection.
This is a particularly instructive example because interpreter discovery appears benign. A policy may correctly prevent the agent from directly launching an unsandboxed binary, yet allow it to change a project-local environment that the editor launches automatically.
Git metadata outside .git
A third Cursor issue exploited the fact that Git metadata does not always reside in a directory literally named .git. Git supports indirection and alternative layouts, including a .git file that points to metadata elsewhere.Path-based protections that focus only on blocking writes to a conventional
.git directory can therefore miss equivalent sensitive locations. According to the research, modified Git configuration could involve an fsmonitor helper that the host-side Git integration later executed.Cursor patched this path in version 3.0.0, with a CVE still pending at the time of disclosure. The lesson extends beyond Git: security rules based on familiar filenames are brittle when the underlying tool supports aliases, redirects, indirection, or configurable paths.
Codex CLI and the Limits of Command Allowlists
OpenAI’s Codex CLI uses sandboxing and approval policies to distinguish ordinary development commands from operations that require more scrutiny. This approach can reduce interruptions while retaining a barrier around high-risk activity.Pillar’s finding showed how that balance fails when a policy evaluates a command by name without fully modeling what its arguments and side effects can do.
When git show is not read-only
Developers normally use git show to display commits, tags, trees, and file contents. It therefore appears suitable for a safe-command allowlist.Git’s command-line interface, however, is powerful and highly configurable. Options can influence processing behavior, output handling, external helpers, configuration values, and interactions with repository state.
According to the researchers, Codex CLI’s allowlist relied too heavily on the trusted
git show command name even though specially selected parameters could produce changes or execution-relevant side effects. The policy recognized a familiar label rather than evaluating the complete invocation.A policy must understand the whole operation
Robust command authorization cannot stop after matching the executable and first argument. It must consider:- The fully resolved executable path must be validated rather than trusting a name found through environment-dependent lookup.
- Every argument must be evaluated, including options that load configuration or invoke external helpers.
- Environment variables must be treated as part of the operation because they can change program behavior.
- The working directory and repository state must be included in the decision.
- File descriptors, redirections, pipes, and command substitution must not escape policy inspection.
- The command’s likely side effects must determine whether approval is required.
The difficulty of “safe” developer commands
Git is not unique. Package managers, compilers, build systems, scripting runtimes, archive utilities, and cloud CLIs often expose options that execute plugins, load configuration, contact services, or write to unexpected locations.An allowlist that labels an entire developer tool as safe can create a broad bypass. Conversely, requiring approval for every invocation can overwhelm users and train them to click through warnings without inspection.
The viable middle ground is context-aware policy combined with deterministic enforcement. AI model judgment may help classify intent, but it should not be the final security boundary for host-level execution.
Docker as an Unsandboxed Side Door
A vulnerability affecting Cursor, Codex CLI, and Gemini CLI involved access to a privileged Docker service outside the sandbox. Docker is commonly treated as a containment technology, but control over a sufficiently privileged Docker daemon can amount to control over the host.The precise risk depends on configuration and platform. Nevertheless, an agent that can reach a powerful local daemon may be able to request a container with host directories mounted, elevated capabilities enabled, or commands executed in a context far less restricted than its original sandbox.
The socket is an authority boundary
On Linux, Docker clients commonly communicate with a daemon through a Unix socket. Docker Desktop and related products may expose local APIs or helper services through platform-specific mechanisms.If a sandbox blocks direct filesystem access but permits communication with the Docker control plane, the agent may ask Docker to perform actions on its behalf. The daemon becomes a confused deputy: a trusted, privileged component carrying out requests from a less-trusted caller.
This is not necessarily a Docker vulnerability. It is a failure to recognize that access to the daemon is itself a powerful capability that must cross the same approval and policy checks as direct host execution.
Why containers can make the chain deceptive
Developers may see a Docker-related action and assume it remains isolated inside a container. That assumption is unsafe when the agent controls container creation parameters.A malicious container request could attempt to mount sensitive host paths, access credentials, connect to internal services, or manipulate source code outside the intended workspace. Even without full host compromise, access to development containers may expose secrets and network identities unavailable inside the original agent sandbox.
The shared issue has reportedly been resolved. Its presence across three tools reinforces the argument that vendors need to inventory privileged local services, not merely filesystem paths and shell commands.
Antigravity and Google’s Lower Severity Assessment
Pillar also examined Antigravity, reporting bypasses involving macOS Seatbelt policy and Visual Studio Code task configuration. Google reportedly treated the findings as valid but assigned lower severity because practical exploitation required social engineering or trust in a malicious repository.That position highlights a wider disagreement over how agentic vulnerabilities should be scored. Conventional severity frameworks often focus on direct exploitability, required user interaction, and privileges already obtained.
Deny-by-default versus allow-by-default
The Seatbelt-related finding concerned a policy that reportedly operated more like an allow-default profile with selected dangerous behavior denied. Such models are difficult to secure comprehensively because modern operating systems expose an enormous number of services, launch paths, filesystem mechanisms, and interprocess communication channels.A denylist succeeds only when defenders anticipate every dangerous route. An adaptive agent can test combinations, retry failed approaches, and use obscure but legitimate platform features that a static rule set omitted.
A stronger design starts from deny-by-default and adds narrowly scoped capabilities required for the task. This can reduce convenience, but it produces a boundary that is easier to reason about and audit.
The .vscode time bomb
Visual Studio Code task files can define commands for building, testing, launching, and automating projects. If an agent can create or modify such a task while an unsandboxed editor later runs it, the task acts as a delayed execution mechanism.Some exploitation scenarios may require the developer to trigger the task or trust the workspace. Even so, automated and semi-automated task execution is common enough that these files deserve explicit controls.
At minimum, an editor should clearly distinguish between configuration created by the user, configuration obtained from a repository, and configuration generated by an AI agent during the current session. Treating all three as equally trusted discards valuable provenance.
Why Windows Developers Should Care
Several demonstrations focused on Linux or macOS mechanisms, but the underlying problem is highly relevant to Windows. Windows development environments are rich in automatic discovery, project-local executables, PowerShell scripts, task definitions, package hooks, debugging profiles, and background helper processes.The concern is not that every listed product remains vulnerable through every path on Windows. It is that Windows hosts provide many equivalent trust handoffs that vendors and administrators must evaluate.
Windows-specific execution surfaces
Potentially sensitive workspace artifacts include Visual Studio Code tasks, launch profiles, PowerShell scripts, MSBuild project targets, NuGet package behavior, Node package scripts, Python virtual environments, Git configuration, debugger adapters, test discovery extensions, and Dev Container definitions.Windows also has path-search and executable-resolution behaviors that can become dangerous when applications look in the current directory before trusted system locations. A project-local executable named like a legitimate helper may be launched by host software if resolution rules are not carefully controlled.
Other high-value interfaces include Docker Desktop, Windows Subsystem for Linux integration, named pipes, local HTTP management endpoints, credential helpers, SSH agents, and cloud command-line sessions. A sandbox that can communicate with these services may possess more authority than its filesystem rules suggest.
Microsoft Defender is not a complete answer
Endpoint detection and response software may identify suspicious payloads, process trees, persistence attempts, or credential access. Microsoft Defender for Endpoint and competing products can therefore provide an important additional layer.However, these chains frequently use legitimate developer tools and expected parent processes. A Python extension launching an interpreter, Git invoking a configured helper, or Docker creating a container may not look malicious in isolation.
Detection needs richer context: which files the agent created, which trusted component consumed them, and whether execution followed. Without provenance linking the write to the later action, defenders may see only normal development activity.
Enterprise Impact
For enterprises, the findings turn AI coding assistants from an individual productivity choice into a software supply-chain and endpoint-governance concern. Developers often hold access that would be highly valuable to attackers, even when they are not local administrators.A compromised development identity can modify source code, approve changes, publish packages, access artifact repositories, retrieve cloud secrets, and initiate deployment workflows. Host-level execution under the developer’s account may therefore be sufficient for severe organizational impact.
AI tools need inventory and policy
Organizations should first determine which agentic tools are installed and how they are configured. Unsanctioned adoption can leave security teams unaware of agents capable of reading repositories, running commands, and interacting with local services.Enterprise policy should define:
- Approved versions must be patched and centrally tracked.
- High-risk repositories should be handled only in isolated development environments.
- Agent network access should be restricted to task-specific destinations.
- Privileged local daemons should remain unreachable unless explicitly required.
- Credentials should be short-lived, narrowly scoped, and stored outside agent-readable paths.
- Agent-created automation files should require human review before host execution.
- Security logs should preserve both tool actions and the provenance of changed files.
Separate development from production authority
The research strengthens the case for separating daily coding environments from production administration. A developer workstation running autonomous agents should not simultaneously hold persistent, broadly scoped credentials for critical infrastructure.Just-in-time access, hardware-backed authentication, isolated administrative workstations, and separate browser profiles can reduce the consequences of endpoint compromise. Build and release systems should also verify changes independently rather than trusting artifacts simply because they came from an authorized developer account.
Consumer and Independent Developer Impact
Independent developers may lack enterprise controls, but they often run agents with unusually broad access to personal and professional data on the same computer. A single workstation may contain source code, tax documents, password-manager sessions, cryptocurrency wallets, browser cookies, and cloud credentials.The simplest defensive step is to avoid using an AI agent against an untrusted repository on a primary machine with valuable credentials. Convenience should not obscure the fact that an autonomous coding tool is capable of acting as the logged-in user.
A practical hardening sequence
Developers can reduce exposure through a disciplined workflow:- Update each AI coding tool before opening unfamiliar projects. Cursor users should verify they are on version 3.0.0 or later, while Codex CLI users should run version 0.95.0 or later for the disclosed fixes.
- Open unknown repositories inside a disposable virtual machine or equivalent isolated environment. A container alone may be insufficient if powerful host services or shared directories remain exposed.
- Inspect automation files before allowing tasks, hooks, interpreters, or build scripts to run. Pay particular attention to newly created
.vscode, Git, Python environment, container, and agent-configuration files. - Keep Docker and similar privileged services unavailable by default. Enable access only for projects that genuinely require it.
- Use low-privilege, short-lived credentials. Avoid leaving production tokens available in the same session used for agent experimentation.
- Review the complete diff after an agent finishes. Include hidden files and configuration directories rather than reviewing only application source code.
- Discard the environment when the task is complete. Persistence makes delayed execution attacks more useful, while ephemeral environments remove many planted artifacts.
Strengths and Opportunities
The findings do not mean AI coding agents are inherently unusable. They expose clear engineering opportunities that could make the next generation of tools substantially safer.Better product architecture
- Vendors can apply the same policy to indirect execution as direct execution. If an agent cannot launch a command itself, a helper should not launch that command merely because the agent encoded it in configuration.
- Editors can record file provenance. Agent-created, repository-provided, and human-authored files should not automatically receive identical trust.
- Approval systems can focus on trust transitions. A warning is most valuable when an agent-produced artifact is about to trigger unsandboxed execution.
- Sandboxes can begin from deny-by-default policies. Narrow capability grants are easier to test than open-ended denylists.
- Command policies can validate complete invocations. Resolved paths, arguments, environment, working directory, and side effects should all influence authorization.
- Ephemeral workspaces can limit persistence. Destroying the environment after each task removes delayed payloads and poisoned configuration.
- Telemetry can connect writes to consequences. Defenders need an audit trail showing that an agent modified a file and a host process later executed it.
Risks and Concerns
The immediate vulnerabilities are being patched, but the architectural pattern is broader than any one advisory. Development ecosystems contain countless mechanisms through which data becomes behavior.The unresolved structural problems
- Patch-by-filename defenses will remain incomplete. Blocking one hook file or configuration directory does not address equivalent execution paths elsewhere.
- Approval fatigue can neutralize warnings. Excessive prompts encourage users to approve actions reflexively.
- Model-based safety checks are nondeterministic. A model may reject a malicious instruction in one context and follow a slightly altered version in another.
- Trusted extensions expand the effective sandbox boundary. Every host-side extension that reads project state can become part of an attack chain.
- Local daemons can bypass filesystem isolation. Access to Docker, credential agents, browsers, or cloud helpers may provide powerful indirect capabilities.
- Delayed execution complicates incident response. The malicious write and resulting process may occur in different sessions.
- Developer credentials increase blast radius. Host execution can become source-code compromise, package tampering, or cloud intrusion without administrator privileges.
What to Watch Next
Pillar’s disclosure is structured as a series of technical deep dives, and further implementation details may sharpen the understanding of each attack chain. Vendors are also likely to revise sandbox boundaries, workspace-trust behavior, command policies, and handling of privileged local services.The most consequential changes will be architectural rather than cosmetic.
Questions vendors now need to answer
Security teams and users should look for concrete answers to the following questions:- What files can the agent create or modify?
- Which unsandboxed components automatically read those files?
- Can any of those components execute commands, plugins, interpreters, or helpers?
- Does the product preserve the origin of agent-generated files?
- Are host-side actions governed by the agent’s sandbox and approval policy?
- Can the sandbox reach Docker, WSL, credential agents, local APIs, or named pipes?
- Are command rules based on names, complete invocations, or actual side effects?
- What logs connect an agent’s write with later host execution?
- Can enterprise administrators enforce settings that a project cannot override?
- Are unfamiliar repositories opened in a genuinely isolated environment?
A new endpoint security category
These findings may accelerate the emergence of agent-aware endpoint controls. Traditional application control focuses on executable files and process launches, while data loss prevention focuses on information movement.Agent security must connect intent, file provenance, policy, and delayed side effects. The critical event may not be a suspicious command from the AI process; it may be an ordinary editor extension executing a file the agent silently changed seconds earlier.
That requires monitoring trust handoffs rather than only process trees. It also requires vendors to expose reliable telemetry so organizations can distinguish human actions from autonomous agent actions performed under the same user account.
The research into Cursor, Codex CLI, Gemini CLI, and Antigravity marks a significant shift in how sandbox security must be understood. The true boundary of an AI coding agent includes every file it can influence and every trusted component that may later act on that influence. Patching the seven reported vulnerabilities is necessary, but the lasting solution will require development tools to treat agent output as untrusted until it crosses an explicit, observable, and enforceable approval boundary.
References
- Primary source: Techzine Global
Published: 2026-07-21T09:27:09+00:00
- Related coverage: cymulate.com
Configuration-Based Sandbox Escape (CBSE) in AI Coding Tools
Critical flaws in AI coding tools allow sandbox bypass, arbitrary code execution, and credential theft.
cymulate.com
- Official source: help.openai.com
Codex Security | OpenAI Help Center
help.openai.com
- Related coverage: pillar.security
The Week of Sandbox Escapes
www.pillar.security
- Official source: deploymentsafety.openai.com
Addendum to GPT-5.2 System Card: GPT-5.2-Codex - OpenAI Deployment Safety Hub
GPT-5.2-Codex is our most advanced agentic coding model yet for complex, real-world software engineering. A version of GPT-5.2 optimized for agentic coding in Codex, it includes further improvements on long-horizon work through context compaction, stronger performance on project-scale tasks like...deploymentsafety.openai.com - Related coverage: labs.cloudsecurityalliance.org
CSA research note gemini cli cvss10 rce sandbox bypass 20260501 csa styled
PDF documentlabs.cloudsecurityalliance.org
