Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Can Credentials Stay Outside the Sandbox and Still Be Used Inside It?

Yes, when the request leaves the sandbox with a placeholder and the credential is attached outside it, on the host or at a proxy, so the sandbox never holds the value. Check which component holds the credential, which hosts may receive the real value, and what the agent can still open through its own file tools.

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

Whoever approves an agent's access to a credential has to decide where that value lives and who answers for it. A sandbox is a boundary around a process, and a credential is a value the process may need to finish a task; the obvious way to give it one is to place the value inside. The title asks whether the two can be separated, so that the value stays on the host or in a store while the work that needs it still completes within the boundary. They can, and the mechanism is a substitution: the sandbox carries a placeholder, the request leaves, and a component outside writes the real value into it. The answer depends less on the strength of the sandbox than on where that substitution happens. This page locates the boundary and what a browser control governs, follows the substitution through Docker Sandboxes and Claude Code, reads where each vendor's account stops, and lists what remains reachable once the value is outside, with a test a team can run on its own setup. One record type, a request rewritten at the boundary, carries the argument through sections that follow a request from the page that displays a credential to the call that uses it.

Key findings

  • Docker's credentials page states that "The real credential stays on the host when proxy management is active; the sandbox sees only a sentinel value," so the request leaves the sandbox and the value is attached on the host side (Docker, Manage, 2026).
  • Anthropic documents a mask mode in which a sandboxed Bash command sees a sentinel and a proxy on the developer's machine substitutes the real value only for hosts listed in injectHosts (Anthropic, Sandboxing, 2026).
  • The Model Context Protocol guidance states that "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server," and it warns that MCP servers "run with the same privileges as the client" (Model Context Protocol, 2026).
  • A governed environment replaces a value with a consistent token before any model reads the screen, so an agent that requests a page holds the token and never the string (What Is Least Exposure?).
  • Real values resolve only at the approved destination at the moment of an approved action, and the approval carries the name of the person who gave it (What Is a Tethered Agent?).

What does it mean for a credential to stay outside the sandbox?

Outside means any place the sandboxed process cannot read. Two arrangements fit that description. The value can sit on the host while a proxy attaches it to a request as the request leaves. It can sit in a store that issues a short-lived credential to a component outside the agent. Either keeps the string out of the agent's process, and neither changes what the agent reads while it works.

The boundary has an address. A governed browser environment covers what the agent reads and does on a rendered page: dashboards, consoles, settings pages, sign-up forms. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A coding agent's shell commands and file reads sit outside that control, and so does a tool server it calls. Least privilege, the identity industry's standard answer, governs actions and credentials and does not govern the content of the screen: an agent can satisfy it in full and still hold every record it was shown (What Is Least Exposure?).

The rendered page is also where leakage accumulates. A help-center page for the browser agent states that it sees what is on the page and can act on it, and that use of sessions open in the browser is not described there (Does Claude in Chrome Use Your Saved Logins and Open Sessions?). One review of 2025 monitoring counted 28,649,024 new credentials in public GitHub commits, with commits co-authored by an AI coding agent leaking at roughly double the baseline rate and 24,008 unique credentials in MCP configuration files, as How Do You Let an AI Agent Manage API Keys Without Reading Them? records.

How does a request leave the sandbox and still carry the real credential?

The record for this page is a request rewritten at the boundary. A sandboxed job needs to publish a package, and the publish token is not in the sandbox. The job's environment holds PUBLISH_001, and the request leaves with that string in the authorization header. A proxy on the host matches the placeholder to a stored credential and writes the real header before forwarding. The registry sees a valid token; the sandbox and the model saw only the placeholder.

Docker documents the arrangement. "An HTTP/HTTPS proxy on your host intercepts outbound requests from the sandbox" and "overwrites the auth header before forwarding," and "The real credential stays on the host when proxy management is active; the sandbox sees only a sentinel value" (Docker, Manage, 2026). A kit with passthrough set to true "sends the real token response into the sandbox and reduces credential isolation," and the flows described "apply to local sandboxes."

Claude Code is narrower. The sandbox covers shell commands only, and with mask the sandboxed command sees a sentinel while the local proxy substitutes the real value only on hosts in injectHosts, or on every host in its allowed-domains list when that host list is empty (Anthropic, Sandboxing, 2026). Read, Edit, Write, WebFetch, WebSearch, MCP servers and hooks run outside the sandbox, so masking covers commands, not files.

Willison's design patterns hold that "Agents can trigger tools, but cannot be exposed to or act on the responses from those tools" (Willison, 2025). A managed identity is the same idea: the AgentCore Identity documentation says centralized credential management eliminates the need to embed credentials in agent code or configuration files (Does AWS Bedrock Keep Company Credentials Away From Agents?).

What do the vendors themselves say?

The two vendor pages that document the substitution each stop at a different edge, and the table below puts their claims side by side.

