Why Sandboxes Won't Save You From Shadow AI (And What Will)

The short answer

Sandboxing an AI coding agent limits where it runs, not what it is allowed to do. To actually secure these tools, you need to govern the agent's specific actions with enforced hooks, scoped permissions, and logging, at the point of execution rather than at the perimeter of a VM or container.

That distinction matters more than most security teams currently treat it. A sandbox answers "can this process reach my host machine." It does not answer "should this agent be allowed to run this command, touch this file, or call this API." Those are different questions, and 2026 has been the year that gap got expensive.

Sandboxes were built for a different threat

Containers and VMs were designed to contain a process: limit its filesystem, its network, its blast radius if something goes wrong. That model works well against malware and against traditional untrusted code. It was never designed for a tool that reads instructions in natural language, decides on its own what to do next, and then writes new files and configuration as part of doing its job.

Security researchers at Pillar Security spent a week in mid-2026 proving exactly why that mismatch matters. They disclosed seven separate flaws across four widely used AI coding agents, Cursor, OpenAI's Codex CLI, Google's Gemini CLI, and Google's Antigravity.¹ None of the seven broke the sandbox itself. Every one of them worked because the agent stayed inside its box, followed every rule, and simply wrote a file, a hook definition, a modified Git config, a task runner entry, that some other tool outside the sandbox later read and executed without question.¹

As the researchers put it: "the agent did not need to break the sandbox directly. It only had to write something that a trusted component outside the sandbox would later run."¹ One of the findings, a Cursor flaw tracked as CVE-2026-48124 with a CVSS score of 8.5, let a hook configuration file written inside the sandbox run an unsandboxed local command automatically, with no user approval, the moment an agent's turn ended.¹ Another, nicknamed "GitPwned," exploited the fact that Codex CLI's allowlist trusted the command git show by name without checking whether its flags could write files rather than just read them.¹

The researchers' framing is the whole argument in one line: "If an agent gets to write the future inputs of systems, it was never sandboxed in the first place."¹ That is the trust handoff problem. A sandbox governs a process. It does not govern everything that process's output eventually touches: a Git extension, an IDE task runner, a Docker daemon, a CI pipeline.

Why this is a governance problem, not just an engineering one

The technical flaws are fixable one at a time, and several already have been patched.¹ But the pattern behind them is not a bug, it is a structural mismatch between how these tools are deployed and how they actually behave. An autonomous coding agent doesn't run one command and stop. It runs a session: reads files, decides on a plan, executes a sequence of shell commands, writes new files, and repeats, often for minutes at a time with minimal human review of each step.

That is precisely the behavior traditional shadow IT policy was never built to see. Most companies still think about unsanctioned software as an employee installing an app or subscribing to a SaaS tool without approval. Shadow AI is now largely a different animal: a developer pointing an agent at a repository with elevated permissions, and the agent making dozens of autonomous execution decisions inside a session that IT never reviewed and cannot fully reconstruct afterward.

The scale is not marginal. Okta found only 47% of companies surveyed said they knew all the AI agents running on their networks.² Microsoft's 2025 Work Trend Index found 78% of AI users at work are bringing their own AI tools outside IT approval.³ And the cost of that gap is measurable: IBM's 2025 Cost of a Data Breach Report found organizations with high levels of shadow AI faced breaches that cost $670,000 more, on average, than organizations with low or no shadow AI usage.⁴ One in five organizations studied had a breach involving shadow AI at all.⁴

For coding agents specifically, the risk compounds. A shadow SaaS subscription might leak a customer list. A shadow coding agent with shell access can rewrite your CI pipeline, commit a credential to a config file, or hand execution privileges to something entirely outside the box you thought you'd contained it in.

What hooks actually are, and why they're the real control point

The fix that keeps surfacing across vendor documentation and security research alike is not a stronger sandbox. It's a hook: a deterministic, mandatory checkpoint that runs at a specific point in an agent's lifecycle and decides, based on rules your team wrote, whether an action is allowed to proceed.

Claude Code's own documentation describes this precisely: hooks are user-defined shell commands, HTTP endpoints, or scripts that execute automatically at fixed points in an agent's session, before a tool runs, before a file is edited, before a command is executed, and they can block, approve, or modify what happens next.⁵ Unlike a system prompt or a policy document the model might interpret loosely, a hook is code. It runs every time, with no ambiguity about whether the agent "remembered" the rule.

That is the meaningful shift from sandboxing to governance. A sandbox says: whatever happens, contain the damage to this box. A hook says: before this specific action happens, check it against a rule, and stop it if it fails. The Pillar research shows why the second approach catches things the first one misses: several of the flaws they found involved the agent writing a hook or task definition file inside the sandbox that was then trusted and executed by something outside it.¹ A poorly designed hook can itself become the exploit. A well designed one, reviewed the same way you'd review agent-authored source code, is the closest thing to a real control point these tools currently have.

Practically, that means:

• Command allowlists that check arguments, not just names. The GitPwned flaw worked because git show was trusted by name, ignoring that a flag could make it write files.¹ Any hook or permission rule your team writes needs to model the full argument surface of a command, not just its label.
• Treat agent-authored configuration files as untrusted, always. A hook definition, a .vscode task, a Git config entry: if an agent wrote it during a session, it needs the same review a human's pull request would get before anything trusts it.¹
• Log the handoff, not just the sandbox. None of the vendor advisories reviewed in the Pillar research described an alert firing when an unsandboxed component consumed an agent-written file.¹ That is the audit gap most teams currently have. Logging needs to cover what happens after the agent's output leaves the sandbox, not just what happens inside it.
• Restrict what daemons and sockets the agent can reach. Several of the disclosed flaws routed through a shared Docker socket, letting a sandboxed agent launch a privileged container and sidestep the sandbox entirely.¹ If an agent's environment has access to a daemon with more authority than the agent itself, the sandbox boundary is mostly decorative.

None of this replaces the isolation layer. Sandboxes still matter as a first line of defense; you want the blast radius contained even when a hook fails. But treating the sandbox as the control, rather than the containment, is the mistake most organizations are currently making. It's the same mistake covered in our earlier piece on securing AI-generated code: the risk isn't that the model is malicious, it's that nobody defined, in advance, what it's actually allowed to do.

The governance mandate

If your organization has employees running Claude Code, Cursor, Codex CLI, or similar agents against real repositories, the honest question isn't whether to allow it. Adoption is already near-universal among engineering teams, and banning it outright mostly just pushes it further into the shadows.³ The question is whether anyone has defined, in code, what these agents are permitted to execute, and whether that definition is enforced every time or just suggested in a policy doc nobody reads during a live session.

Companies that treat coding agents as software they own and operate, with hooks, allowlists, and logging built in from day one, are the ones who will avoid becoming the next line item in a breach cost report. Companies that treat a sandbox as the whole answer are, based on the last several months of disclosed research, going to keep discovering the gap the hard way. If your team is weighing whether to build that governance layer in-house or route it through an agent orchestration platform, tools like Remy are built around exactly this idea: treating agent permissions and hooks as first-class, auditable infrastructure rather than an afterthought bolted onto a sandbox.

The tools aren't going away. The organizations that get this right are the ones that stop asking "is it contained" and start asking "is it allowed."