Why agentic security needs its own threat model
Executive Summary #
Over several months, Pillar Research found and reproduced sandbox escapes and boundary bypasses across Cursor, Codex, Gemini CLI, and Antigravity. In almost every case, 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, load, scan, or treat as safe. In aggregate, these vulnerabilities show that AI coding agents change the endpoint threat model, and that most sandbox designs have not caught up.
We are releasing the research as The Week of Sandbox Escapes: one deep-dive a day, each showing a different route across the boundary. The findings cluster into four repeatable failure modes:
- Denylist sandboxes that cannot keep pace with OS complexity
- Workspace configurations that are really executable code
- "Safe" command allowlists that trust command names instead of invocations
- Privileged local daemons that sit outside the sandbox entirely
The bottom line is that an agent's blast radius is not the agent process; it includes everything the agent can write that the host later trusts.
The productivity gains of agents are real, and developers are already using them. The problem is that these tools became infrastructure before most organizations governed them as infrastructure.
CISOs and security buyers need to realize that it's not enough for an agentic IDE or CLI to have a sandbox. It needs to prove where the sandbox boundary actually is, what the agent can write, which host components trust those writes, which local daemons it can reach, which commands skip approval, and what telemetry exists when a trusted helper executes something the agent influenced.
Agentic tools are becoming endpoint actors. They need to be assessed, monitored, and governed like endpoint actors.
Pillar’s Approach #
At Pillar, we look at AI adoption through the lens of enterprise risk.
Agentic coding tools are a natural place to start because they concentrate endpoint risk in one workflow. They run where source code, SSH keys, cloud tokens, browser sessions, package-publishing rights, and production access often live close together. They process untrusted input as a matter of routine: READMEs, issues, docs, dependencies, code comments, diffs, logs, and web content. They are built to act, not just answer.
Put that together, and prompt injection stops being a chatbot problem. A malicious instruction can become a local action on a developer machine.
Most products address that risk with sandboxes, approval prompts, and safe-command policies, but those controls often focus on the agent process alone. The agent's power also includes the files it can write and the host components that later trust those files.
How Agents Escape Their Sandboxes #
The general rule of thumb for sandboxes is that inside the workspace is allowed, and outside the workspace is protected.
In practice, sandbox boundaries have at least three layers:
Direct execution: what the agent process can run.Workspace writes: what files the agent can create or change.Host trust: what unsandboxed components later do with those files.
The third layer is where the most interesting failures live. Modern IDEs and CLIs are full of host-side automation:
- Python extensions discover interpreters
- Git integrations scan repositories
- VSCode task runners load project tasks.
- Hook engines fire lifecycle commands
- Docker Desktop exposes a powerful local socket
A sandboxed agent can follow every rule it is given and still shape the inputs those components consume.
That is the imaginary or perceived boundary: believing "the agent can only write inside the project" is the same as "the agent cannot affect the host."
But that is an incorrect assumption. On developer endpoints, project files are often executable infrastructure.
The Series #
Each post goes deep on one chain. Together, they show the same failure pattern repeating across vendors and products.
Failure Mode 1: Denylists Lose To Platform Complexity #
The Antigravity Seatbelt finding is the cleanest example of a denylist failure. A sandbox profile that starts from "allow by default" has to remember every dangerous operation the OS exposes: every local service, mount type, launch path, and strange interaction between them.
That is not a sandbox, it’s a list of things somebody remembered to block that’s always one entry short.
Agents make that worse because the attacker gets a flexible operator inside the environment. The model can adapt, write files, run commands, retry, and combine features in ways a static policy did not anticipate.
Failure Mode 2: Workspace Config Is Often Code #
Several findings were not classic process breakouts. The agent wrote files it was allowed to write. The escape happened later, when the host treated those files as trusted configuration.
We saw this with “A time bomb in .vscode: bypassing Antigravity's Secure Mode”, and the “The hook was already in the workspace” vulnerabilities, virtualenv interpreters, Git config, and fsmonitor helpers.
It’s important to note that these are all normal developer workflows. For years, project configuration has told machines how to build, test, launch, lint, and automate a repo.** When a sandboxed writer can hand executable config to an unsandboxed reader, the boundary has a hole in it. **
Agents break the old assumption that these configurations are written by humans and reviewed in the usual way. The sooner developers adapt to that reality, the better.
Failure Mode 3: "Safe" Commands Are Not Safe By Name #
The Codex git show finding was allowed because the name looked read-only. The actual invocation was not.
Git is full of flags that change behavior. A command can look harmless and still write files, load config, call helpers, run hooks, or trigger user-defined behavior. In that world, allowlisting by command name is too blunt.
The policy question is not "is git show safe?" It is: what exact invocation is being run, with what arguments, in what directory, against what config, and with what possible side effects?
Failure Mode 4: Local Daemons Live Outside The Box #
The Docker socket finding is the reminder that sandboxing the agent process does not sandbox the host.
A privileged local daemon is a second execution environment. If the agent can talk to it, the daemon can do work the agent itself is not allowed to do. Developer endpoints often run Docker Desktop, package managers, cloud CLIs, language servers, build daemons, emulators, and local databases. Any one of them can become a trust bridge.
A sandbox that blocks direct filesystem writes but leaves open a daemon with host reach has not protected the host. It moves the boundary to the daemon API.
What Security Teams Should Ask Coding Vendors #
The buying conversation should not stop at "does it have a sandbox?" For agentic systems, mandatory questions include:
- What can the agent write?
- Which host components trust those writes?
- Which local daemons can the agent reach?
- Which commands skip approval, and why?
- Is policy enforced on command names, paths, or actual side effects?
- Can the product distinguish user-created project state from agent-created project state?
- What telemetry fires when a trusted helper runs something the agent wrote?
These questions separate a sandbox listed as a checkbox feature in a marketing deck from one that provides an enforceable boundary for securing agentic processes on the host.
Pillar's Approach #
Our approach starts with agentic threat modeling. Something sends the agent untrusted input, the agent produces output, and other components consume the output and act on it. Most of the other components in the system were built before agents existed. If a control only watches the agent process, it is only securing one link of that chain. So we ask these questions of any agentic system:
- What untrusted input can reach the model?
- What can the model do directly?
- What can the agent write?
- Which components read those writes?
- Which of them execute code outside the agent's policy?
- Which controls are deterministic, and which depend on model behavior?
- Where can an agent-created artifact become a host action?
When it comes to how we model endpoints, we approach it as a set of trust handoffs, not a single process tree. Agents hand work off to systems that trust them in CI, in browsers, in SaaS workflows, and on developer machines.
We built our endpoint solution by focusing on places where that handoff has no chokepoint. In CI, a build step that consumes agent output runs somewhere you can log. In SaaS, the handoff crosses an API you already have in front of. On a developer machine, the agent writes a file and a privileged local process picks it up microseconds later, in the same user session, with no network hop and nothing watching the seam. The handoff is invisible by default.
That is what our endpoint product instruments: the seam. Not the agent process, not a list of dangerous filenames. Provenance on what the agent wrote, visibility into which unsandboxed component read it, and a record when execution follows.
Every escape in this series produces that sequence. None of them required us to know in advance that fsmonitor was interesting.
What A Good Threat Model For Agents Looks Like #
Agentic endpoints require a layered threat model. The relevant controls belong across all levels of an organization's defense: in vendor products, enterprise policy, and the endpoint security layers around the tools: Start from deny-by-default wherever sandboxing is used and then:
- Treat workspace configuration that can trigger execution as sensitive
- Require explicit approval when an agent creates or modifies host-side automation
- Run helper execution under the same policy as direct agent execution where possible
- Constrain automatic discovery that executes workspace-controlled binaries
- Model command policy at the invocation and side-effect level
- Restrict access to privileged local daemons unless explicitly needed
- Preserve provenance between user-created, repo-created, and agent-created files
- Monitor trust handoffs, not just the agent process
It’s essential to understand that agentic development is a new endpoint behavior, not just a nicer or newer IDE.
Our** Week of Sandbox Escapes** is a story about a new kind of software breaking an existing assumption - sandboxing your agent is not enough. We need to better understand the threat models of non deterministic, agentic software, and secure them properly.
Developer endpoints were already complicated. Agents add actors that read untrusted content, write plausible-looking files, and trigger automation inside the same environment that holds code, credentials, infrastructure access, and release paths.
This research highlights that when it comes to agents, the sandbox boundary that developers expect in coding tools -- one that keeps the agent inside the sandbox and the user outside -- breaks down. The boundary we kept finding was both messier and porous, because If an agent gets to write the future inputs of systems, it was never sandboxed in the first place.
**This is why agentic security requires its own threat model. **
Combine the non-deterministic nature of agents with the complexity of modern IT environments and there will be thousands more to come. The industry is learning as we go, which is why it's so important to share what we learn and help enterprises recognize and mitigate the risks when moving quickly to deploy agentic systems.
Subscribe and get the latest security updates
Back to blog