Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Does Running a Coding Agent in Docker Protect My Credentials?

No, not in plain Docker, because a container protects the host from the agent while anything mounted into it or set as an environment variable sits inside with the agent. Docker Sandboxes with the sentinel swap is a different product, and it keeps the credential on the host; check which of the two you are running.

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

Engineering leaders who approve a coding agent inside Docker are often signing off on a boundary around a process, not around a credential. The container keeps the agent's work away from the host's daemon, its home directory and its other services. It does not keep the agent away from whatever the team puts inside the container, and a coding agent is usually given something: a working tree with a .env file, a registry token in the environment, a config file with a database password. Anything inside is readable by the agent, and anything the agent reads its model receives. The real choice is between a container that holds the credential and a design that keeps the credential on the host and gives the agent a placeholder. Shadow adoption makes the choice urgent: a Cloud Security Alliance research note reports that eight in ten employees use AI tools not approved by their organizations, so a container is often the only boundary an unsanctioned agent sits behind (How Do You Keep Data Access Policies Consistent Across AI Tools?). This means the security owner should decide which credentials enter the container before the agent does, and the sections below check that decision against what the container isolates, what a mounted .env exposes, what Docker and NVIDIA document about placeholders, what a sentinel leaves open, and what still reaches the model.

Key findings

  • Docker's Sandboxes documentation states that "Every sandbox runs inside a lightweight microVM with its own Linux kernel" and that "The agent has no path to your host Docker daemon," which is a boundary around the host rather than around the values the agent is handed (Docker, Isolation, 2026).
  • Docker's credentials page states that "An HTTP/HTTPS proxy on your host intercepts outbound requests from the sandbox" and "overwrites the auth header before forwarding," so the real value is applied on the host side of the boundary (Docker, Manage, 2026).
  • NVIDIA's OpenShell guidance states that "The agent receives an opaque placeholder, not the real API key or access token," a design that keeps the string out of the sandbox while the request still leaves it (NVIDIA, 2026).
  • SecretBench is "a labeled dataset of source codes containing 97,479 secrets (of which 15,084 are true secrets)," the population that a mounted .env file joins (Basak et al., 2023).
  • A governed environment replaces a value with a consistent token before any model reads the screen, so an agent working a settings page holds TOKEN_001 and never the string (What Is Least Exposure?).
  • Real values resolve only at the approved destination at the moment a named person approves the action, and the approval ties the run to the person who set the agent up rather than to the agent (What Is a Tethered Agent?).

What does running a coding agent in a container actually isolate?

A container separates one process tree from the rest of the machine: its own filesystem layer, process table and network namespace, with the host's Docker daemon and home directory outside the boundary. It limits what the agent can damage on the host, and it limits what a compromised dependency can reach there.

The seam shows in the same product. Docker's architecture page states that "A directly mounted workspace appears at the same absolute path as on your host" and that "The sandbox sees your actual host files, so changes in either direction are instant with no sync process involved" (Docker, Architecture, 2026). A workspace mounted that way is inside the boundary by construction, which is the decision a team makes when it wants the agent to edit the project.

Vendor engineering on agent sandboxing describes the same containment: effective sandboxing requires both filesystem and network isolation, and sandboxing safely reduced permission prompts by 84 percent, a measure of what stayed off the host rather than of what the model was shown (Does Sandboxing an Enterprise AI Agent Protect Your Data?).

The scope then needs saying in plain words. A governed browser environment covers what the agent reads and does on a rendered page: dashboards, consoles, settings pages and sign-up forms. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A container is a different layer, on the other side of that line.

What is inside the container once a .env file is mounted?

A .env file is a plain list of name and value pairs, and a coding agent is usually given one so it can run the project. Mount the working tree and the file arrives with it. The agent opens it, the value enters the model's context, and from then on it sits wherever the agent's reasoning goes: the prompt, the summary, the patch, the transcript. The container did nothing, because the file was placed inside on purpose.

The protection runs the other way. Docker's architecture page states that "All outbound TCP traffic from the sandbox routes through a proxy on your host," which is the hook a credential design uses and also the place where a substituted value re-enters the request (Docker, Architecture, 2026). A proxy can mediate the traffic it sees, and it cannot unsee a value the agent read from a file in the mounted tree.

Masking in CI shows the same limit. GitLab's documentation states that "When a job outputs the value of a masked variable, the value is replaced with [MASKED] in the job log," and warns that "Masking a CI/CD variable is not a guaranteed way to prevent malicious users from accessing variable values" (GitLab, 2026). A mask is applied at the point of output, and a value the agent already holds is beyond it.

Agent tooling repeats the pattern: a coded agent is deployed as a UiPath process within Orchestrator folders and receives its credentials as environment variables, which puts the credential inside the sandbox with the agent rather than outside it (Does Sandboxing UiPath AI Agents Protect Sensitive Workflows?).

