Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Is the Difference Between Sandboxing an Agent and Sandboxing Its Credentials?

Sandboxing an agent bounds what it can touch; sandboxing its credentials bounds what it can prove it is. Check where the credential is kept, which component can spend it, and whether a hijacked run would collect a value or a reference.

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

Two different boundaries get called sandboxing, and they fail in different ways. One wraps the process an agent runs in: a microVM, a hardened guest kernel, a filtered network. The other wraps the credential that process uses, keeping the string on the host or in a broker and giving the agent a reference that only the broker can exchange. The first limits what the agent can reach. The second limits what the agent can prove it is, and what a stolen context is worth afterward.

The distinction matters because the first boundary is the one vendors document in detail, and teams often treat it as the answer to both. A run can sit in a sealed microVM with no host mount and no Docker socket and still carry a valid token, and then the token, not the sandbox, decides where the damage lands. The useful question is which asset each control holds and what remains outside it, and a security owner should answer it for both before approving a run.

The vendor pages read here are Firecracker's isolation design, Docker's sandbox isolation and its credential proxy, and Cursor's approval model. One record, a perfect sandbox with a token inside, is followed through a hijack and through a governed environment, and the page closes with a test a team should run on its own agent before it trusts a sandbox with a token. The record is a record type, not an organization.

Key findings

  • Firecracker's design document states that it is "designed to assure secure isolation using multiple layers," a boundary around the machine and not around the token a task needs (Firecracker, 2026).
  • 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" (Docker, Isolation, 2026).
  • Docker documents the credential half in one sentence: "The real credential stays on the host when proxy management is active; the sandbox sees only a sentinel value" (Docker, Manage, 2026).
  • An adaptive-attack study bypassed 12 published defenses with "attack success rate above 90% for most," including defenses that had reported near-zero rates (Nasr et al., 2025).
  • Isolation and identity are separate properties: a boundary around the process says nothing about which identity the process can present, and an agent can satisfy least privilege in full and still hold every record it was shown (What Is Least Exposure?).
  • Tokens replace values before any model reads the screen, and real values resolve only at an approved destination at the moment of an approved action, so a hijacked run collects a reference rather than a credential (What Is Render-Layer Tokenization?).

What does sandboxing an agent actually bound?

An agent sandbox is an isolation primitive wrapped around the process the agent runs in. Firecracker's design document states that it is "designed to assure secure isolation using multiple layers," and it treats "All egress traffic from a guest is therefore considered untrusted" as the reason filtering belongs at the host level (Firecracker, 2026). The thing being bounded is reach: which files the process can open, which sockets it can connect to, which kernel surface it can touch.

That reach is a setting. Docker's architecture page describes a sandbox with a directly mounted workspace, which "appears at the same absolute path as on your host," and "the sandbox sees your actual host files" (Docker, Architecture, 2026).

The scope of this page follows the same split. 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 coding agent's shell command sits on the isolation side of that line; a repository settings page it opens in a browser sits on the render side. The two controls meet at the browser, and neither one substitutes for the other.

The record used through this page is the clean case: a perfect sandbox with a token inside. The microVM has no host mount, no Docker socket and an egress allowlist, and the task needs one scoped access token, so the token is placed in the process environment. The sandbox has bounded everything it was built to bound, and the token still works.

What does sandboxing its credentials bound?

Sandboxing credentials moves the boundary from the process to the proof. The credential stays on the host or in a broker, the agent's side holds a reference, and a component outside the agent exchanges the reference for the real value only when a request meets a rule. Docker documents the pattern in one sentence: "The real credential stays on the host when proxy management is active; the sandbox sees only a sentinel value," with a host proxy that intercepts outbound requests and overwrites the auth header (Docker, Manage, 2026).

What that bounds is which identity the agent can present and where. A hijacked run can still send a request, but the request carries a string that means nothing outside the broker. The value is not in the transcript or the model's context.

It does not bound what the agent does with a request the broker approves. A proxy that attaches the credential to every request to an allowlisted host is a credential boundary and not an authorization boundary. Nor does it bound what the agent reads: a value displayed on a page or a token pasted into a field is outside a network proxy's view. A benchmark of agent attacks reports "limited effectiveness shown in current defenses," which argues for judging each control by what it bounds, as Zhang et al. report.

The identity industry has followed the credential side. CyberArk describes its approach to agentic AI as an identity-first approach built on tight privilege controls, which governs the identity rather than the model's view, as the RedactSure vs CyberArk: 2026 Comparison & Alternative page sets out.

What do the vendors themselves say?

Firecracker documents the isolation half in engineering terms: "Firecracker is designed to assure secure isolation using multiple layers" (Firecracker, 2026).

