Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do I Encrypt a Credential So Only One Sandbox Can Open It?

Seal it to a key that exists only inside that sandbox: generate the keypair there, register the public half with the grant service, and encrypt the credential to it when the grant is issued. Then check what the sandbox's processes can read after decryption, because the key governs custody, not sight.

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

A team that hands one task a credential no other task should have needs encryption to answer one question: who holds the key that opens this value. The answer is a key that exists in exactly one place, generated inside the sandbox that will use it, with the ciphertext addressed to that key alone.

Three things decide whether that works. The first is where the keypair is made and whether the private half ever leaves. The second is how the ciphertext is delivered and how long the grant lasts. The third is what happens after the sandbox decrypts, because every process inside it can read the plaintext, and that is where key custody and screen-level substitution part ways.

The record used throughout is two CodeCells and one grant. One sandbox receives the credential and opens it; the second holds the same ciphertext and can do nothing with it. The sections that follow set the scope, walk the four steps that make the grant, review what vendors document about wrapping, isolation, scoping and permission rules, and close with the limits and a test. Per-sandbox keys turn a shared vault into per-task custody; they do not change what a model is shown when a page renders the same value.

Key findings

  • HashiCorp's Vault documentation describes response wrapping: "A new single-use token is generated with the TTL supplied by the client," and the credential is fetched once against that token (HashiCorp, 2026).
  • The same page states that Vault "currently does not provide signed response-wrapping tokens, as it provides little extra protection," so identity has to come from the grant record (HashiCorp, 2026).
  • Cognition's Devin guide scopes credentials to a session "purely to the current session and are not saved for any future sessions," which is per-task custody inside one agent rather than custody per sandbox (Cognition, 2026).
  • Firecracker "is designed to assure secure isolation using multiple layers," and its design page treats traffic leaving a guest as untrusted, which is the boundary a sealed credential is opened inside (Firecracker, 2026).
  • Tokens before any model reads the screen keep a credential out of the model's context: the page shows GITHUB_TOKEN_01, and the real string stays in the store (What Is Render-Layer Tokenization?).
  • Real values resolve only at the approved destination at the moment of an approved action, while least privilege governs actions and credentials and does not govern the content of the screen an agent reads, so the two controls are complements (What Is Least Exposure?).

Where Does the Sandbox Stop and the Rendered Page Begin?

The title asks about a sandbox, so the first thing to fix is which control governs which surface. On any page an agent renders, a governed browser environment covers what that agent reads and does there: consoles, dashboards, settings pages and sign-up forms. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A credential decrypted inside a sandbox and exported as an environment variable, or written to a file a coding agent later reads, sits outside that control. A credential displayed on a console's token page sits inside it.

This page is about the seam between the two. Most credentials arrive on a rendered page before they are used inside a sandbox: an engineer opens a console, creates a token, and hands it to a task. The page that displays the token is read by a model, and the value is then sealed to a sandbox key.

Two records carry the example. The first is a token settings page, where a credential is shown to whoever holds the session. The second is the sandbox itself, a CodeCell in this design, where the decrypted value becomes an environment variable or a file. On the page, the question is what the model was shown, and a shared administrative login is the standard case of a credential that bundles more access than the task needs (Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool?). A sign-up or settings form is a measured leak point, as Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity? documents: an agent that fills the form reads every field it renders.

How Do You Encrypt a Credential to One Sandbox's Key?

First, the sandbox generates a keypair at start, inside its own boundary, keeps the private half there, and registers the public half with the grant service under the task identifier. If the private key is created outside and installed, whoever installed it can keep a copy, and the arrangement collapses into a shared secret.

Second, the grant service encrypts at grant time. The credential is encrypted to that public key, with an ephemeral key for the message, and the grant record binds the key fingerprint, the task, the credential's scope and an expiry. This is the step the title describes: a ciphertext for one sandbox.

Third, delivery is single-use and expiring. Vault's response wrapping is the closest documented pattern: "To help address this problem, Vault includes a feature called response wrapping," which returns a token in place of the credential and lets the holder redeem it once (HashiCorp, 2026). Wrapping is delivery, not encryption to a recipient key: the token authorizes the fetch, and the sealed ciphertext limits the reader.

Fourth, the value is used and the grant dies. The sandbox decrypts in memory, passes the value to the one process that needs it, and the grant expires. The second sandbox holding the same ciphertext has nothing to open.

A named person approves the grant, and the approval is recorded against the task. FINRA's 2026 oversight report, as summarized by Debevoise & Plimpton, explains why scope matters: "Agents may act without human validation and may take actions that exceed the user's actual or intended scope or authority" (Debevoise & Plimpton, 2026). A grant scoped to one task and one credential is the smallest thing a person can approve, and as What Is a Tethered Agent? puts it, the tether is a description of authority and not of capability.

What do the vendors themselves say?

The four vendor pages reviewed here document the parts around the key, and none of them describes a keypair generated inside a sandbox and used to seal one credential. That arrangement is not described in the pages reviewed. What they document is delivery, isolation, scoping and permission boundaries.

