Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Is a Sandbox Enough to Make a Coding Agent Safe?

No, because a sandbox answers one question well: it contains what a process can reach and what it can send. Credentials, the repository's own data, the tools that run outside the boundary and the approval of a consequential action are four questions it leaves open, and each needs a named control.

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

Reviewers approving a coding agent often stop at the sandbox, a boundary around a process whose documentation is specific enough to check. What that documentation does not answer is the rest of the review. An agent can sit inside a boundary that holds, with no escape and no kernel bug, and still read a credential through a route the boundary does not govern, absorb the values a repository puts in front of it, call a server that carries its own token, and take an action no person approved. Each is a question about information and authority rather than containment, and none is a weaker version of the escape question.

The sections take them in the order a review meets them: the boundary, credentials, the repository, the tools outside it, and the approval. One record type runs through the page, a deploy key rotation performed by a coding agent inside a sandbox that holds, so the same run is examined from each side. Vendor pages are quoted where they state a limit, since the limit is usually in the vendor's sentence. What Is Least Exposure? sets out why the last of the four is not a permissions problem.

Key findings

  • Anthropic's Claude Code documentation places the boundary around the shell: it covers shell commands only, while Read, Edit, Write, WebFetch, WebSearch, MCP servers and hooks run outside it, and its credential setting covers sandboxed commands alone (Anthropic, Sandboxing, 2026).
  • The permissions page says a .claudeignore file "has no effect," that a path is kept from the Read tool by a Read(./.env) deny rule, and that such rules "don't apply to a command that reads files without naming them" (Anthropic, Configure, 2026).
  • Anthropic's engineering post gives the pair the boundary needs, that "effective sandboxing requires both filesystem and network isolation," and reports that sandboxing "safely reduces permission prompts by 84%" (Anthropic Engineering, 2025).
  • Cursor's security page defaults terminal commands and MCP connections to approval, "By default, terminal commands need your approval," and calls its run modes "best-effort guardrails rather than a hard security boundary" (Cursor, 2026).
  • A secure VM is one layer, not the whole design: the description of Meta's own agent pairs a dedicated VM with "surrogate tokens" it uses without seeing and a separate component that approves every egress (What Would an Enterprise Version of Meta Muse Need?).
  • Least privilege governs actions and credentials and not the content of a screen an agent reads, so an agent can satisfy it in full and still hold every value shown (What Is Least Exposure?).

What does a sandbox answer, and what are the four questions it leaves open?

The question a sandbox answers is containment: whether a process can reach the host, the network or another tenant beyond the boundary its operator drew. Anthropic's engineering post sets the bar, that "effective sandboxing requires both filesystem and network isolation," and the sandboxing page confines the setting to shell commands (Anthropic Engineering, 2025). The control is worth having, and it is a control over processes.

The four questions that follow are not weaker versions of that one. First, what the agent may use and where the real value lives, because a key can be denied to a command and still open to a file tool. Second, what the repository puts in front of the model: the code, the history and the instructions in a file are not a containment question at all. Third, which tools run outside the boundary, because a permission rule is a policy and not isolation. Fourth, who approves an action the boundary permits, and what record survives it. A sandbox that holds answers none of them.

A page-level control is narrower, since a coding agent spends most of its day outside it. A governed browser environment covers what an agent reads and does on a rendered page, meaning a repository settings page, a cloud console or an issue page, and does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP.

Question What the sandbox answers What is left open
Containment Where a process may run, what it may read, where it may send Nothing beyond the strength of the boundary itself
Credentials Not addressed by isolation Which value is used, by whom, and from where
Repository data Not addressed What the model is shown while it works
Tools outside Not covered File tools, web fetches, MCP servers, hooks
Approval Not addressed Who authorized the action, and the record

The record type for this page is a deploy key rotation: an agent inside a sandbox that holds, asked to replace a production deploy key and put the new value where the repository can use it. Each section asks what the boundary did not decide about that run.

Where do the credentials sit while the sandbox runs?

Custody is the first of the four, because the settings that govern credentials stop at the command. A deny rule keeps a path from the file tools, with the page's caveat that it does not reach a command reading files without naming them. A masked credential shows a sentinel to the sandboxed command while a local proxy substitutes the real value on hosts in injectHosts. Neither changes what a page displays.

Microsoft documents a different answer for a workload on its own platform: "Managed identities eliminate the need for developers to manage these credentials," which removes a durable string from an Azure run and says nothing about a value the agent must carry between two pages (Microsoft, 2026). As Is It Safe to Let an AI Agent Set Up Your Cloud Environment? notes, AWS strongly recommends against root access keys, the simplest durable credential an agent could be given.

