Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do I Keep Credentials Outside the Sandbox Where the Agent Runs?

Put the credential in a process on the other side of the boundary, which makes the call for the agent: the agent sends a request with a reference, and that process forwards it with the real value. Check where the value is stored, what the model received, and which hosts the proxy will attach it to.

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

For organizations handing API keys to agents, the sandbox is built to protect the host, and it does that by drawing a line around what the agent's process can touch. The credential a task needs usually sits on the wrong side of that line, because the simplest way to give an agent an API key is to place it in an environment variable, and an environment variable belongs to the process the sandbox contains. Moving the value out means giving the agent something else to send: a reference that a component on the host, or in a gateway the sandbox connects through, exchanges for the real value. The agent composes a request naming that reference, the component matches it, attaches the credential, forwards the request and hands back the response. One side holds a placeholder; the other holds the string.

Whether the exchange holds comes down to a few details, and each one decides part of the organization's exposure. A sandbox covers some things and leaves others outside, so that boundary comes first. One record, a webhook created on a repository settings page, shows the path from reference in to result out. The vendor projects document the mechanics, including the settings that undo them, and some exposure remains even with the value outside, so a team should run a test before it trusts the arrangement.

Key findings

  • Docker's Sandboxes documentation states that "An HTTP/HTTPS proxy on your host intercepts outbound requests from the sandbox" and "overwrites the auth header before forwarding," so the request leaves with a marker and receives the real value on the host (Docker, Manage, 2026).
  • NVIDIA's OpenShell guidance states that "The agent receives an opaque placeholder, not the real API key or access token" and that "Every outbound connection from the sandbox goes through the CONNECT proxy," which puts the only copy of the value in the gateway (NVIDIA, OpenShell Security, 2026).
  • A benchmark of agent attacks found "critical vulnerabilities in different stages of agent operation" and "limited effectiveness shown in current defenses," the argument for moving the value out of reach rather than adding another instruction (Zhang et al., 2025).
  • GitGuardian's test of Copilot reported that "Copilot generates 2702/900 = 3.0 valid secrets for one prompt on average," evidence that a value the model has read can come back out later (GitGuardian, 2025).
  • Tokens replace values before any model reads the screen, so the agent's request carries a reference, and real values resolve only at the approved destination at the moment of an approved action (What Is Least Exposure?).
  • A tether describes the agent's authority, not its capability, so a credential the agent may use is one its model can be steered into using (What Is a Tethered Agent?).

What does a sandbox protect, and what does it leave outside?

A sandbox is a boundary around the agent's process, not around the credential the process needs. Docker's 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," three statements about the host boundary and none about how a credential reaches a request (Docker, Isolation, 2026). A value in the VM's environment is inside with the agent; a value on the host has to be carried across on each call.

Two different controls meet at that line. The governed browser environment covers the pages an agent reads and acts on: 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 credential used in a shell, by a tool call, or by a coding agent's file read belongs to the proxy design described here, not to a browser control.

OWASP's LLM06:2025 entry describes excessive agency in terms of more functionality, permission or autonomy than a task requires, which is what a login that bundles workflow access with value access produces by construction (How Do You Give AI Agents Access to Workflows Without Exposing Sensitive Data?).

The record used through the rest of the page is a webhook created on a repository settings page: a form field that would hold a signing secret, and an API call that needs the value.

What does a reference in, a result out look like on one record?

The record for this page is a webhook created on a repository settings page: a payload URL and a signing secret. Without a proxy, the agent reads the signing key as it fills the field, the page echoes it back in the list of webhooks, and the value sits in the transcript beside a request any later step can repeat.

With the arrangement, the field renders as WH_SECRET_01 and the model types that string. The submit leaves the sandbox with the placeholder in the header, the proxy on the far side terminates TLS to read it, matches it to the stored value and the approved destination, replaces it and forwards the request. What returns to the agent is the result: a 201, the webhook id, and a delivery that succeeded.

Infisical's Agent Vault post states the premise plainly: "In short, the agent should not be trusted with direct access to any secrets," and explains that a traditional proxy keeps the tunnel opaque while its own proxy terminates it so it can see and replace the credential (Infisical, 2026). A proxy that only forwards encrypted bytes cannot read a header, so it cannot swap the placeholder, and the service receives a string it rejects.

That is why the record has two sides: the agent's side holds a reference whose meaning is fixed for the run, and the far side holds the mapping and the rule about which destination may receive it. The pattern is the one behind any API key an agent is allowed to use and never to read (How Do You Let an AI Agent Manage API Keys Without Reading Them?).

What do the vendors themselves say?