Docker's isolation page describes the boundary: "Every sandbox runs inside a lightweight microVM with its own Linux kernel," the agent has no path to the host's Docker daemon, and "Credential values are never stored inside the VM" (Docker, Isolation, 2026). The last statement is about the microVM's own storage, and the credentials page is where the sentinel mechanism is written down. The isolation page does not describe cloud sandbox behavior; it points to a separate comparison page.

Anthropic's security page describes the sandbox and its edge: "Sandbox bash commands with filesystem and network isolation, reducing permission prompts while maintaining security." It also states the limit plainly: "The boundary is a permission prompt, so a Bash command you approve can still write anywhere your user account can," and that "no system is completely immune to all attacks" (Anthropic, Security, 2026). The credential custody on that page, GitHub credentials stored encrypted and kept out of the session VM, is described for Anthropic-hosted cloud sessions and not for local ones.

Dimension Docker Sandboxes, per its documentation Anthropic's Claude Code, per its documentation What a buyer should verify
Boundary A lightweight microVM with its own Linux kernel Shell commands only; file tools, WebFetch, WebSearch, MCP and hooks outside Which steps of the workflow are shell commands
Where the real value sits On the host, with the proxy On the developer's machine, with the local proxy, for hosts in injectHosts Which hosts are on the list
What the sandbox sees A sentinel value A sentinel, in sandboxed Bash commands Whether a passthrough kit or a settings file changes that
Custody claim Credential values never stored inside the VM GitHub credentials never enter the cloud session VM Whether the run is local or in the cloud
Per-run record No per-run record on these pages No per-run record on these pages What the vendor can show a reviewer afterward

Read together, the accounts answer different halves of the title. One keeps the value out of the sandbox for the requests its proxy manages; the other keeps it out of sandboxed commands for the hosts it lists. Neither page describes a per-run record of what the model received from a rendered page, which is the question the rest of this page turns on.

What can still reach the credential once it is outside the sandbox?

Every substitution covers the routes it is applied to, and the agent has others. A token that also sits in a file the agent can open is in the model's context the moment that file is read, whatever the proxy does with the request that follows. Claude Code's permissions page separates the two: "To block Claude's file tools from reading a file or directory, add a Read deny rule for its path," and a project .claudeignore file "has no effect," so its entries belong in 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."

A deny entry is therefore a control on named paths, and it does not stop the file tool itself: "A denyRead entry doesn't stop the Read tool" (Anthropic, Sandboxing, 2026). A command that enumerates a directory can surface what the rule was meant to hide, and a tool server that returns a page body can return a value with it.

The account-level routes have the same shape. A durable credential at the top of an account outlives the task and is reachable from every run, which is why the cloud provider's own guidance recommends against creating access keys for the root user (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?). The administrator guidance for a productivity suite says the super admin account should be used only when needed, a rule written for people that applies with more force to an agent (Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool?).

How does a team test whether a credential ever entered the sandbox?

The test needs one agent, one task and one credential. Run the task, then search the transcript and the pages the agent rendered for the value. If it appears in either place, the boundary did not hold for that route, whatever the proxy did with the request that followed.

The baseline matters because models repeat what they read. GitGuardian's test of Copilot reported that "Copilot generates 2702/900 = 3.0 valid secrets for one prompt on average," and that among the repositories it examined "over 1,200 leaked at least one secret" (GitGuardian, 2025). The post does not confirm whether the extracted credentials were still active, so the finding is about repetition and not about live access.

Volume makes the baseline worse. SecretBench is "a labeled dataset of source codes containing 97,479 secrets (of which 15,084 are true secrets)" (Basak et al., 2023). Its 2021 comparison figure comes from monitoring the authors cite rather than measure, and the paper reports no tool evaluation, so the dataset is cited for the population and not for a rate.

The risk register names the same failure. In the non-human identity top 10, NHI2 Secret Leakage is the "leakage of sensitive NHIs such as API keys, tokens, encryption keys, and certificates to unsanctioned data stores," and NHI5 covers overprivileged identities (OWASP, 2025). A sandbox that keeps a durable credential for the agent, and a proxy that rewrites one header, pass neither test on their own.

Score the run on three questions: which component held the string, which destinations received it, and who approved the action that used it. A team that cannot answer all three has a boundary it cannot describe, and the next release will move it.

What does a governed environment change?

A governed environment is a control class that sits at the render layer, before a model reads a screen. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works on PUBLISH_001 rather than the string, and the same token appears on every page for as long as the run lasts.

Real values resolve only at the approved destination, at the moment of an approved action. A named person confirms which values are tokenized, approves each consequential action, and can pause the run. 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 complementary to a sandbox rather than a replacement. A sandbox proxy attaches the real credential to a request that has already left the process, and the value stays outside the agent. A governed environment keeps the value off the screen the agent reads before it builds that request, so the token, not the credential, is what the model reasons over during the task. The two controls meet at the same boundary: one governs what the process may do, the other what the model was shown.

