| Blog | Endor Labs

What it claims

Model-level guardrails and approval prompts cannot be the control against a hijacked coding agent. The working assumption should be that the agent will be talked into something hostile, and the question is what the host still permits once it has been. The page defines a sandbox strictly: tool calls run under constraints that are enforced below the agent (usually by the kernel) and that the agent cannot edit from inside. A policy file the agent can read and modify is not a sandbox.

How it works

The page ranks the options from weakest to strongest and gives the trade-off for each:

1. No sandbox. The agent runs with the developer's full user rights. The page says this is where most installs sit today.
2. Approval prompts. These fail under volume. By the fortieth prompt in an hour, approving takes a click and careful review does not, so the boundary is weakest when the agent is busiest.
3. OS-level enforcement. Policy covers the whole subprocess tree that a command spawns, not only the command itself. Cursor evaluated App Sandbox, containers, VMs and Seatbelt. It rejected the alternatives because they required signing every binary the agent might run or added startup latency.
4. Containers. These give a separate filesystem root. In practice the boundary gets perforated as soon as you mount the project, forward git credentials and pass through the SSH agent. Containers also share the host kernel, so a kernel bug collapses the boundary.
5. VMs and microVMs (gVisor, Firecracker). These close the kernel gap at a cost in startup time and memory. That may be fine in CI but not on a laptop. Mounted credentials are still exposed.

Filesystem and network isolation only work together:

flowchart TD
  A[Compromised agent] --> F{Filesystem locked?}
  F -- no --> W[Write shell rc / hook] --> X[Payload runs outside sandbox]
  F -- yes --> N{Egress locked?}
  N -- no --> P[Read allowed files, POST out]
  N -- yes --> C[Contained: now a config question]

Even with both locked, filesystem isolation does not stop lateral movement through legitimate credentials. For example, it can block deleting a file on disk but not a gh api call that deletes the branch.

Evidence

The page's evidence is the nx incident (August 2025):

• No agent vulnerability was exploited. The malware invoked three agent CLIs as documented, with the guardrail flags switched off.
• Exfiltration needed no attacker infrastructure. Results were base64-encoded and committed to a public repo in the victim's own GitHub account, so no command-and-control server was needed.
• Over 1,400 such repos were publicly searchable at peak before GitHub removed them.
• A second wave followed. Harvested tokens were used to rename private repos and force them public.

The page also states that almost every documented agent sandbox escape so far has come from allowlist hygiene or configuration logic, not sophisticated exploits. It gives no list or count for this claim.

How to use it

The page offers three audit questions for any agent running in your org:

• What enforces the isolation? If nothing does, it is configuration, not a sandbox.
• What is inside the boundary? Cloud credentials or an SSH agent in the workspace undo the wall.
• Who can change it? If the developer can switch it off, it is a default, not a control.

Limits

This is a vendor blog post with no benchmarks or measurements beyond the nx figures. The incident payload analysis (prompt and flag mapping) is referenced but not included on this page. The post does not name specific escapes behind the configuration claim. No setup commands or configuration examples are given.