AI Coding Agent Security in 2026: Sandbox Rules
AI coding agent security 2026 guide with sandbox rules, approval settings, and safe workflows after Cursor, Codex, Gemini CLI, and Antigravity escapes.
AI coding agent security 2026 is now a practical engineering problem, not a theoretical risk. Recent sandbox escape reports across Cursor, Codex, Gemini CLI, and Antigravity showed a pattern that every developer should understand: the agent can stay inside the sandbox, write a normal project file, and still cause host-side execution later when a trusted local tool reads that file.
Use AI agents, but treat their file writes as security-sensitive output. A sandbox helps, yet it does not make generated config, package scripts, hooks, Docker files, or CI changes automatically safe.
- Let agents read and edit normal application files.
- Require approval before shell, network, Docker, dependency, migration, CI, and deploy actions.
- Review files that another host tool can run or load.
AI coding agent security 2026 starts with writable files
Most developers picture sandbox escape as a process breaking a container or abusing an operating system bug. That is still possible, but the more relevant agent pattern is simpler. The model reads untrusted text, follows hidden instructions in that text, and writes a file that another tool trusts later.
A poisoned README can tell the model to edit a task file. A dependency description can suggest a package script. A pull request comment can pretend to be a project rule. The model may interpret that as useful context, then create a change that looks normal in a busy review.
The risky files are not rare. They are the files every real repo already has: package scripts, workflow files, editor tasks, dev container settings, Docker configuration, Git hooks, shell scripts, test runner plugins, MCP server definitions, and database migrations. They are text, but many of them are executable instructions waiting for another tool.
That is why a sandbox scoped to the project folder is only one layer. If the host outside the sandbox later runs something from that folder, the review boundary moved from process isolation to file trust.
What changed after the July 2026 reports
BleepingComputer reported on July 20, 2026 that Pillar Security researchers reproduced sandbox escape paths across Cursor, OpenAI Codex, Google Gemini CLI, and Antigravity. The important detail is that the escapes did not require attacking the sandbox directly. The agent could remain constrained, while host components later acted on files it wrote.
The reported issues touched several failure modes: workspace config that behaves like code, command allowlists that trust a command name more than its arguments, Git metadata tricks, IDE behavior, and privileged local daemons such as Docker. Some fixes were already shipped by vendors, including Cursor 3.0.0 and Codex CLI 0.95.0. That is good, but it does not remove the broader class.
The takeaway is not that one tool is unsafe and another is safe. The takeaway is that agent safety must include the repo, the editor, local services, and the review process around generated files.
How the main AI coding tools handle the boundary
| Tool class | Safer starting point | Stronger mode | Main risk to watch |
|---|---|---|---|
| Codex CLI | Suggest for unfamiliar repos | Auto Edit with command approval | Full Auto can run commands inside a sandbox, so review writable config and shell paths. |
| Claude Code | Read-only permissions first | Sandboxed bash with explicit filesystem and network rules | Over-broad permission rules and hooks that run commands too freely. |
| Gemini CLI | Sandbox on before shell tasks | Docker, Podman, or runsc sandbox | Network access, host mounts, and Docker socket exposure. |
| Cursor and IDE agents | Workspace trust plus manual review | Automatic edits only in trusted repos | IDE extensions can load workspace config outside the agent sandbox. |
| Experimental agents | Read-only or throwaway repo | External isolation only | Unknown interactions with host tools, plugins, and local daemons. |
OpenAI documents Codex CLI with Suggest, Auto Edit, and Full Auto modes. Suggest reads files and proposes edits. Auto Edit can write files but still asks before shell commands. Full Auto can read, write, and execute commands inside a sandboxed, network-disabled environment scoped to the current directory.
Anthropic documents Claude Code as permission based, with read-only behavior by default, explicit approval for edits and commands, write access limited under the start folder, and sandboxed bash support. Its sandboxing docs describe filesystem and network isolation as complementary to permissions.
Google documents Gemini CLI sandboxing through a command flag, environment variable, or settings file. It supports Docker, Podman, macOS sandbox-exec, runsc, and LXC. Its configuration also allows extra sandbox paths and network access controls.
The workflow I would use on a client repo
For a client repo, I would not start with full autonomy. I would start with scoped autonomy. The goal is to let the agent save time on implementation while keeping command execution and sensitive files under human control.
This protects against a common failure: the agent creates a file that your host tool later trusts. A disposable worktree also makes cleanup simple. If anything looks suspicious, delete the worktree and start again from a clean branch.
Files that deserve manual review
Agents can edit these files, but these edits should not be approved casually. They can control commands, network calls, deployments, credentials, or local execution.
| File or folder | Why it matters | Review action |
|---|---|---|
| package.json | Scripts can run during install, test, build, and deploy. | Read every changed script and dependency. |
| Lockfiles | A version change can pull new code into the project. | Check package source and install behavior. |
| .github/workflows | CI can access tokens, artifacts, and deployment targets. | Confirm no secret exposure or production action. |
| .vscode and editor config | Tasks and settings can affect local IDE behavior. | Review before opening the repo as trusted. |
| .devcontainer and Docker files | Container setup can mount host paths or run setup scripts. | Inspect mounts, sockets, build steps, and network use. |
| scripts and hooks | Shell scripts and Git hooks often run with broad local permission. | Read arguments, paths, and environment access. |
| MCP config | MCP servers can expose tools and external systems. | Approve servers like production access, not editor decoration. |
| Database migrations | Generated SQL can be destructive while looking routine. | Run against test data first and review rollback paths. |
Approval rules that work without slowing everyone down
A strict prompt for every action causes fatigue. A broad always-allow rule creates a hole. The practical middle is a small allowlist that everyone understands.
Good automatic approvals
- Read-only commands such as git status, git diff, and rg.
- Formatters already pinned in the repo.
- Type checks that do not need network access.
- Local test commands in a trusted repo.
- Build commands that only write normal caches.
Keep manual approval
- curl or wget piped to shell.
- Package installs on untrusted branches.
- Docker commands with host mounts or socket access.
- Commands that touch SSH, cloud, or payment credentials.
- Deploy scripts and database migrations.
If an allowlist rule is hard to explain in one sentence, it probably should not be automatic. That keeps routine work fast and risky work visible.
How to configure common agents safely
Codex CLI
Start unfamiliar repos in Suggest mode. Move to Auto Edit when you trust the branch and want file patches. Save Full Auto for disposable worktrees, generated projects, or well-contained tasks where command execution is acceptable. Full Auto being sandboxed and network-disabled is useful, but it does not remove the file handoff problem.
Claude Code
Use the permission model instead of skipping prompts. Keep the default posture for unknown repos, then add a narrow set of safe commands per project. Sandboxed bash helps because filesystem and network rules are enforced outside model judgment. Hooks can be useful for logging and checks, but hook files deserve review because they run deterministic automation.
Gemini CLI
Enable sandboxing before giving it write and shell tasks. For common development, Docker or Podman is practical. On Linux, runsc gives stronger isolation when the team can support it. Keep sandbox network access off unless the task explicitly needs it, and avoid exposing the host Docker socket unless you understand the tradeoff.
Cursor and IDE agents
Treat the IDE as part of the risk surface. The agent may be boxed, but extensions and editor services can read workspace files outside that boundary. Use workspace trust, inspect task files, and be careful with Python interpreter discovery, Git integration, and project settings.
Related RightKod reading
If you are choosing an agent interface, compare this guide with Cursor vs VS Code for AI Coding in 2026. If you want a broader setup recommendation, read The Best AI Coding Setup in 2026. Teams comparing coding assistants can also read GitHub Copilot vs Gemini Code Assist 2026.
Verdict
The safest AI coding agent setup in 2026 is not one product. It is a workflow: disposable workspace, no secrets by default, sandboxed command execution, limited network access, and manual review for files that other tools execute.
If you need one professional default, use this: allow read and normal source edits, but require approval before commands and before changes to executable config. That gives most of the productivity benefit while closing the simplest path from prompt injection to host execution.
Frequently asked questions
Is an AI coding agent sandbox enough by itself?
No. A sandbox helps, but it does not solve the file handoff problem. If the agent can write a file that a host IDE, package manager, hook runner, or Docker daemon later trusts, the risk moves outside the sandbox.
Should I let an AI agent run npm install?
Only in a trusted repo or isolated environment. Package installs can run lifecycle scripts and download new code. For unfamiliar repos, inspect dependency changes first and run installs in a container or disposable worktree.
Which is safer: Codex, Claude Code, Gemini CLI, or Cursor?
The safer option is the one configured with tighter permissions for your task. Codex, Claude Code, Gemini CLI, and IDE agents all have useful controls, but none remove the need to review executable files, network access, and host tool interactions.
How should teams handle secrets with AI coding agents?
Keep real secrets out of agent workspaces by default. Use fake values, local-only test credentials, or secret managers with narrow scoped access. Never let an agent read SSH keys, production API tokens, or cloud admin credentials without a specific approved reason.
What should an admin log for agent usage?
Log the task summary, files changed, commands approved, tools used, and final diff. For MCP or cloud integrations, log which external systems were reachable. That gives reviewers enough context to audit risky changes without reading a full chat transcript.