Firecracker's design page treats the guest as the isolated unit: "Firecracker is designed to assure secure isolation using multiple layers," and "all egress traffic from a guest is therefore considered untrusted, and should be filtered at the host-level" (Firecracker, 2026). Isolation inside the guest is the property a sealed credential borrows, and the host-level filter is the property the guest cannot supply for itself.

Cognition's Devin guide lists organization, personal, repository and session scopes for credentials, with session credentials "scoped purely to the current session and are not saved for any future sessions," and it says that "in the browser, Devin types the value directly" (Cognition, 2026). A scope decides how long a credential lives and who may reuse it. Typing the value on a page means the plaintext passes through the agent's own action, which no scope changes.

Anthropic's Claude Code documentation describes Read deny rules for file paths and then states the limit: "They 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," with OS-level enforcement left to the sandbox (Anthropic, 2026). A permission rule covers the file tools and not a shell command that never names the file.

Dimension Vendor, per its documentation What a buyer should verify
Delivery to one recipient HashiCorp Vault response wrapping: a single-use token with a client-supplied TTL, unsigned by Vault Whether the grant record, not the token, says who issued the credential
Boundary around the workload Firecracker: multiple isolation layers; guest egress untrusted and filtered at the host Whether the host enforces egress and what the guest can reach
Credential scoping Cognition Devin: organization, personal, repository and session scopes; encrypted at rest Whether the plaintext is typed on a page or bound into a process
Permission boundary Anthropic Claude Code: Read deny rules for file tools, sandbox for OS-level enforcement Whether the rule covers a subprocess that never names the file
Key custody No vendor page reviewed states that a credential is encrypted to a sandbox key Which component generates the keypair and where the private half lives

What Does Per-Sandbox Encryption Not Protect?

Encryption decides who can open a value, and it stops deciding when the value is open. Inside the sandbox the plaintext is available to the process that decrypts it and to anything else with the same reach.

Devin's guide says that "for shell commands, it binds secrets as environment variables whenever needed," so any process in the sandbox that inherits the environment can print the value (Cognition, 2026). The instruction to copy it can also arrive in content the sandbox reads, the pattern What Is Indirect Prompt Injection and How Does It Reach AI Agents? describes.

The sandbox is software, and the supply chain reaches it. The SLSA threat list includes an "attacker compromised the build platform and installed an implant that injected malicious behavior during each build," and a second pattern in which the "attacker added an innocuous dependency and then later updated the dependency to add malicious behavior" (SLSA, 2026). Either case defeats encryption at rest inside the sandbox, because the compromised process is the intended reader.

Two limits follow. A keypair protects the value until decryption and not after, so a grant that outlives the task is a shared credential with extra steps. The count of credentials already exposed in public commits, 28,649,024 in 2025, is the measure of what a context can carry (How Do You Let an AI Agent Manage API Keys Without Reading Them?).

Verizon's 2026 DBIR landing page reports that 31 percent "of breaches now start with software vulnerabilities, beating stolen passwords as the top way attackers get in" (Verizon, 2026). A per-sandbox key shrinks what a compromised sandbox yields; it does not stop the compromise.

What Should a Team Test Before Trusting a Grant?

Name one task, one credential and two sandboxes built from the same image. Grant the credential to the first and try to open the same ciphertext in the second with the same user, the same network and the same role. If the second sandbox can decrypt, the design is a shared vault with a new name. If it cannot, ask what else in the environment holds the private key: the orchestrator that provisioned the pair, a logging agent, a backup of the sandbox disk.

A network location is not a boundary. NIST's zero trust guidance grants no implicit trust to an asset or account "based solely on their physical or network location," the assumption a shared vault makes about every sandbox on the same network (NIST, 2020). Two sandboxes in one cluster look identical to a vault that authorizes by path or role.

Then read the record for the run. It should show which key fingerprint was used, which task the grant was issued for, when it expired and which person approved it. If it shows a credential used outside the grant window or by a second sandbox, the custody model is not in force, whatever the diagram says.

Long-lived static credentials are the baseline this replaces. Datadog reports that "37 percent of customers who send CloudTrail logs to Datadog are using IAM users in their GitHub Actions," the durable credential a per-task grant replaces (Datadog, 2025). The same report says Datadog "identified thousands of malicious PyPI and npm libraries in the wild" during 2024, code that can arrive inside a sandbox image (Datadog, 2025).

Last, open the console page that displays the credential and ask what the model received. If it received the value, the key work is irrelevant to that exposure, because the model already holds the plaintext.

What does a governed environment change?

A governed environment is a control class that acts where a screen is rendered, before any model reads it, and it answers a different question from the one a keypair answers. Values chosen by policy are replaced with consistent tokens for the whole run, so a settings page that displays a credential renders CRED_001 rather than the string. Real values resolve only at the approved destination, at the moment of an approved action. A named person confirms what is tokenized 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 the two controls stack rather than compete. Per-sandbox keys decide who can open a credential; tokenization decides what a model reads when the credential is displayed on a page. A team that does only the first has custody and no sight control, and the model still receives the value from the console page that shows it. A team that does only the second has sight control over a shared vault underneath.

