Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Can a Coding Agent Escape Its Sandbox?

Rarely through the wall: the sandbox in a coding agent is documented as covering shell commands, while the file tools, MCP servers, hooks and web fetches run outside it. Ask what runs outside before asking how strong the wall is.

A credential reference travels from a browser record through a bounded route to a separate API destination.

Security and platform teams that approve a coding agent usually sign off on its sandbox, and that sign-off is often tested against the wrong thing. The question people ask is whether a determined process can break out of a container, and that question belongs to microVM design, seccomp filters and host kernel patches. The question that decides what a coding agent reaches on an ordinary working day is narrower: which parts of its work never entered the sandbox at all. Anthropic's documentation separates the sandbox from the permission rules, and the list of what follows a permission rule is longer than the list of what the sandbox holds. A team that reads only the sandbox section of a vendor's page will conclude that the agent is contained; a team that reads the permissions page beside it will find the routes that leave. This page follows the order a review would: what the sandbox covers, how the harder boundary is built, what the vendors document about their own limits, one record type (an MCP server that holds a credential outside the sandbox), and the control that changes what a run can read before the model acts. Reviewers should keep the two questions apart, because the value that ends up in a transcript rarely arrives through a broken hypervisor.

Key findings

  • Anthropic's security page describes the sandbox as covering shell commands, then states the limit in its own words: "The boundary is a permission prompt, so a Bash command you approve can still write anywhere your user account can" (Anthropic, Security, 2026).
  • gVisor's security model states that "No system call is passed through directly to the host," which is what makes a user-space kernel a harder boundary than a shared container runtime (gVisor, 2026).
  • A study of prompt injection against agentic coding editors reports that "attack success rates can reach as high as 84% for executing malicious commands," so the command channel is exercised even when no container is breached (Liu et al., Your, 2026).
  • The benchmark paper for prompt injection runs "5 prompt injection attacks and 10 defenses with 10 LLMs and 7 tasks," and its abstract reports no result figures, so the record establishes a method rather than a winner (Liu et al., Formalizing, 2024).
  • A governed environment replaces a value chosen by policy with a consistent token before any model reads the screen, so an agent composing a repository settings page works with HOOK_002 and never holds the signing secret (What Is Least Exposure?).
  • Real values resolve only at the approved destination at the moment of an approved action, which keeps the signing key out of the transcript even on a page that echoes the field (What Is Least Exposure?).

What does a coding agent's sandbox cover, and what runs outside it?

Anthropic's security page is the place to start, because it draws the line itself: "Sandbox bash commands with filesystem and network isolation, reducing permission prompts while maintaining security" (Anthropic, Security, 2026). The sentence is precise about the unit. The sandbox holds the command, not the session.

The permissions page separates the layers. To block a file, a team adds "a Read deny rule for its path, such as Read(./.env) or Read(./secrets/**)"; a .claudeignore file "has no effect," and the rules "don't apply to a command that reads files without naming them, such as grep -r pattern . run from the directory that holds the file" (Anthropic, Configure, 2026).

Two things follow. The deny rules apply to the built-in file tools, and the page points to the sandbox for enforcement that covers every process, which is a vendor saying which layer is a boundary and which is a policy. The second is that a review has to ask for the list of tools that follow a permission rule, not for the settings that happen to be present.

The scope of a browser control is narrower again. A governed browser environment covers what an agent reads and does on a rendered page, meaning dashboards, consoles, settings pages and sign-up forms, and does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A coding agent spends much of its day in the first list and most of its authority in the second.

A traffic layer is not a wall around a process either. RedactSure vs Databricks: 2026 Comparison & Alternative records Databricks describing Unity Gateway as "the Databricks governance solution for enterprise AI," which governs traffic between models, agents, MCP servers and tools once routed through it, and traffic that is not routed through it is not governed.

Is the wall itself the weak point?

The Firecracker design document builds its isolation from "multiple layers," and states that "All egress traffic from a guest is therefore considered untrusted, and should be filtered at the host-level" (Firecracker, 2026). The second sentence matters: the guest is assumed hostile, and the host decides what leaves it.

gVisor states the dependence plainly, that it "relies on the host operating system and the platform for defense against hardware-based attacks," and closes the page with "A sandbox is not a substitute for a secure architecture" (gVisor, 2026). A boundary that depends on the host is not a control over what a process reads.

The research record measures what a hijacked agent does with the commands it is allowed to run, not a broken hypervisor. Progent's authors report that privilege control "significantly reduces attack success rates while maintaining high utility," and their abstract gives no numbers, so the finding shows a direction rather than a size (Shi et al., 2026). The design idea is that authority narrows per step, so a command that should never have been issued reaches less.

That is the right reading of the wall. A microVM is the harder boundary, and an agent inside one is still capable, because the tether is "a description of authority, not of capability" (What Is a Tethered Agent?). The wall is not the weak point. The weak point is what never stood behind it.

What do the vendors themselves say?