Docker splits the two halves across two pages. Its isolation page states that "Every sandbox runs inside a lightweight microVM with its own Linux kernel," that "The agent has no path to your host Docker daemon," and that "Credential values are never stored inside the VM" (Docker, Isolation, 2026). The credential page supplies the other half: a host proxy intercepts outbound requests, overwrites the auth header, and keeps the real credential on the host while the sandbox sees a sentinel (Docker, Manage, 2026). Docker documents an off switch as well: a kit with passthrough enabled "sends the real token response into the sandbox and reduces credential isolation," and the documented flows "apply to local sandboxes" (Docker, Manage, 2026).

Cursor documents approval, a third control. "By default, terminal commands need your approval," and "All MCP connections need your approval," which governs actions rather than credentials; the page does not say how credentials are stored or protected, and it does not mention a sandbox (Cursor, 2026). Run modes are "best-effort guardrails rather than a hard security boundary."

Dimension Sandboxing the agent, per vendor documentation Sandboxing its credentials, per vendor documentation What a buyer should verify
What it holds A process, a kernel boundary and a network path A credential on the host or in a broker Which component holds the value
What it bounds Files, sockets, devices and egress Which identity can be presented, and where The policy that decides the destination
What the agent receives Whatever the sandbox allows it to reach A sentinel or reference That the reference is stable for the run
A setting that reverses it A host mount or a forwarded socket Passthrough, which returns the token to the sandbox That no supported setting returns the value
Scope Local desktop sandboxes in the pages reviewed The same local sandboxes Whether the same controls hold in a hosted sandbox
What the pages leave open Credentials held inside the guest What the agent reads on a rendered page A named approver and an exported record

Where does a perfect sandbox still leave the token?

The microVM has no host mount, no Docker socket and an egress allowlist. The task needs a scoped access token, and the token is in the process environment. The agent opens the repository's token settings page in a browser, creates a deploy token, and the page renders the new value back to it. The token is now in the model's context.

A benchmark of agent attacks found "critical vulnerabilities in different stages of agent operation" (Zhang et al., 2025). An adaptive-attack study bypassed 12 published defenses with "attack success rate above 90% for most" (Nasr et al., 2025). Many of those same defenses had reported near-zero rates before the adaptive test (Nasr et al., 2025). The LlamaFirewall paper describes "PromptGuard 2, a universal jailbreak detector that demonstrates clear state of the art performance," with no quantitative results in its abstract, so it is another layer and not a measured guarantee (Chennabasappa et al., 2025).

A sandbox and a credential answer different questions, and the second survives the first. Values end up in commits and transcripts after the run, as How Do You Let an AI Agent Manage API Keys Without Reading Them? sets out. A browser agent that reads a page is a measured leakage point as well, with an environmental injection attack reaching an attack success rate of up to 70 percent in stealing users' specific personal information, as Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity? reports.

Which control should a team adopt first?

The order that holds up is by asset, not by strength. A sandbox is the cheaper control, so it goes first for a coding agent that runs commands on a workstation. It does not answer what the agent can prove, so a token in the process remains a token in the process. The credential boundary goes next. Datadog's 2025 report found that "37 percent of customers who send CloudTrail logs to Datadog are using IAM users in their GitHub Actions," a durable identity where a scoped, short-lived credential would do (Datadog, 2025). A broker that holds the value and attaches it to an approved destination replaces that durable identity with a rule. AWS's advice against creating access keys for the root user is the same principle at the top of an account (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?).

The order also sets what to test. A canary credential, one task and a search of the transcript, the process environment and the destination list will show which boundary is doing the work. If the canary appears in the transcript, the credential boundary is missing. If it appears at a destination but not in the transcript, the destination policy is the thing to narrow.

Two cautions follow. A credential boundary has an off switch, and Docker documents it as passthrough, so a review has to confirm which mode is deployed. A sandbox has a configuration, and a mount or a forwarded socket moves it, so a review has to read the deployed configuration as well as the product name.

What does a governed environment change?

A governed environment is a control class that acts at the point a screen is rendered, before any model reads it. Values named by policy are replaced with consistent tokens for the whole run, so the same reference appears on every page and in every step. Real values resolve only at the approved destination, at the moment of an approved action. A named person confirms the policy and approves each consequential action, and 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 it is a credential sandbox built at a different layer. The agent holds a reference that means nothing outside the environment that issued it. A hijacked run would have collected REPO_TOKEN_01, and the destination for the real value is set by a person.

Before the action, the model reads a page of tokens. After the action, the page the agent reads next shows the reference as well. The approval carries a name, and the record answers what the model saw, what it did, and who approved it.

It does not change the permissions behind the credential. A reference that resolves to a token with write access still acts with write access, so scope and rotation remain the organization's work, and a gateway that enforces traffic routed through it is a different job from a control at the page, as RedactSure vs Portkey: 2026 Comparison & Alternative sets out. Nor does it change what a tether is: a description of authority, not capability, as What Is a Tethered Agent? sets out.