The control class does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP. A credential that a sandbox decrypts and exports into a process remains a key-management problem, which is why the grant has to be short, scoped and recorded.

What the record adds is the part a keypair cannot state. A ciphertext proves that one key could open a value; it does not say which model saw the value, on which page, or who approved the use. The governed environment writes that down.

Methodology and limitations

This page rests on four vendor documentation pages (HashiCorp's Vault response wrapping note, Firecracker's design page, Cognition's Devin secrets guide and Anthropic's Claude Code permissions page), two standards and guidance documents (NIST SP 800-207 and the SLSA v1.0 threat overview), one law firm summary of a regulator's report, two industry reports (Datadog's State of DevSecOps 2025 and Verizon's 2026 DBIR landing page), 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 facts are cited to the page that states them, and figures from vendor research are cited as reported, not as independently measured.

RedactSure did not test any named product hands-on. Where a mechanism is not described in the pages reviewed, the page says so and does not infer the behavior. Vendor features change and the page carries its date, so a release after that date should be treated as 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, two CodeCells and one grant, and not an organization. The four steps in the second section are stated as a design requirement, not as a claim about any product's implementation.

Determinations about whether a credential-handling design meets a contractual or regulatory requirement belong to counsel, assessors and the organization's own compliance officers. Nothing here replaces a test of the organization's own agent against its own credential store, repeated after each release.

What the record shows

Per-sandbox custody answers the title with one condition attached. A credential encrypted to a key generated inside one sandbox, delivered once at grant time and expiring with the task, is unusable in every other sandbox; the pages reviewed document the delivery pattern and the isolation it depends on, and they document no product that seals a credential to a sandbox key. The condition is that the key governs custody and not sight: once decrypted, the plaintext is available to every process in the sandbox, and the console page that displays the credential is still read by the model. Before relying on the pattern, a team should test it with one agent, one credential and two sandboxes: grant the credential to the first, and record which key opened it, what the second sandbox could do, and what the model read.

Frequently asked questions

Can I encrypt a credential to one sandbox without a keypair per sandbox?

You can, and the result is weaker. Encrypting with a password or a shared key means the credential has to reach every sandbox that might need it, which is the shared vault problem in another form. A per-sandbox keypair keeps the private half in one place and makes the ciphertext useless elsewhere. The cost is bookkeeping: one public key per task, one grant per credential, and a rotation step when the task ends. That bookkeeping is what a grant record exists to hold.

What stops a second sandbox from opening the ciphertext?

The private key. The ciphertext is encrypted to a public key whose private half was generated inside the first sandbox and never exported, so a second sandbox on the same host, network or account has nothing to decrypt with. This holds only if the keypair was created inside the boundary and the orchestrator cannot read the private key. If the key was generated centrally and installed, the installer holds a copy and the second sandbox may too.

Does encrypting the credential keep the agent from reading it?

No. Encryption protects the value in transit and at rest; the agent's process decrypts it and works with the plaintext. From that point the model can read the value if the value enters its context, which it often does on a settings page or in a command. RedactSure's design addresses that second half by substituting a token at the render layer before the model reads the screen, and the two controls answer different questions about the same value.

How long should a grant last?

As long as the task and no longer. The Vault page reviewed here ties the wrapping token to a TTL the client supplies and gives no default, so the length is a decision the team makes per task. A grant measured in minutes limits what a stolen ciphertext is worth; a grant measured in days is a durable credential with extra steps. Expiry should be enforced by the component that issues the grant, not by the sandbox that receives it.

How do I know which sandbox opened the credential?

From the grant record, not from the ciphertext. The record should name the key fingerprint, the task, the credential scope, the expiry and the person who approved the grant, and the opening event should be logged against that fingerprint. Vault's documentation notes that its wrapping tokens are not signed, so the record has to carry the issuer identity rather than the token. A record showing a credential used outside its window is the signal that custody is not in force.

Is response wrapping the same as encrypting to a key?

No. Wrapping is a delivery mechanism: Vault returns a single-use token in place of the credential, and the holder redeems the token once within the TTL. Encrypting to a key is a custody mechanism: the ciphertext is addressed to one public key, and only the matching private key can open it. The two combine well, with wrapping protecting the handover and the recipient key protecting the value, but neither substitutes for the other.

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 Sandbox Credential Off the Model's Screen

Sealing a credential to one sandbox settles who can open it, and the pages reviewed never change what a token page shows the model.

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

Before: the agent opens the console's token settings page, the credential renders as text, and the model holds a string it can paste anywhere. Inside the governed environment: the same page renders CRED_001, and the real value reaches the approved destination only when the named person approves the change.

RedactSure is deploying now with enterprise and government customers. Datadog found 37 percent of sampled customers still running GitHub Actions on IAM users.

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

See it on your own workflow

Encrypting a credential to one sandbox protects the copy, not the page the agent reads. Bring a task that opens a token settings page and see, with test values, what the model receives. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.