Where the value sits Container with a .env mounted Sandbox that hands the agent a sentinel
The file Inside the container, readable by the agent Outside the sandbox; the agent never reads it
The environment A name and value pair the process can print A placeholder such as TOKEN_001
An outbound request The real value, if the agent puts it in the request The real value applied on the host proxy
The transcript Whatever the model read, in full The placeholder, which is useless elsewhere
After the run A value to rotate A value that never entered the run

That is the answer for this record type. The container decides what the agent can reach on the host, and the .env decides what the agent can read. The first is isolation and the second is exposure, and mounting a file is a choice about the second.

What do the vendors themselves say?

Docker's isolation page describes a lightweight microVM with its own kernel and no path to the host's Docker daemon, which is a boundary around the host rather than around the agent's reading. Read the credential sentence on that page carefully, because it is narrower than it appears. The isolation page adds that "Credential values are never stored inside the VM," a statement about the microVM's own storage and not about a value the team has just placed inside it (Docker, Isolation, 2026).

The mechanism the title's second product is built on is on that page. The credentials page states that "The real credential stays on the host when proxy management is active; the sandbox sees only a sentinel value," and that these flows "apply to local sandboxes" (Docker, Manage, 2026). A sentinel covers the credentials the proxy is configured to inject, which is a smaller set than every value the agent can open.

NVIDIA's guidance describes the same design for its own sandbox. The same guidance states that "Every outbound connection from the sandbox goes through the CONNECT proxy" and that "Each allowed endpoint is a potential data exfiltration path," so a placeholder protects the value and still leaves the request (NVIDIA, 2026).

Dimension Docker Sandboxes, per its documentation What a buyer should verify
Isolation unit A lightweight microVM with its own Linux kernel Whether the cloud product behaves the same way
Host access "The agent has no path to your host Docker daemon" What else is mounted into the sandbox
Workspace A directly mounted workspace appears at the host's absolute path Whether a .env or key file sits in that tree
Credential custody Real value on the host, sentinel in the sandbox, header written by the proxy Which credentials the proxy manages, and which the agent can read
Outbound path All outbound TCP through a host proxy Which endpoints are allowed
Passthrough kits The real token response is sent into the sandbox Whether any kit in use sets passthrough to true
Per-run record No per-run record is described on these pages What the vendor can show a reviewer afterward

The table is the vendor position in one view: the boundary and the credential design are documented in detail, and the file the agent reads sits inside the boundary the documentation describes.

Does a sentinel keep the credential outside the microVM?

For the credentials a proxy manages, yes. The value stays on the host and the sandbox presents a sentinel that the proxy replaces as the request leaves. The limit is in the same documentation. The same page says that a kit with passthrough: true "sends the real token response into the sandbox and reduces credential isolation," which is the configuration that puts the string back inside (Docker, Manage, 2026). A team that installs a kit for an unusual service can undo the property it bought.

Two other qualifications matter. First, the documented flows apply to local sandboxes, so whether a cloud sandbox behaves the same way is not described in the pages reviewed. Second, the sentinel covers the credentials the proxy is configured for; it does not cover values the agent reads from a page, because those never pass through an auth header. A repository settings page that renders a deploy key is the simplest example: the key is on the page, so the model receives it. GitHub tells users to treat access tokens like passwords and offers fine-grained tokens limited to specific repositories, as What Can an AI Agent See in Your GitHub Settings? sets out.

That distinction is where the title's two products separate. A sentinel is custody of a credential at the moment of use. Exposure is what the model was shown before the use, and the two are measured at different points: one at the proxy, one at the screen.

What still reaches the model once the container is isolated?

Everything the agent can read on the pages it renders and the files it opens is what the container was never asked to govern. Willison's design patterns "constrain the actions of agents to explicitly prevent them from solving arbitrary tasks," and one holds that "Agents can trigger tools, but cannot be exposed to or act on the responses from those tools" (Willison, 2025). That is a statement about tools, not screens: an agent reading a settings page has already been exposed to it.

The LlamaFirewall paper describes "PromptGuard 2, a universal jailbreak detector that demonstrates clear state of the art performance," with no rate in the abstract to check it against (Chennabasappa et al., 2025). A detector that catches most injections still leaves open what the model holds when one gets through.

The code the agent writes adds a second exposure. Veracode's release states that "Our research reveals GenAI models make the wrong choices nearly half the time, and it's not improving," and puts Java's security failure rate at "over 70 percent" (Veracode, 2025). The question is narrower: for one task, which values does the model receive? Google tells Workspace administrators that the super admin account should be used only when needed, and that rule, written for people, applies with more force to an agent (Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool?). A key the task does not need should not be in the tree. The cloud case, where the credential is the account, is covered in Is It Safe to Let an AI Agent Set Up Your Cloud Environment?.

What does a governed environment change?

It moves the control from the network path to the render layer. A governed environment is a control class that sits where a screen is drawn, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works on placeholders such as PATIENT_001 or ACCT_001 and sees the same token 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; the approval is a record with a name on it, not a rule the agent applies to itself. Every screen as tokens, every action and every approval is written to a record the organization can export to its own monitoring.