Then the servers. The Model Context Protocol's guidance states that "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server," and a server holding a token issued to it reads what that token reads (Model Context Protocol, 2026). A platform that federates MCP servers "into a single endpoint" concentrates that reach (RedactSure vs Arcade: 2026 Comparison & Alternative), and How Do You Let an AI Agent Manage API Keys Without Reading Them? takes up the design question for the API case.

What do the vendors themselves say?

Anthropic documents two layers and is explicit about which is which. The sandboxing page states that the sandbox covers shell commands only, with Read, Edit, Write, WebFetch, WebSearch, MCP servers and hooks outside it, and that sandbox.credentials affects sandboxed Bash commands only (Anthropic, Sandboxing, 2026). On macOS a masked credential file cannot be read inside the sandbox at all, the same effect as deny.

The permissions page supplies the file-tool rule: "To block Claude's file tools from reading a file or directory, add a Read deny rule for its path," and it points to the sandbox for enforcement that blocks every process (Anthropic, Configure, 2026). It also says a .claudeignore file has no effect, and that the deny rules "don't apply to a command that reads files without naming them." One detail matters for the team that writes the setting: sandbox.credentials is ignored in a repository's own settings file, so a rule that protects a key cannot sit in the file a pull request reviews.

Cursor's page documents approvals rather than a boundary: "By default, terminal commands need your approval" and "All MCP connections need your approval," and it states that "AI can behave unexpectedly due to prompt injection, hallucinations, and other issues" (Cursor, 2026). It describes its run modes as "best-effort guardrails rather than a hard security boundary." The page does not mention a sandbox, and how credentials are stored or protected is not described in the pages reviewed.

Dimension Anthropic, Claude Code, per its documentation Cursor, per its documentation What a buyer should verify
What the boundary holds Sandboxed Bash commands, with filesystem and network isolation No sandbox described; run modes called best-effort guardrails Which work runs inside a boundary and which does not
What runs outside it Read, Edit, Write, WebFetch, WebSearch, MCP servers, hooks Terminal commands and MCP connections behind approval The list, in writing, for the tools the team uses
Credential custody Deny and mask settings for sandboxed Bash; macOS blocks a masked file entirely Not described Custody for a local session and for each server
Default approval Permission rules for file tools; commands approved or denied by rule Terminal and MCP approval on by default Who approves a deploy, a push or a key rotation
Record Not described for the model's view Not described What the model saw and who approved each action

What does the repository put in front of the model?

The second question is what the repository contributes, and it is the one a boundary cannot touch. A coding agent reads continuously: source files, CI configuration, deployment notes, the history behind a function. Those reads go through the file tools, which follow permission rules rather than the sandbox, and through commands that name a file or do not. The research record on code tools is the reason to care. A study of neural code completion tools reports that "two valid credentials were identified during our experiments," evidence that a value a tool has seen can return in its output (Huang et al., 2024). The same study states that the tools "can not only return the precise piece of their training data," and its abstract does not give the number of tools tested, so the finding is a mechanism rather than a rate.

Dependencies carry the exposure from the other direction. Code generating models invent package names at a rate of "at least 5.2% for commercial models and 21.7% for open-source models," and a name that resolves to someone else's package installs code the agent then runs (Spracklen et al., 2025). The study does not say whether hallucinated names were registered and exploited. Inside a boundary that code runs with the agent's own reach, so the boundary limits where it can go and not what it can read on the way.

For the rotation record, the repository is where the run starts: the deployment notes name the key, the CI configuration shows where it is consumed, and the history shows when it last changed.

Who approves an action the sandbox permits?

Containment decides what a command may touch, and approval decides whether a command should have run. A boundary supplies the second only by accident. Cursor's page is the clearest vendor statement of the difference: terminal commands and MCP connections need approval by default, which governs action and says nothing about what the model read before it proposed it.

The design literature takes the action side seriously. Willison's patterns "constrain the actions of agents to explicitly prevent them from solving arbitrary tasks," and one of them allows that "Agents can trigger tools, but cannot be exposed to or act on the responses from those tools," with no empirical test of the patterns reported on the page (Willison, 2025). That is a discipline for the tool layer, not a property of a container.

Progent's authors report that privilege control "significantly reduces attack success rates while maintaining high utility," and their abstract gives no figures, so the record shows a direction rather than a size (Shi et al., 2026). The idea is that authority narrows per step, so a command that should never have been issued reaches less. It still leaves the question of who is accountable when a permitted action lands. The tether is a description of authority, not of capability (What Is a Tethered Agent?), which is why a sandbox cannot stand in for an approver.

In the rotation record, every command ran where it was supposed to run, and the sandbox permitted the call that replaced the key. Nothing named the person who authorized the change, and nothing recorded what the model had read.

What does a governed environment change?