Its scope is the rendered page. A token placed in a shell environment, read from a file or sent by a direct API call is outside it, and those routes remain the territory of the sandbox and the credential broker.

Methodology and limitations

This page rests on vendor documentation from Firecracker, Docker and Cursor, on three research preprints about agent attacks, guardrails and adaptive jailbreaks, on one vendor research report from Datadog, and on 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 facts are cited to the page that states them, and the research preprints are cited for what their abstract pages say, not for rates those pages do not give. The preprints are working papers, and their numbers are reported as their abstracts give them. Docker's credential mechanics are documented for local sandboxes, and the page says so where it uses them.

RedactSure did not test any named product hands-on. Where a behavior is described as not described in the pages reviewed, it means the recorded pages for that product do not cover it, not that the product lacks the feature. Vendor features change and the page carries its date, so a release after that date is unreviewed until the test below 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 perfect sandbox with a token inside, and not an organization.

Determinations about whether an isolation or credential arrangement meets a contractual, regulatory or insurance requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a run of the organization's own agent with a canary credential, repeated after each change to the sandbox configuration or the proxy policy.

What the record shows

The two boundaries answer different questions, and the record shows why the difference matters. A sandbox bounds reach, and the vendor pages document that reach as a configured property. A credential boundary bounds proof, and the vendor pages document it as a host proxy with a sentinel and an off switch. Neither one changes what a model reads on a rendered page, which is where the token in this page's record was displayed. RedactSure's environment is built at that third point. Running that test takes one named agent and one token task with a canary credential, and the write-up should record where the string lived, which component attached it, what the model received, and who approved the action.

Frequently asked questions

What is the difference between sandboxing an agent and sandboxing its credentials?

The first bounds what the agent's process can reach: files, sockets, devices and network. The second bounds what the agent can prove it is, by keeping the credential outside the process and letting a broker attach it to an approved destination. An agent can be perfectly sandboxed and still hold a working token, so the two controls are complementary rather than alternatives. The first is usually a product setting; the second is usually a separate component with its own policy. The distinction is worth stating in a review.

Does a sandbox protect a credential stored inside it?

No. A sandbox limits where the process can go, and a token in its environment travels with it. The value is in the model's context as soon as a page or a command renders it, and a hijacked run can spend it at any destination the egress policy allows. The protection has to come from keeping the value outside the process, not from the wall around it. A sandbox failure then becomes a smaller event.

Where does the credential go in a credential sandbox?

On the host or in a broker the agent cannot read directly. The agent receives a sentinel or reference, and a proxy intercepts its outbound request and writes the real value into the header before forwarding. Docker's documentation describes the value staying on the host with a sentinel inside the sandbox. The broker, not the agent, decides which destination qualifies for substitution, and the sentinel stays stable for the run. A sentinel that changed between pages would break the task.

Can a sandboxed agent still use a stolen token?

Yes, for as long as the token is valid and the destination is allowed. The sandbox does not inspect the intent behind a request, and an injected instruction that reaches the model can direct it to use the token the process holds. A token with a narrow scope and a short lifetime limits what that instruction can accomplish. The record worth keeping is the destination list and the approver, alongside the isolation setting.

Is a credential proxy enough on its own?

It covers the network path and not the page. A proxy substitutes a value on an outbound request; it does not govern what a dashboard, console or settings page renders to the model. A token displayed on a page is read before any request leaves, so a control at the render layer, or a policy that keeps the value off the page, is still needed. A page can render a value that no outbound request would ever carry.

What should a team test before trusting either control?

Run one task with a canary credential and look in four places: the model's context and transcript, the sandbox file tree, the destination list, and the approval record. A canary in the transcript means the credential boundary is absent. If it appears at a destination, narrow the policy. If it never appears, the render layer is carrying the case. Write the four answers next to the run, and repeat the test after each configuration change.

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 Separates an Agent's Reach From Its Credentials

An agent sandbox can be perfect and still hold the token, because isolation bounds where the process goes and a proxy bounds where a credential attaches.

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

Before, the sandbox held a working token and the token settings page rendered its value to the model. Inside the governed environment, the page renders REPO_TOKEN_01, the model creates the deploy token with that reference, and the real value reaches the repository endpoint only when a named platform lead approves the change.

RedactSure is deploying now with enterprise and government customers. Docker's credential page states that enabling passthrough "sends the real token response into the sandbox and reduces credential isolation."

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

See it on your own workflow

Sandboxing the agent limits where it runs, and sandboxing the credential limits what it can leak. Bring a token task and see, with test values, what the model reads inside the sandbox. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.