For this page's question the change is specific. A container controls what the agent can reach on the host, and the vendor designs reviewed above show that a value read from a mounted file stays inside whatever the container holds. A governed environment controls what the agent is shown, so the value can stay in a store while the agent works on a token and the real value travels only to the destination a person approved. The two controls answer different questions, and a team can run both.

The limits are worth stating. The scope is the rendered page, so a value the agent reads through a shell command or an API call in its own process is governed by the sandbox and the credential store, not by this. And a token is only as useful as the policy behind it: a policy that tokenizes nothing leaves the screen as it was.

Methodology and limitations

This page rests on vendor documentation from Docker, NVIDIA and GitLab, two research preprints on software credentials and on guardrail systems, one press release about generated code, one practitioner analysis of agent design patterns, and existing RedactSure research pages. 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, and figures from the press release and the preprints are reported as those pages state them, not as independently measured. Where a vendor page describes local behavior, the page says so rather than extending it to a cloud product.

RedactSure did not run a coding agent in Docker or in a Docker Sandbox for this page. The Docker pages describe local sandboxes, and whether the cloud product behaves the same way is not described in the pages reviewed; a reader should treat a release after the read dates as unreviewed until the check 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 container with a .env mounted set beside a sandbox that hands the agent a sentinel, and not an organization.

Determinations about whether a particular container configuration, credential or agent deployment 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 workspace, repeated after each release.

What the record shows

For a team signing off on a containerized agent, the record answers the title in two parts. Plain Docker separates the agent's processes from the host, and the documentation says so in plain terms: a microVM boundary, no path to the host daemon, a mounted workspace that mirrors the host's paths. None of that touches the file the team mounts, and a value in that file is in the model's context as soon as the agent opens it. The second product, the one with a proxy and a sentinel, keeps the credential on the host for the requests it manages, and its own documentation lists the exception: a passthrough kit sends the real token into the sandbox. A team can therefore run a coding agent in a container, pass an audit, and still be unable to say what the model read. Before signing off, test one agent, one task and one mounted workspace, and trace which values the model received and who approved the action that used them.

Frequently asked questions

Does running a coding agent in Docker protect my credentials?

A plain container protects the host, not the credential. It keeps the agent's processes away from your Docker daemon, your home directory and other services, which is real protection for the machine. It does not keep the agent away from a .env file you mount into the workspace or a token you set as an environment variable; those are inside the boundary with the agent, and the model reads whatever the agent reads. The boundary and the credential are two different questions.

Is Docker Sandboxes the same thing as Docker?

No. Docker Sandboxes is a separate product built around a lightweight microVM, and its credential handling is different: a proxy on the host intercepts outbound requests and writes the auth header, so the sandbox sees a sentinel instead of the real value. The documentation says these flows apply to local sandboxes. Whether a cloud sandbox behaves the same way is not covered on those pages, so confirm which product and environment you have before relying on it.

Does a mounted workspace still reach the agent?

Yes, by design. Docker's architecture page says a directly mounted workspace appears at the host's absolute path and that the sandbox sees your actual host files, with no sync process in between. That is convenient when the agent must edit the project. It also means a .env, a key file or a credentials file in that tree is inside the boundary, and the agent reads it the way it reads any other file. Keep such files outside the mounted tree or accept that they are inside.

Does masking an environment variable keep it out of the transcript?

Masking is applied where output is produced, not where values are stored. GitLab's documentation says a masked value is replaced in the job log and warns that masking is not a guaranteed way to prevent malicious users from accessing variable values. In an agent run the transcript is written from the model's context, so a value the model already read is in it whether or not the shell masks it later. Masking narrows one output path and not the context.

What should I check before mounting a .env file?

Ask which values the task needs, and whether any of them can be replaced with a placeholder. The record is the useful test here: the file, the environment, the outbound request and the transcript. If a value appears in the first two and the task does not need it, take it out. Rotate anything the agent has already read. This is the cheapest control on the page, and it requires no product.

Can an agent do the work without ever reading the credential?

Yes, if the value is applied outside the agent's view. A proxy can write the auth header for a request, a sandbox can hold a placeholder, and a governed environment can render a token on the page and resolve the real value at the approved destination. Each design changes where the value lives, not what the agent is asked to do. The differences show up in what the model holds and what a reviewer can see afterward; RedactSure's environment is built on the last of these.

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 Mounted Workspace From Handing Over the Key

A container limits what the agent may touch on the host, and the proxy designs reviewed assume the value was never in a file the agent opens.

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

Before: the agent opens a repository's deploy key settings page, reads the key rendered there, and pastes it into the pipeline. Inside the governed environment: the page renders DEPLOY_KEY_001, and the real key reaches the one destination a named person approved.

RedactSure is deploying now with enterprise and government customers. Veracode reports models making the wrong choices nearly half the time.

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

See it on your own workflow

A container keeps the agent off your host, but the settings pages it opens still show keys. Bring a deploy key task you run in Docker and see, with test values, what the model reads. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.