Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Should a Coding Agent Sandbox Have Access To?

The repository the task works in, the tools it runs and the results of credentialed calls; not the credential, not the rest of the filesystem, not the network beyond the task. Check those three exclusions against a sandbox manifest before the agent's next run.

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

A sandbox is defined by its manifest, the list of what the process inside it may read, write and reach. For a coding task that list is short, and most of the work on it is subtraction. The repository at a named commit, the toolchain the task invokes and the result of any call that needed a credential belong on it. The credential itself, the rest of the filesystem and every destination the task never uses belong off it. Writing the list is an inventory exercise rather than a hardening exercise, and it begins with one record type: a sandbox manifest written for a single task. A manifest needs six entries, and each of the three exclusions is worth something specific to an attacker who reaches the sandbox. Anthropic, the Model Context Protocol maintainers and GitLab document sandbox boundaries and credentials, and some routes run past any manifest a team can write, so a manifest should be tested against its task after it is written. What Is Least Exposure? and What Is a Tethered Agent? frame the distinction the last sections depend on: authority can be scoped to one task, while what a model was shown on a rendered page is a separate question from what the process was allowed to touch.

Key findings

  • Claude Code's sandboxing page states that "the sandbox covers shell commands only", while Read, Edit, Write, WebFetch and WebSearch follow permission rules and local MCP servers and hooks run with full access, so a manifest that lists a sandbox is not a list of everything the agent can reach (Anthropic, Sandboxing, 2026).
  • Claude Code's security page adds that the boundary is a permission prompt, so "a Bash command you approve can still write anywhere your user account can", which is the developer's access and not the task's (Anthropic, Security, 2026).
  • A study of browsing agents reports that "our findings include prompt injection, domain validation bypass, and credential exfiltration" and demonstrates "how untrusted web content can hijack agent behavior", which is what a network grant wider than the task exposes (Mudryi et al., 2025).
  • GitGuardian counted "about 29 million secrets leaked on public GitHub in 2025" and an 81 percent year-over-year rise in AI-service leaks, credentials that reached files no task needed (GitGuardian, 2026).
  • A governed environment replaces values chosen by policy with consistent tokens before any model reads the screen, so the run that opens a repository settings page works on KEY_001 rather than the key (What Is Least Exposure?).
  • In that control class real values resolve only at the approved destination at the moment of an approved action, and a named person approves each consequential action, which is the part of access a sandbox manifest cannot express (What Is a Tethered Agent?).

What belongs on a manifest for one sandboxed task?

Take the record as a manifest for one task: update a dependency and repair the test it breaks, in one repository, on one branch, for one run. Written out, the manifest has six entries. Each is a grant with a scope and an end.

Entry What it grants for this task What it does not grant
Working copy The repository at a named commit, read and write Any other repository, and any branch but the task's own
Toolchain The runtime, compiler, test runner and package manager the task invokes A browser, a database client and a cloud command line the task never calls
Package source One registry mirror and a local cache for the ecosystems the task builds against Publish rights, and any host outside the mirror
Scratch space A writable directory for build output, discarded after the run The home directory, the credential store, the rest of the filesystem
Credentialed results The pull request number, the CI report, the ticket the run opened The token, key or password that produced them
Return channel A diff or patch, and a log of the run A path to push, publish or deploy

Read down the second column of the table above and the list is unremarkable, which is the point. The entry teams most often get wrong is the fifth: a token in the environment is easier to arrange than a broker outside the sandbox, so the token goes in and the result comes back with the token still attached. Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool? and How Do I Keep Credentials Outside the Sandbox Where the Agent Runs? work through that entry from the administrator side and the credential side.

Two scope notes belong here. The manifest is about the terminal, the IDE and the filesystem. A governed browser environment, described at the end of this page, covers what an agent reads and does on a rendered page: dashboards, consoles and settings pages. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, so the manifest remains the instrument for everything a task does off the page.

A manifest also needs an owner and an expiry. One named person signs the six entries, one end time voids them, and the run's log comes back with the diff. Without those two lines the list describes an intention rather than a grant, and that is the difference between an inventory and a policy.

Why do the three exclusions matter more than the grants?

A manifest reads as a list of permissions, and the more useful reading is its silences. Three things are left out of every manifest for a coding task.

The credential comes first, because it outlives the task. The Model Context Protocol's security guidance states that "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server" and that "poor scope design increases token compromise impact, elevates user friction, and obscures audit trails" (Model Context Protocol, 2026). The same guidance warns that cloud metadata endpoints "often expose IAM credentials, API keys, and other secrets", the destination a network grant beyond the task reaches first (Model Context Protocol, 2026).

The filesystem comes second, because it holds values the task never names. Wiz examined 50 AI companies and found that "65% had leaked verified secrets on GitHub" (Wiz, 2025). An agent with a home directory can read a shell history, a cloud credential file and the settings for every service the developer has touched, none of which the task requires.