A governed environment is a control class that acts where a page is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so a settings screen that carries a key renders as KEY_003 and an account as ACCT_014. 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 in which layer decides exposure. A boundary governs where a process runs and what it can send. A governed environment governs what a rendered screen shows the model, and the two answer different questions. The rendered page is a measured leakage point, since the research recorded for the sign-up case describes an environmental injection attack on generalist web agents that reached an attack success rate of up to 70 percent in stealing users' specific personal information (Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity?).

What it does not do is replace the boundary. The terminal, the IDE, the local filesystem, direct API calls and MCP stay with the sandbox, the permission rule and the scoped token, and a team that has a sandbox should keep it. The change is that four questions get four named controls instead of one asked to carry them all, and the fourth, the record, is the one a review can read afterward.

Methodology and limitations

This page rests on three research preprints about credential memorization, package hallucination and privilege control, vendor documentation from Anthropic and Cursor, Microsoft's managed identity page, the Model Context Protocol security guidance, and one practitioner analysis of agent design patterns, 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 counted figures are cited as reported rather than independently measured.

RedactSure did not test any of the products hands-on, and this page describes no run performed against a live repository. Where a page reviewed does not address a point, the page says so rather than treating silence as a denial, and 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 checks above are repeated. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a deploy key rotation by a coding agent inside a sandbox, and not an organization.

Determinations about whether a sandbox, a permission rule or a credential design 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, with the transcript kept and the approver named. 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 with a qualified no. A sandbox is documented as containing processes, and the pages reviewed give it a measured benefit: fewer prompts, and isolation of both filesystem and network. What it does not tell a reader is which credential the run used, what the repository put in front of the model, which tools ran outside the boundary, or who approved the action that landed. Each of those has a control in the vendor documentation or in the research record, and none of them is containment. RedactSure's environment is the render-layer control for the pages in that run and nothing else. For a first test, a reviewer should pick one agent and one task, list the four questions against the run, and record which control answered each and what the model received.

Frequently asked questions

Is a sandbox enough to make a coding agent safe?

No, because it answers containment and the review has four more questions. Credential custody decides which value the run may use, permission rules and token scope decide what the tools and servers reach, the repository decides what the model reads, and an approver decides whether a consequential action lands. A boundary that holds is a necessary first layer, and it is the only one a container can supply. Count the layers before you connect a production credential.

What does a coding agent's sandbox actually hold?

By Anthropic's documentation, the sandbox covers shell commands, with filesystem and network isolation. Read, Edit, Write, WebFetch, WebSearch, MCP servers and hooks run outside it, and the credential setting applies to sandboxed Bash commands only. Cursor's page describes approvals for terminal commands and MCP connections and no sandbox at all. The boundary holds the processes it starts in the shell. Ask which tools follow a permission rule, which run with full access, and which hold a token of their own.

Can a sandbox keep a credential out of the model's context?

Only for the routes it governs. A deny rule can keep a path from the file tools, and a masked credential shows a sentinel to sandboxed commands while a proxy supplies the real value on listed hosts. Neither changes what a page displays, and a file opened by the Read tool still arrives in full unless a permission rule blocks it. Check the Read route separately from the command route, and check whether a page renders the value again.

What can a coding agent read inside a sandbox?

Whatever its permission rules and tools allow. The file tools read the working tree and, where permission rules allow, files under the home directory, and a command can read the files it names and some it finds. Code completion tools have returned credentials they had seen, and code generating models invent package names at a measurable rate, so an installed package runs with the agent's own reach. What the boundary decides is where that happens, not what is read.

Who should approve an action the sandbox allows?

A named person, outside the model, for each action a customer depends on: a deploy, a key rotation, a production configuration change, a push to a protected branch. A per-command approval prompt is not the same thing, because it asks about a command rather than a consequence, and the person answering is often the one who started the run. Approval has to leave a record too, or the next review starts from memory.

What should a team ask for in writing?

The scope of the boundary and the tools that run outside it; how a credential is held and which pages may display it; the token each server carries and its scope; who approves a consequential action and the name on the record; and what the model received on each rendered page. Then run one rotation and compare the answers with the transcript. A vendor that cannot answer in writing has not described the control, and an answer without a date has not been checked.

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 Keeps a Rotated Deploy Key Out of the Model's Context

A boundary around a process leaves the value on the screen, and no control reviewed answers what the model is shown when a key appears on a page.

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

Before: the key console and the repository's deploy keys settings page render the new key, and the model receives it twice. Inside the governed environment: both pages render DEPLOYKEY_003, and the real value reaches the key field on a named person's approval.

RedactSure is deploying now with enterprise and government customers. Anthropic confines its credential setting to sandboxed Bash commands.

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

See it on your own workflow

A sandbox does not stop a rotated key from appearing on the two pages the agent reads during the rotation. Bring a key rotation your team performs and see, with test values, what the model receives on both. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.