Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Does Docker Sandboxes Protect a Browser Agent?
No; Docker Sandboxes isolates the process and its network and keeps the real credential on the host, while the model still receives whatever the portal renders on the screen the agent drives. Ask what the model is shown on a page, and who approves the action that follows.
No. An agent that signs into a supplier portal from inside a Docker sandbox sits behind three documented walls: a microVM with its own Linux kernel, a host proxy that carries every outbound connection, and a credential the documentation keeps on the host. None of the three sits between the model and the page. The portal draws the invoice, the remittance account and the supplier's address, and the browser hands the page to the model that chooses the next step. Docker's Sandboxes credentials page is precise about the request layer, where the proxy "intercepts outbound requests from the sandbox" and "overwrites the auth header before forwarding" (Docker, Credentials, 2026). The isolation pages describe the machine and the network; neither describes a step that reads a page's values. The supplier's application decides what that page shows, and the model reads all of it, including the account number the payment will be sent to. For a finance team that wants an invoice read and a payment queued, the gap matters: the account number the agent needs is the value an injection would collect. What remains is what the model was shown while it held.
Key findings
- For a browser agent inside a Docker sandbox to be safe on a portal that carries bank details, the values on the rendered page would have to be replaced with consistent tokens before the model reads the screen, with real values released only at the approved destination (What Is Render-Layer Tokenization?).
- It would also require a named person approving each payment, submission or record change, with a record of what the model received on every screen, because the sandbox decides where the process runs and not what it read (What Is Supervised Delegation?).
- Docker's Sandboxes documentation does not state that the values a page renders are replaced before a model reads them; its pages describe a lightweight microVM, a host proxy and a credential sentinel, and none of the three covers the page a browser agent reads (Docker, Isolation, 2026).
- Every sandbox runs inside a lightweight microVM with its own Linux kernel, and credential values are never stored inside the VM, a boundary around the host rather than the page the agent reads (Docker, Isolation, 2026).
- All outbound TCP traffic from the sandbox routes through a proxy on your host, so the network is accounted for while the page still reaches the model in full (Docker, Architecture, 2026).
- AgentDAM's evaluation found that web agents are prone to inadvertent use of unnecessary sensitive information, so on a portal the whole page reaches the model even when the task needs two fields (Zharmagambetov et al., 2025).
Where does the wall sit, and where is the screen?
Start with what the Sandboxes pages document. The isolation page states: "Every sandbox runs inside a lightweight microVM with its own Linux kernel." It adds: "The agent has no path to your host Docker daemon" and "Credential values are never stored inside the VM" (Docker, Isolation, 2026). The architecture page states: "All outbound TCP traffic from the sandbox routes through a proxy on your host" (Docker, Architecture, 2026). The boundary is around the host: the agent cannot reach the daemon, and the traffic leaves through a proxy the host controls.
The screen is inside that boundary. The portal's HTML, the values in its fields and the session the browser holds all live inside the sandbox with the agent. A boundary that decides where code runs and what traffic leaves answers a different question from what the model reads. The Columbia lab draws the distinction: agents turn every layer of the stack into a semantic quality problem, and trustworthy agent automation cannot be solved at a single layer of the stack (DAPLab, 2026).
Both layers matter. The sandbox makes the run survivable: a compromised agent cannot reach the host daemon. The rendered page decides what the compromise collects, and the recorded case here is an agent driving a supplier portal with the invoice open and a payment waiting for approval (Does Sandboxing an Enterprise AI Agent Protect Your Data?).
What does the model read when the agent drives a portal?
The record is an agent that signs into a supplier portal inside a Docker sandbox, opens one invoice and queues a payment for approval. The login leaves the browser holding a live session with the supplier. The invoice page renders the supplier's name, the remittance account, the invoice number and the payment button. The agent needs two fields, and the model receives the page.
That is how a browser agent works. The page is the input, and every field on it is in the context before the model chooses a click. AgentDAM's evaluation of web agents makes the point in its own words: web agents "are prone to inadvertent use of unnecessary sensitive information" (Zharmagambetov et al., 2025), and a portal is where that tendency has the most to work with: the record the agent needs shares a screen with the account it does not.
EchoLeak's account of CVE-2025-32711 in Microsoft 365 Copilot describes a client that "automatically fetches the external image URL included by the attacker," with an allowed Teams endpoint used to get past the content security policy (Reddy and Gujral, 2025). The defenses do not hold: The Attacker Moves Second tested 12 published defenses against jailbreaks and prompt injections and measured an "attack success rate above 90% for most" (Nasr et al., 2025). A sandbox changes where the fetch happens and not whether the model read the page that carried it.
A team can check this: capture the rendered invoice and the model's context where it reads the remittance account, then compare the two. The isolation page's promise is that the agent cannot reach the host, and nothing in the pages reviewed says the page was filtered (Who Controls What an AI Agent Sees in a Hosted or Sandboxed Browser?).
What do the vendors themselves say?
Docker's credentials page draws the boundary at the request layer. It states: "An HTTP/HTTPS proxy on your host intercepts outbound requests from the sandbox" and "overwrites the auth header before forwarding" (Docker, Credentials, 2026). The page states the result plainly: "The real credential stays on the host when proxy management is active; the sandbox sees only a sentinel value" (Docker, Credentials, 2026). The same page documents an exception: a kit with passthrough: true "sends the real token response into the sandbox and reduces credential isolation." The page also bounds the design, because these flows "apply to local sandboxes" (Docker, Credentials, 2026).
The pages on the machine draw the same boundary: the host, its daemon, its files and the credential the proxy holds are what the product protects.
| Dimension | Docker Sandboxes, per its documentation | What a buyer should verify |
|---|---|---|
| Where the boundary sits | A microVM per sandbox, with its own Linux kernel | Whether the browser and the agent share that sandbox |
| Credentials | The real value stays on the host and the sandbox sees a sentinel; a passthrough kit removes that isolation | Whether a passthrough kit is in use for this workflow |
| The rendered page | Not described on the credentials, architecture or isolation pages | What the model receives from a portal screen, and who approves the action |
| Record | Not described on those pages | What record shows the screen the model read |
A buyer who checks the first two rows finds a sandbox that does what it says. The last two rows decide whether the browser agent is covered.
What does the credential proxy cover, and what does the agent still read?
The proxy is the strongest part of the Docker design for an agent that calls an API. The host "overwrites the auth header before forwarding" and the sandbox holds a sentinel in place of the real value (Docker, Credentials, 2026). An agent can therefore call a service with a credential it never holds (Can a Coding Agent Use a Credential It Cannot Read?). A passthrough kit reverses that.
Neither covers the page. A rendered field in a portal's HTML is not an auth header. A session that a login created is a cookie the browser stores and sends, not a header the host rewrites. When the portal renders the remittance account after login, the proxy has already done its work on the connection.
The pattern is not Docker's alone: in the review of coding agents and sandboxes, all four sandbox products describe a placeholder or proxy that keeps the real value from the agent, and Docker Sandboxes is one of the two that document it by default (Can AI Coding Agents Read Your API Keys?).
The question is which values the model may read on a page it is allowed to open. Separate identities with limited scope decide which account the agent uses, and they do not decide which fields the supplier's page shows that account.
Authentication can be arranged so a person approves a fill the model never reads, and that release covers the fill and not the pages that follow (Can a Browser Agent Get Past Two-Factor Authentication Without Seeing My Codes?). The swap keeps a credential out of the guest, and the render layer keeps a value off the screen before the model reads it, so the session carries ACCT_001 in place of the supplier's account.
What does a governed environment change?
A governed environment acts where a page becomes readable. Values chosen by policy are replaced with consistent tokens for the whole run, so the portal draws ACCT_001 where the remittance account would be and the model works with the token (What Is Render-Layer Tokenization?). Real values resolve only at the approved destination, at the moment of an approved action, so the payment can be addressed to the real account without the number entering the model's context. A named person approves each payment, submission or record change, and every screen, action and approval is written to a record the organization holds (What Is Supervised Delegation?; What Is an AI Control Record?).
Inside the sandbox, the invoice page renders the account and the model reads it. Inside the governed environment, the same page renders ACCT_001, the agent queues the payment against the token, and the real number is attached at the bank's payment endpoint when the named approver releases it. The sandbox still contains the process, and the render layer decides what the process was shown.
None of this replaces isolation. It adds the layer that reads the same page before the agent does, and keeps a record of what it substituted. The category is set out in RedactSure vs Docker Sandboxes: 2026 Comparison & Alternative, where the process boundary and the render layer sit on one portal record.
What the record shows
The review turns on what the model received, not on where the process ran. A sandbox that keeps an agent off the host and puts every connection through a host proxy has done its work, and the invoice page still reaches the model with the remittance account on it. The conclusion from this page's record is narrow: the sandbox protects the machine and the credential at the request layer, and the documentation reviewed does not describe a control over the values a rendered page shows the model. A team can test that on one workflow. Open a staging supplier portal inside the sandbox, sign in with a test account, and let the agent read one invoice. Capture the screen the model received and the request log from the host proxy, then search both for the account number. If the number is on the screen, the control belongs above the proxy.
Methodology and limitations
This page rests on Docker's Sandboxes documentation for credentials, architecture and isolation, three research papers, AWS guidance, Harvard's generative AI guidance and the Columbia DAPLab page, with existing RedactSure research. Vendor pages were read between October 16, 2026 and October 21, 2026, and each Sources line carries the date for its page. Public documentation read in full gives a sound view of where each product applies its control.
No product named here was tested for this page, and "not described in the pages reviewed" means the pages reviewed. RedactSure is deploying now with enterprise and government customers. The example is a record type, an agent driving a supplier portal from inside the sandbox, not an organization. Regulatory determinations belong to counsel and the organization's compliance officers. Nothing here replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
Does Docker Sandboxes protect a browser agent?
No, not from what the page shows the model. Docker's pages document a microVM for each sandbox, a host proxy for all outbound TCP, and a credential that stays on the host while the sandbox sees a sentinel. Those controls bound where the agent runs and what it can reach. They do not filter the page the browser draws, and the model receives that page when it decides the next step. A sandbox that holds every property its pages claim still leaves the account number in the model's context.
What does the model receive when the agent opens a portal inside the sandbox?
The rendered page, including every field the portal draws: the supplier's name, the remittance account, the invoice number and the payment controls. The agent needs two of those fields and the model receives all of them. AgentDAM's evaluation found web agents prone to inadvertent use of unnecessary sensitive information, and a portal is a page where the unnecessary value is the one that matters.
Does the credential proxy keep the real token out of the model?
For an outbound request, yes: the host overwrites the auth header and the sandbox holds a sentinel, so the model never needs the real value. That is the case the credentials page documents. A page the portal renders is not an auth header, so the swap does not cover a remittance account drawn in a field after login. A passthrough kit sends the real token response into the sandbox and reduces that isolation.
Who approves an action the browser agent takes inside the sandbox?
No one, from the pages reviewed. The sandbox decides whether the process can reach the host and where its traffic goes; it does not put a named person between the agent and a queued payment. An approval is a decision about one action, recorded with a name. Docker's pages describe the boundary and the credential, not an approval step. A team that needs one has to add it at the workflow level, where the payment is released.
What record shows what the agent read inside the sandbox?
The pages reviewed describe no record of the screen. They describe the isolation layers, the proxy and the credential handling. A record that answers the question captures the page as the model saw it, with the action and the approver beside it. AWS's guidance puts the test for an agent record clearly: "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026).
Would running the browser outside the sandbox change what the model reads?
No, because the exposure follows the page and not the machine. Running the browser on the host, in a separate VM or in a hosted browser moves where the page is drawn; the model sits in the same place in each arrangement. Harvard's guidance lists seven risk categories for AI-enabled systems, and Sensitive Data Exposure is the first (Harvard, 2026). The control that changes the answer acts before the model reads the page.
How RedactSure Keeps a Portal's Account Number Off the Model's Screen
Docker's sandbox can keep an agent off the host and still hand its model every field a supplier portal draws. The Attacker Moves Second bypassed 12 published defenses against jailbreaks and prompt injections with an attack success rate above 90% for most (Nasr et al., 2025).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Today, the invoice page renders the remittance account, and the model reads it while the agent queues the payment. Inside the governed environment, the same page renders ACCT_001, the agent queues the payment against the token, and the real account number is attached at the bank's payment endpoint when a named person approves the release.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
The remittance account a portal draws stays in the model's context long after the payment is queued. Bring one agent task and see, with test values, what the model reads and where the real value lands. Book a demo