The network comes third, because it turns a local mistake into an export. What Network Access Should a Coding Agent Sandbox Have? treats the destination list as a list to justify one host at a time. If a grant cannot be described in one sentence that names the task's need, it stays off the manifest until someone writes that sentence.

What do the vendors themselves say?

Three sets of vendor documentation bear on the inventory.

Anthropic's Claude Code pages are the most detailed. The security page states that "GitHub credentials are stored encrypted on Anthropic's servers and never enter the session VM" and that the VM holds "a short-lived credential scoped to that session" (Anthropic, Security, 2026). The permissions page states that if a project has a .claudeignore file, "it has no effect, so move its entries" into Read deny rules (Anthropic, Configure, 2026). The same page adds that 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), the gap between a rule about a path and a process that searches every path.

On credentials the sandboxing page is specific: with mask "the sandboxed command sees a sentinel", and the local proxy substitutes the real value only on hosts in injectHosts, or on every host in network.allowedDomains when that list is empty (Anthropic, Sandboxing, 2026). That is the closest documented design to the fifth entry, and it stops at the shell command.

Anthropic's engineering write-up states that "effective sandboxing requires both filesystem and network isolation" and that sandboxing "safely reduces permission prompts by 84%", a case that measures prompts avoided rather than values withheld (Anthropic Engineering, 2025).

Dimension Claude Code, per its documentation What a buyer should verify
Shell coverage Sandboxed bash commands, with filesystem and network isolation Whether both isolations are on for the task's shell
File tools Read, Edit, Write, WebFetch and WebSearch follow permission rules Who writes those rules, and from which settings file
Ignore files A .claudeignore file has no effect; entries belong in Read deny rules That no repository file grants an exemption
Read exceptions Deny rules do not stop a command that reads files without naming them Whether the task needs a search across the whole tree
Credentials Masked: sandboxed commands see a sentinel, resolved for hosts in injectHosts Which hosts are on the list, and for how long
Cloud sessions GitHub credentials stay on the servers; a short-lived credential enters the VM Whether the same holds for a local session
Local MCP and hooks Run with full access outside the sandbox Whether the task needs them at all
Model exposure Not described in the pages reviewed A policy on which values the model is shown

What runs past the manifest?

Every manifest governs processes, and a coding agent's exposure does not stop at the process boundary.

The first route past it is the install step. Package hallucination research puts invented names at "at least 5.2% for commercial models and 21.7% for open-source models" (Spracklen et al., 2025). One registry mirror narrows the destination but not the decision: if the invented name resolves there, the task installs a package nobody chose. A lockfile rule closes it, with the mirror serving only the names the lockfile records.

The second is text the model reads. A study of neural code completion tools found that "two valid credentials were identified during our experiments" and that the tools can "return the precise piece of their training data" (Huang et al., 2024). A tool result, a log line or a comment in the file being edited is text the model reads, and it can carry a value the manifest never granted.

The third is the page the agent opens inside the sandbox, and this one the format cannot express. A repository settings page that lists deploy keys, a cloud console that shows an access key, an issue page that carries a customer's account number: the manifest grants the process a socket and a file descriptor, and the page arrives in the model's context as text. Nothing in the six entries distinguishes those values from the code the task is working on. Should AI Agents Use Screens, APIs or MCP? sets out why a page is a different channel from an API call.

How do you test a manifest against its task?

Four checks, run in order, answer the question for one manifest.

Subtract first. Remove one grant at a time and rerun the task. If the task still passes, the grant was surplus; if it fails, the failure names the need the entry serves.

Watch egress second. Log every destination the run contacts and compare the list with the task. A mirror, a source control endpoint and the API that returns the result are expected; a metadata endpoint, a paste service or a chat API is not. An export needs a destination, and the log is where it appears.

Plant an instruction third. Put a line in a comment, an issue body or a dependency's README that tells the agent to fetch a URL and post the contents. If the agent follows it, the test has found the gap between what the manifest governs and what the model does with what it reads.

Read the record fourth. The run should produce a list of what the agent read, where it wrote, which credential the task needed and who approved the exception.

Recovery is the part teams plan last. A credential that reached the working copy is revoked and replaced. Rotation is not a boundary, and the AWS advice against creating access keys for the root user is the same lesson at the top of the account (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?). Anthropic's security page says the protections "significantly reduce risk" while "no system is completely immune to all attacks", the honest frame for a manifest too (Anthropic, Security, 2026).

What does a governed environment change?

A governed environment is a control class that acts where a screen is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so a settings page that lists keys renders KEY_001, PAT_001 or ACCT_001 in place of each value. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each 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 class adds the one entry a manifest cannot hold: the page. The six entries can grant a process a socket and a file descriptor, and they cannot say that the key on the settings page will reach the model as a placeholder. Under the control class the value is substituted before the model reads the page, resolved from a store the sandbox never mounts, and released only to the destination a named person approved. The manifest governs what the process can touch; the governed environment governs what the model can see, and the two meet at the page the agent opens inside the sandbox.