Anthropic documents the credential design for its hosted sessions, and the limit beside it: "GitHub credentials are stored encrypted on Anthropic's servers and never enter the session VM," and the VM holds "a short-lived credential scoped to that session" (Anthropic, Security, 2026). That custody is described for Anthropic-hosted cloud sessions and not for a local session, so a team running the agent on its own machines cannot read it as a promise about its own disk. The same page closes with a sentence that applies to every wall: "While these protections significantly reduce risk, no system is completely immune to all attacks."

The permissions page points to the sandbox for the enforcement a rule cannot give: "For OS-level enforcement that blocks all processes from accessing a path," it says, enable the sandbox (Anthropic, Configure, 2026). Read together, the two pages put policy in one layer and the boundary in another, and they say which is which.

The two isolation projects document their own boundary with more care than most. Firecracker describes isolation in layers and treats every guest as untrusted at the host; gVisor describes a user-space kernel that passes no system call through to the host. What none of the four pages describes is a mechanism that decides which fields a model receives once a page is open, which is the decision a buyer is left to make.

Dimension Anthropic, Claude Code, per its documentation gVisor and Firecracker, per their documentation What a buyer should verify
What the boundary holds Bash commands, with filesystem and network isolation A user-space kernel for the guest; a microVM guest with its own kernel Which work runs inside the boundary and which does not
What sits outside it File tools on permission rules; a deny rule covers the built-in file tools and recognized commands that name a file Not addressed, since the boundary is the guest The list in writing, for the tools the team actually uses
Credential custody GitHub credentials encrypted on Anthropic's servers, short-lived and scoped, for hosted sessions Not described inside the guest Custody for a local session and for each MCP server
Stated limit The boundary is a permission prompt; no system is completely immune A sandbox is not a substitute for a secure architecture Who owns the residual risk the vendor names
Approver Not named for a tool call Not named for a guest A person, by role, for each consequential action

What is the practical route out of a coding sandbox?

The record for this page is an MCP server that holds a credential outside the sandbox. It is a process the agent starts in the workspace, carrying a token issued to a repository service so it can read webhooks and deploy keys. The sandbox holds the agent's commands; the server runs beside them, token in its own environment.

The specification warns implementers that "MCP servers run with the same privileges as the client," and states that "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server" (Model Context Protocol, 2026). The same page warns that "Poor scope design increases token compromise impact, elevates user friction, and obscures audit trails," the failure mode of a token issued for every repository (Model Context Protocol, 2026).

The sequence is short. The agent asks for the webhook list, the server returns it with the signing secret in the payload, and no command in the sandbox opened a file. The wall held, and the value crossed it anyway.

The same shape appears in durable credentials a team hands over so an agent can work: a super admin account, used only when needed, as Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool? sets out; root access keys, which Is It Safe to Let an AI Agent Set Up Your Cloud Environment? advises against for the root user; and a pipeline that authenticates by OIDC rather than a stored credential (How to Set Up S3 and GitHub With Cowork or Dots). Each is outside the sandbox by construction, and each outlives the run that used it.

What still sits outside a stronger wall?

The reading is the payload. TruffleHog's scan of web data found "11,908 Live Secrets," and "2.76 Million Web Pages contained live secrets" (Truffle Security, 2025). The post does not establish that a model trained on them, and the point does not depend on it: a page an agent reads can hold a live key either way.

Verizon's report points the same way: "of breaches now start with software vulnerabilities, beating stolen passwords as the top way attackers get in," and "Hackers are shifting their focus from tricking people to exploiting systems" (Verizon, 2026); the page shows a 31% figure for software vulnerabilities. Exploitation is the measured route in, which argues for the microVM, and the read is what decides the loss.

Three layers above the sandbox repeat the pattern. A browser agent brings its own session: the help center behind Does Claude in Chrome Use Your Saved Logins and Open Sessions? describes an agent that sees what is on the page and acts on it, defaults to an automatically approve mode that pauses when needed, and can request logins from 1Password, while use of sessions already open in the browser is not described in the pages reviewed. A tool platform federates the calls: Arcade's product page lists "8,000+ agent-optimized tools across 80+ toolkits," with MCP servers federated "into a single endpoint" (RedactSure vs Arcade: 2026 Comparison & Alternative), which governs the call and not the page it was made from.

The wall bounds where a stolen key can go, and it does not decide whether the key was ever in front of the model.

What does a governed environment change?

A governed environment is a control class that acts at the point a page is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so a model composing a repository settings page works with HOOK_002, KEY_003 and ORG_007 rather than the signing secret, the deploy key and the account name. Real values resolve only at the approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves every consequential action. Every screen as tokens, every action and every approval, is written to a record that exports to the organization's own monitoring.

For this page's question, the change is where the boundary sits. A sandbox bounds what a process may do and where it may send data; a microVM makes that bound harder to cross. Neither decides what the model was shown, and the route that matters in practice is the value that reached the model through a page, a tool response or a server that was never behind the wall. The governed environment does not replace the sandbox. It covers the surface the sandbox was never asked to cover, and it leaves a record of what that surface showed.