Docker keeps the mapping on the developer's machine. The credentials page says "The real credential stays on the host when proxy management is active; the sandbox sees only a sentinel value," warns that a kit with passthrough enabled "sends the real token response into the sandbox and reduces credential isolation," and scopes these flows to "local sandboxes" (Docker, Manage, 2026). Passthrough is a supported setting, so a review has to check it.

1Password and NVIDIA split the mapping from the sandbox. 1Password's post states that "The agent can work with real systems without holding any credentials in its context," and that "OpenShell Gateway replaces a placeholder with the real value only when the agent sends a request to an approved host" (1Password, 2026). The page does not describe independent testing of the integration.

Arcade's post describes what the far side should decide before it attaches anything: "Can this agent, acting for this user, perform this action on this resource?" and "Even if a user can delete files in Drive, their agent should only get read access unless deletion is explicitly needed" (Arcade, 2025). Substitution and authorization are separate functions.

Microsoft's managed identity documentation removes the stored value altogether: "Managed identities eliminate the need for developers to manage these credentials," and "This token acquisition doesn't require any secrets," though the design covers workloads on Azure resources rather than a request from a sandbox on a laptop (Microsoft, 2026).

| Dimension | Docker Sandboxes, per its documentation | NVIDIA OpenShell, per its documentation | What a buyer should verify | |---|---|---| | Where the value lives | On the host, when proxy management is active | In the gateway; the agent holds a placeholder | Which component holds it, and who can read it back | | What the agent sees | A sentinel value | "An opaque placeholder, not the real API key or access token" | That the placeholder is stable for the whole run | | What triggers substitution | An outbound request through the host proxy | A request to an approved host through the CONNECT proxy | Whether the destination check is per host, per path or per request | | A setting that reverses it | A kit with passthrough enabled | Not described in the pages reviewed | That no supported setting returns the value to the sandbox | | Scope | "local sandboxes" | Outbound requests from the sandbox | Whether the same controls apply in a hosted sandbox |

What still leaks when the credential stays outside?

Keeping the value outside changes what an attacker collects when an injection succeeds; it does not stop the injection. A study of browsing agents lists "prompt injection, domain validation bypass, and credential exfiltration" among its findings and demonstrates "how untrusted web content can hijack agent behavior," the route that survives a proxy when the agent is steered to an endpoint the allowlist already trusts (Mudryi et al., 2025). The proxy attaches the credential because the request goes to an approved host, and the reason for sending it is the attacker's.

That is the confused-deputy shape: the far side needs an authorization decision in addition to the swap. In a SailPoint survey of 353 IT professionals, 80% of organizations said agents took unintended actions, about 40% said agents "accessed unintended systems," 31% said agents shared inappropriate data and 23% said agents revealed credentials (How Do You Test Whether an AI Agent Can Reach Data Outside Its Assigned Task?). A credential outside the sandbox removes the last case from the transcript; it does not remove the action.

Three limits follow from the vendor pages. Configuration: a passthrough kit puts the real token response back inside. Scope: the Docker page limits these flows to local sandboxes. Endpoint list: a proxy is only as narrow as the hosts it will attach a value for, and NVIDIA's guidance calls each allowed endpoint a potential data exfiltration path.

None of that argues for keeping the value inside. It argues for reading the proxy's policy as the security boundary: which hosts, which paths, whose approval, and what record remains.

How do you test whether the credential is really outside?

A test is worth more than a reading of the page, because the property is negative: the value must appear in no place the agent can reach. Set a canary credential with a distinctive string, run the task, then look for it in four places.

The first is the model's context and the transcript the run produces. A study of neural code completion tools found that they "can not only return the precise piece of their training data" and that "two valid credentials were identified during our experiments," the risk a value carries once it has passed through model-facing text (Huang et al., Your, 2024). The second is the sandbox's file tree and process environment.

The third is the destination list: point the agent at a host that is not approved and confirm that the request leaves without a usable value, then repeat for a path on an approved host that the task does not need. The fourth is the record: ask which requests received the real value, when, and under whose approval.

Two failure modes are worth testing by name. A proxy that fails open is worse than no proxy, because the request looks normal and the value goes wherever it goes. A durable credential is the other: a value scoped to one task and one host can be bounded this way, while an account key cannot. AWS's guidance against creating access keys for the root user makes the point at the top of the account (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?).

What does a governed environment change?

A governed environment treats the value as something the model never needs and the task sometimes does. On a rendered page, values chosen by policy are replaced by consistent tokens before any model reads the screen, so the field, the confirmation and the next page show the same reference for the whole run. The real value resolves only at the approved destination, at the moment of an approved action, which for the record above means the repository settings endpoint when a named person approves the webhook. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

Applied to a sandbox, the same control class changes which side holds what. The credential stays with the party that can make the call, the agent's side holds a reference it cannot exchange on its own, and the exchange is gated by a named approver rather than by the agent's judgment about which host is appropriate.