The scope is the rendered page. The manifest still governs the terminal, the IDE, the local filesystem, the registry mirror and the network. A page that renders values to the model is the one place where an inventory of process access and an inventory of exposure have to be written separately.

Methodology and limitations

This page rests on vendor documentation from Anthropic and GitLab, the Model Context Protocol specification's security guidance, three research preprints on browsing agents, credential memorization and package hallucination, and two industry reports on credential leakage, together with existing RedactSure research pages. Vendor pages were read as of October 20, 2026, and each Sources line carries the date for its page. Quoted facts are cited to the page that states them, and the leak figures are cited as their publishers reported them rather than as independently measured. The preprints are cited for the findings their abstract pages state, and the reports for the figures their publishers give.

RedactSure did not test Claude Code, GitLab or any sandbox hands-on. "Not described in the pages reviewed" means the pages reviewed and nothing broader, and a vendor that later documents the behavior would change that sentence. The vendor features described here change, and the page carries its date; a release after it should be treated as unreviewed until the test above 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, a sandbox manifest for one task, and not an organization.

Determinations about whether an access grant meets a legal, contractual or regulatory 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 against its own repository, repeated after each change to the sandbox, the permission system or the credential broker.

What the record shows

The record points one way. A sandbox's access should be the task's access: the repository at a commit, the toolchain, a package source, scratch space, the results of credentialed calls and a way to return the work, with the credential, the rest of the filesystem and the wider network left out. The vendor pages document the boundary and its holes, a shell-only sandbox, file tools on separate rules, a mask that resolves real values for listed hosts, and a prompt count cut by 84%. What none of them documents is an entry for the page the agent opens inside the sandbox, where a value reaches the model as text; RedactSure's environment is built to replace it there. Write the agent's manifest as six lines for a single task, run it with egress logging as a test, and compare the grants it held with the grants it used.

Frequently asked questions

What should a coding agent sandbox have access to?

The repository the task works in, the toolchain it calls, a package source for the ecosystems it builds against, scratch space, the results of credentialed calls and a channel to return the work. The credential that produced those results, the rest of the filesystem and any destination the task never uses stay out. Write the six entries before the run, give each an end, and treat anything the task asks for later as a change a person approves in writing. The list should look boring.

Does a sandbox need the developer's credentials?

No, if a component outside the sandbox makes the call. The task needs the pull request number, the CI report or the ticket, not the token that produced them. Handing over the developer's token is the shortcut, and it puts a long-lived value inside the process an injected instruction can steer. A broker, a token scoped to one repository, or an environment that holds the value and returns the result all work; the question to ask is whether the sandbox can read the string at all.

Should a sandbox have network access at all?

Only to the destinations the task needs. A package mirror, the source control endpoint and the API that returns the result are typical; everything else is optional. A browsing-agent study found credential exfiltration among its results, and exfiltration needs a destination. An allowlist narrows the set, but the honest test is to log every host the run contacts and compare that list with the task. A host nobody can justify in one sentence should be closed.

Do permission prompts make a sandbox unnecessary?

No. A prompt gates one action and does not change the access behind it; Anthropic's security page says a command you approve can still write anywhere your user account can. A sandbox narrows what the process can reach before the prompt appears, and the two work in sequence: the sandbox sets the boundary, the prompt decides whether a step inside it runs. Neither says which values on the page the agent opens are shown to the model.

What about the tools and packages a task needs?

Put them on the list with a version and a source. A toolchain entry names the compiler, test runner and package manager the task calls, not every binary in the image. A package entry names one mirror and one cache, with publish rights left outside. Code generators hallucinate package names at a rate the research puts at 5.2% or more for commercial models, so the install step deserves its own rule: the mirror serves only the names the lockfile records.

How do you know a manifest is right for a task?

Subtract one grant at a time and rerun the task. If it still passes, the grant was surplus and stays out. Then log egress, plant an instruction in a comment to see whether the agent follows it, and read the record of what the agent read, wrote, called and had approved. A manifest that survives the subtraction and produces a short, explainable log is right for that task alone, and the next task starts from its own list.

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 Sandbox Manifest to the Task

A sandbox manifest describes what the process may touch, and the vendor pages above never state what values the model receives from a settings page the task 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 deploy keys settings page, the private key renders in full, and the value enters the model's context. Inside the governed environment: the page renders DEPLOY_KEY_001, the agent finishes, and the key is released only to the host a named person approved.

RedactSure is deploying now with enterprise and government customers. GitGuardian put the 2025 GitHub total at about 29 million leaked credentials.

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

See it on your own workflow

A sandbox manifest should list what the task needs and nothing more. Bring a task and see, with test values, the deploy keys page as the model reads it and the host the key is released to. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.