Its reach stops at the page. The terminal, the IDE, the local filesystem, direct API calls and MCP remain the territory of the sandbox, the permission rule, the scoped token and the review that reads them. That division is the point: a team that knows which control owns which surface stops asking a container to do a job it was never designed for.

Methodology and limitations

This page rests on three preprints about agent privilege and prompt injection, vendor documentation from Anthropic, gVisor and Firecracker, the Model Context Protocol security guidance, one vendor research post and one industry breach report, plus the RedactSure research pages cited in the body. Vendor pages were read as of October 20, 2026, and each Sources line carries the date for its page. Quotations are the vendor's wording, cited to the page that states them, and each recorded fact is used only for the fact recorded for it. Figures from vendor research are cited as reported and not as independently measured.

RedactSure did not test any of the named products hands-on, and this page describes no escape that anyone performed. Where a page reviewed does not address a point, the page says so instead of treating silence as a denial; that is what "not described in the pages reviewed" means here. Vendor features change, and the page carries its date, so a release after October 20, 2026 is unreviewed until the check is repeated. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, an MCP server holding a credential outside a coding agent's sandbox, and not an organization.

Determinations about whether a boundary meets a contractual, regulatory or certification requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test of the organization's own agent, run against its own settings page, with the transcript kept. A vendor's silence on a mechanism is a question to put in writing, not a finding about the product.

What the record shows

The record answers the title in two parts. The vendors document the harder boundary: a microVM that treats its guest as untrusted, or a user-space kernel that passes no system call through to the host. What the pages reviewed do not record is a coding agent that escaped one. What they do record is a boundary drawn around commands, with file tools, MCP servers, hooks and web fetches outside it, and a measured attack success rate of 84% for executing malicious commands once an agent is persuaded. The practical escape is therefore the surface the wall never enclosed, and the control that matters is the one that decides what the model reads before it acts; RedactSure builds that control at the render layer. A security lead can test this on one named agent and one task: list every tool, server and page it can reach that the sandbox does not hold, and ask of each what value it can put in front of the model.

Frequently asked questions

Can a coding agent escape its sandbox?

Through the boundary, rarely, and none of the pages reviewed records it happening. Through the tools beside it, routinely: file tools work on permission rules, and a server holding its own token returns values the sandbox never saw. The useful question is which parts of a run the sandbox does not cover, and the answer is a list a team can write. Start that list with every server the agent can call. The wall is the smaller half of the question.

Which parts of a coding agent run outside the sandbox?

By Anthropic's account, the sandbox covers Bash commands. The file tools follow permission rules instead, and a deny rule applies to the built-in file tools and to recognized commands that name a file. The documentation also says a deny rule does not apply to a command that reads files without naming them, so a recursive search from the right directory can still surface a value. Ask for the list rather than inferring it. A rule about a tool is not a rule about a script.

Is a microVM enough to contain a coding agent?

It is the harder boundary of the two patterns reviewed here: a guest with its own kernel and egress filtered at the host, or a user-space kernel that passes no system call through. Both pages also state a limit. Firecracker assumes every guest is hostile, and gVisor says a sandbox is not a substitute for a secure architecture. A microVM does not decide which values the model was shown before it acted inside the wall. That is a question for the page.

What can an MCP server do that the sandbox cannot stop?

Run beside the agent with the client's own privileges, hold a token issued to it, and return whatever that token can read. Nothing in the sandbox governs that response, because the server was never inside it. The specification tells implementers to warn users that servers carry the client's privileges, forbids accepting tokens not issued for the server, and warns that poor scope design raises the impact of a compromise. Scope each server's token to one repository and one operation.

Does an escape need a kernel exploit?

No. The measured route is the command itself. A study of agentic coding editors reports attack success rates as high as 84% for executing malicious commands, and Anthropic's page says its boundary is a permission prompt, so a Bash command a user approves can write anywhere that account can. A kernel exploit is the rare case that gets attention. The common case is an agent persuaded to run something, with every permission it was granted still in force.

What should a team record before trusting a sandbox?

The boundary as documented, the tools and servers outside it, the token each server holds and its scope, and the pages the agent reads that carry values. Then one run: the command issued, the page rendered, the values the model received, and the person who approved the action. Keep that beside the vendor's own stated limit rather than a summary of it. The comparison usually shows which layer is doing the work and which one is being credited for it.

About the author

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

How RedactSure Governs the Pages the Sandbox Does Not Cover

The designs reviewed above bound where a command may write and what a guest may send, but none governs the webhook settings page an agent opens.

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Before: the agent opens the repository's webhook settings page, and the model receives the signing key and the account name as the page renders them. Inside the governed environment: the page renders as HOOK_002 and ORG_007 for the whole run, and a named person approves the webhook edit.

RedactSure is deploying now with enterprise and government customers. The coding editor study reported attack success rates as high as 84%.

Everyone else controls where data can go. RedactSure controls what the AI can see.

See it on your own workflow

A sandbox does not reach the settings pages your agent opens in a browser. Bring a task that takes the agent to a page such as webhook settings and see, with test values, what the model reads there. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.