It also changes what a review can ask. Instead of whether the agent was instructed not to print the key, the reviewer asks which destinations received it, which person approved each attachment, and what the record shows the model read first.

What it does not change is the set of permissions behind the credential: a proxy that substitutes correctly still acts with whatever the credential can do, so its scope and the authorization decision at the far side remain the organization's work. Policy consistency is the other half, since an agent facing two toolchains obeys whichever rule reached it last unless one written policy covers both (How Do You Keep Data Access Policies Consistent Across AI Tools?).

Methodology and limitations

This page rests on vendor documentation from Docker, NVIDIA, 1Password, Infisical, Arcade and Microsoft, on three research preprints about agent attacks, credential memorization and benchmark defenses, on one vendor research post from GitGuardian, 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 figures from vendor research are cited as reported, not as independently measured. The vendor pages are documentation and blogs rather than independent audits, and the research preprints are cited for the findings their abstract pages state, not for rates those pages do not give.

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 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 webhook on a repository settings page, and not an organization.

Determinations about whether a 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 proxy policy, or a reading of the vendor documentation for the version actually deployed.

What the record shows

For a team deciding where its agents' credentials live, the designs reviewed answer the title the same way with different reach. Docker's host proxy and NVIDIA's gateway keep the value outside the sandbox and attach it on the way out; 1Password stores it by reference; Infisical terminates TLS to substitute; Microsoft removes the stored credential entirely; Arcade adds the authorization question a substitution proxy still has to answer. What none of them removes is the agent's ability to use the credential at a destination it is allowed to reach, which is why the destination list and the named approver are the parts worth auditing; RedactSure's environment is built on the render-layer half of that control. A canary run makes the practical test: name one agent and one webhook task, run it with a canary credential, and write down every place the string appeared and every destination that received it.

Frequently asked questions

How do I keep credentials outside the sandbox where the agent runs?

Put the value in a process on the far side of the boundary and give the agent a reference. The agent's request names the reference, a proxy or gateway on the host matches it, attaches the real credential and forwards the request, and the result comes back. The property to verify is negative: search the sandbox's file tree, its process environment and the model's transcript for the value, and confirm it appears in none of them.

Is a host proxy the same thing as a secret manager?

No. A secret manager stores values and controls access to them; a proxy sits on the request path and substitutes a reference for a value the agent cannot read. The two are often deployed together, and the useful question is which one holds the mapping and which one decides whether a given destination may receive the value. A store the agent can read back through its own tools is not outside the boundary, whatever it is called.

What does the agent actually send when it uses a reference?

It sends an ordinary request with the placeholder where the credential would sit, usually in a header but sometimes in a form field or a query parameter. The proxy has to see that field, which is why TLS termination matters: a proxy forwarding encrypted bytes cannot read it or replace it. The agent receives the service's response and not the value, so a placeholder it repeats later still resolves to nothing outside the environment that issued it.

Can the agent still use the credential for something I did not approve?

Yes, within whatever destinations the proxy will attach it for and whatever the credential is permitted to do. Keeping the value outside the sandbox stops the agent from copying it; it does not stop a steered agent from using it at an approved endpoint. That is why the allowlist, the authorization decision and the named approver matter as much as the substitution, and why a credential scoped to one task and one host is easier to defend than an account key.

Does keeping the credential outside break the task?

It breaks the tasks that need the raw string rather than a request. A tool that signs a payload locally, or a script that reads the key to configure another service, expects the value in its own process, and a proxy that substitutes on outbound requests cannot help with either. Teams should map those steps first; where the credential has to be read, the honest options are a person completing the step or accepting the exposure.

What should I ask for in writing before I trust a sandbox's credential handling?

Which component holds the value, where it is stored, and whether the agent's own tools can read it back. Which destinations receive it, whether the check is per host or per path, and what happens when the proxy is unavailable. Whether any supported setting, such as a passthrough kit, returns the value to the sandbox. Who approves an attachment, and what record shows the destinations that received it. Each answer should survive a run with a canary credential.

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 Credential Out of the Agent's Process

A credential outside the sandbox still has to be attached somewhere, and the designs reviewed attach it only at the outbound request.

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

Before: the agent reads the signing key in the webhook form and the string sits in the transcript. Inside the governed environment: the field renders WH_SECRET_01, the model submits that token, and the real value reaches the repository settings endpoint only when a named person approves the change.

RedactSure is deploying now with enterprise and government customers. Docker documents that a passthrough kit "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

Keeping credentials outside the sandbox is a claim you can check on one page. Bring a webhook task your agent runs and see, with test values, what the model reads in the form. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.