The limits are worth stating. The scope is the rendered page, so a credential the agent reads through a shell command or an API call in its own process is outside it, and the sandbox and the credential store remain the controls for that path. A policy that tokenizes nothing leaves the screen as it was, and a token is only as useful as the destinations its policy allows.

Methodology and limitations

This page rests on vendor documentation from Anthropic and Docker, one preprint on software credentials, the Model Context Protocol security guidance, the OWASP non-human identity top 10, one vendor research post from GitGuardian, one practitioner analysis of agent design patterns, and existing research pages on exposure and on authority. Vendor pages were read between October 20, 2026 and October 21, 2026, and each Sources line carries the date for its page. Quoted statements are cited to the page that carries them; the figures from the research post and the preprint are reported as those pages state them, not as independently measured.

RedactSure did not run a coding agent inside Docker, Docker Sandboxes or Claude Code for this page. The vendor pages describe local sandboxes; whether a cloud sandbox behaves the same way is not described in the pages reviewed, and a reader should treat a release after the read dates as unreviewed until the test at the end of this page is repeated. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a publish request rewritten at the boundary and a token rendered on a settings page, not an organization.

Determinations about whether a particular sandbox, proxy or credential arrangement meets a contractual, regulatory or internal 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 registry and its own token, repeated after each release.

What the record shows

The record answers the title in one sentence: yes, if the substitution happens outside the process. Docker documents a host proxy that writes the auth header while the sandbox holds a sentinel, for local sandboxes and with a passthrough exception. Anthropic documents a mask mode that does the same for sandboxed Bash commands on listed hosts, with file tools and tool servers outside the sandbox. Both designs keep the string away from the agent, and neither changes what the agent reads on a rendered page, which is where a token displayed in a settings screen enters the context. RedactSure's control sits at that screen. Testing a setup takes one agent, one task and one credential: run the task, then ask which component held the string, which destinations received it, and whether the value ever appeared in a transcript or on a page the model read.

Frequently asked questions

Can credentials stay outside the sandbox and still be used inside it?

Yes, when the request leaves the sandbox with a placeholder and a component outside the sandbox attaches the real credential. A proxy on the host can write the authorization header, a local proxy can substitute the value for listed hosts, or a platform gateway can apply it as traffic passes through. The sandbox never holds the string, and the model driving the job sees the placeholder. The arrangement covers the routes it is configured for, not every file or page the agent can open.

Does Docker keep the credential outside the sandbox?

For the credentials its proxy manages, yes. The credentials page states that the real credential stays on the host and the sandbox sees a sentinel, and that a proxy on the host overwrites the authorization header. Two limits sit on the same page: a kit with passthrough set to true sends the real token response into the sandbox, and the documented flows apply to local sandboxes. Check the kit configuration and the environment before relying on either. The page is worth reading in full before a kit is installed.

Does Claude Code mask a credential for the whole session?

No. Masking applies to sandboxed Bash commands, which see a sentinel while a local proxy substitutes the real value for hosts in injectHosts. Read, Edit, Write, WebFetch, WebSearch, MCP servers and hooks run outside the sandbox, so a credential that also sits in a file the agent can open still enters the context. A Read deny rule is the documented control for that path, and a .claudeignore file has no effect.

What happens if the agent can read the file that holds the credential?

Then the value is in the model's context, and a proxy's substitution does not undo it. The documentation is explicit that a deny entry does not stop the Read tool, that Read follows permission rules, and that a command reading files without naming them, such as a recursive grep, sits outside those rules. Move the file out of reach, add a permission rule for its path, and check which routes remain open.

Is a host proxy enough on its own?

For the requests it manages, yes, and for everything else it is silent. A proxy decides what happens to a credential as a request leaves the sandbox; it does not decide what a settings page renders, what a tool server returns or what the agent reads from a mounted file. Treat the proxy as one control on one path, and test the other paths separately before treating the arrangement as covered.

What should a team ask before trusting a sandbox with a credential?

Four questions: which component holds the real value; which hosts or destinations may receive it; what the agent's own file tools and tool servers can still reach; and what record shows who approved the action. The answers separate a documented custody design from a configuration that quietly reopens the boundary. Ask for the record of one run, then repeat the test after the next release; RedactSure's environment is one place those answers are designed to be visible.

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 Publish Token Out of the Model's Context

A placeholder can sit in a request or on a page, and the designs above stop at the request or the shell command, before what the agent reads.

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

Before: the agent opens a package registry's token settings page, reads the publish token, and the string is in its context for the rest of the run. Inside the governed environment: the settings page renders PUBLISH_001, and the real value reaches the registry only when a named person approves.

RedactSure is deploying now with enterprise and government customers. GitGuardian found 3.0 valid credentials for one prompt on average.

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

See it on your own workflow

Keeping the publish token out of the sandbox only helps if the release still goes out. Bring a release task your team runs and see, with test values, what the model reads on the registry's token page. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.