Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Happens to Credentials When an Agent Sandbox Is Destroyed?

If the credential was inside the sandbox, destroying it ends the process but not the copies the run made in transcripts and logs; if it sat in an adapter outside, teardown ends a grant that never placed the value inside. Ask where the credential lived and what the run wrote down.

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

Teams that count on sandbox teardown to dispose of agent credentials are relying on a promise about the future: when the task ends, the machine and everything on it go away. The promise is true of the machine and false of the record. A token in an environment variable is readable by the process that holds it, and whatever that process prints, sends or saves becomes part of the transcript, the log or the artifact that outlives the box. A teardown review therefore answers a different question from the one it looks like it is answering: what was retained, and where the real value was when retention happened.

The page answers in six parts. The first places the credential on one side of the sandbox boundary or the other, because that placement decides what destruction can reach. The second follows one record, a sandbox destroyed with a token in its environment, and lists what the run had already written elsewhere. The third quotes the vendors' own pages on sandboxes, approvals and credential custody, with the limit each page states. The fourth covers the designs that keep the value outside and end the grant at teardown, the fifth covers the record that survives, and the sixth states the control class in neutral terms.

Key findings

  • Anthropic's documentation states that "GitHub credentials are stored encrypted on Anthropic's servers and never enter the session VM" and that "the VM holds a short-lived credential scoped to that session," a custody arrangement it describes for hosted sessions rather than a local run, so teardown ends a grant that was never inside (Anthropic, 2026).
  • HashiCorp's Vault tutorial documents the opposite placement: a wrapper "obtains a short-lived delegated RAR token, exports it as VAULT_TOKEN, and launches the agent," so the credential sits in the agent's environment for the run and anything it prints leaves the box (HashiCorp, 2026).
  • SecretBench is "a labeled dataset of source codes containing 97,479 secrets (of which 15,084 are true secrets)" (Basak et al., 2023).
  • Least privilege governs actions and credentials and does not govern the content of the screen the agent reads, so a run can satisfy it in full and still hold every value it was shown (What Is Least Exposure?).
  • Tokenization exchanges a sensitive value for a token that carries no exploitable value on its own, so a run holding only tokens leaves nothing worth taking at teardown (RedactSure vs Skyflow: 2026 Comparison & Alternative).
  • The Model Context Protocol's guidance states that "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server," which limits what a leftover token can reach (Model Context Protocol, 2026).

What decides whether a destroyed sandbox takes the credential with it?

The title says sandbox, and the control this page can describe does not reach one, so the scope comes first. A governed browser environment reaches what an agent reads and does on a rendered page, from a dashboard to a console, a settings page or a sign-up form. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A sandbox sits on the terminal side of that line: the variables in its process, the workspace mounted into it and the commands it types are outside a browser control, so the answer comes from where the credential was placed, not from which guard watched a page.

The two placements fail differently. In the first, the value is inside the box: an environment variable the process hands to a command, a file in the mounted workspace, a string typed into a login the agent performs. In the second, it is outside: a proxy or adapter that holds the value and attaches it to an outbound request, or a cloud identity that issues a scoped credential on request and stores no credential. Microsoft's documentation states that "this token acquisition doesn't require any secrets and is automatically authenticated based on the environment where the code runs," the second placement in its plainest form, for workloads on Azure resources rather than for a coding agent's local run (Microsoft, 2026).

Destruction acts on the first placement: it ends the process, releases the mount and disposes of the container. It cannot act on the second, because the second was never inside. The record for this page is a sandbox destroyed with a token in its environment. Nothing in that sentence says whether the token was copied out during the run, and the copy is what outlives the box.

What has the run already written down before the sandbox is destroyed?

A process reads the values in its environment because they are part of its own state. A command that echoes a variable, a failing request that prints its headers, a debug log left at its default level and a script that writes its settings into the workspace all copy the value to a place the sandbox does not own. The model's context is one more of those places: whatever a tool returns is in the conversation, and the conversation is stored.

The volumes are not small. One 2025 count put "28,649,024 new secrets exposed in public GitHub commits across 2025," with commits co-authored by an AI coding agent leaking at roughly double the baseline rate, alongside "24,008 unique secrets exposed in MCP configuration files" (How Do You Let an AI Agent Manage API Keys Without Reading Them?).

The workspace is the other channel. A sandbox that mounts a directory from the host writes through the mount, so a credential the agent saves into the tree survives the container by design, and an image or snapshot taken during the run keeps it too. Neither channel needs the agent to misbehave, and neither appears in a teardown log.

None of that requires a malicious agent. It requires a run that held a value, a channel to write it and a store on the far side of the boundary. Those three exist together in most tasks, which is why the teardown log, which records an exit, is the least informative page a reviewer can read.

What do the vendors themselves say?

OpenAI's Codex documentation states that "locally, Codex uses an OS-enforced sandbox that limits what it can touch (typically to the current workspace)," that "by default, the agent runs with network access turned off," and that "Codex asks for approval to edit files outside the workspace or to run commands that require network access," controls on what a local session may do, and how a credential is stored or handled in that session is not described in the pages reviewed, which is the part a teardown audit needs (OpenAI, 2026).

Cursor's page states that "by default, terminal commands need your approval" and that "all MCP connections need your approval," and it warns that "AI can behave unexpectedly due to prompt injection, hallucinations, and other issues," but it does not mention a sandbox and describes its run modes as "best-effort guardrails rather than a hard security boundary," so approval there bounds the action rather than the credential (Cursor, 2026).

HashiCorp's tutorial sits closest to this page's record. It states that "token lifetime is reduced from days or weeks to minutes" and that the agent receives "a token that is read-only, repo-only, scoped to a single secret, and short-lived," then shows a wrapper that "obtains a short-lived delegated RAR token, exports it as VAULT_TOKEN, and launches the agent," which leaves the token in the agent's environment for the run, and the page does not say whether the agent can read it (HashiCorp, 2026).

Vendor What its page documents about the sandbox and the credential What the page leaves open for a teardown
OpenAI (Codex) An OS-enforced local sandbox, network off by default, approval to work outside the workspace How a credential is stored or handled in a local session
Cursor Approval for terminal commands and MCP connections; no sandbox mentioned How credentials are stored, and what remains after a run
Anthropic (Claude Code) Sandboxed Bash with filesystem and network isolation; GitHub credentials held on its servers, never in the session VM What a local session holds when the platform does not host it
HashiCorp (Vault) Lifetime in minutes; a delegated token exported into the agent's environment Whether the agent reads the token in its own environment
Microsoft (managed identities) Token acquisition with no credential, scoped to the environment where the code runs How the design reaches an agent outside an Azure workload

Read together, the pages describe controls on action and, in Anthropic's hosted sessions, a credential placed outside the box. None describes what a transcript holds after the box is gone, so put that question in writing rather than read silence as a property of the product.

How do you keep the credential outside a sandbox that will be destroyed?

Moving the value out is the design response, and it takes three documented forms. A cloud identity can acquire a token with no credential at all, so the box has nothing to copy. A central store can hold the credential and issue it for one call: centralized credential management removes the need to embed credentials in agent code or settings (Does AWS Bedrock Keep Company Credentials Away From Agents?).

The third form is a lifetime short enough that destruction is a formality. HashiCorp's wrapper hands the agent a token scoped to a single credential for minutes, and a provider that mints a credential for a session ends it with the session. The grant expires, not the box, which is why the design survives a teardown nobody supervises.

Cloud guidance points the same way for the durable versions. Creating access keys for the root user is strongly discouraged, which rules out a credential that would outlive every run after it (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?). The administrator login follows the same rule: a super admin account should be used only when needed, a rule written for people that applies with more force to an agent that acts at machine speed (Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool?).

All three share one limit: they govern the call the agent makes, not what the model read on a page. An agent that opens a console page where the credential is displayed has it before any adapter is consulted, and no lifetime removes the copy that page put in the context (What Happens When an AI Agent Can See API Keys in a Console or Settings Page?).

What record survives the sandbox?

Verizon's 2026 breach report states that breaches now "start with software vulnerabilities, beating stolen passwords as the top way attackers get in," and that "hackers are shifting their focus from tricking people to exploiting systems" (Verizon, 2026). If the entry is the exploit rather than the password, the useful property of a credential is not how carefully it was kept but how little it yields once the run that used it is over.

The research on privilege control measures the same window. Progent, a privilege-control design for agents, "significantly reduces attack success rates while maintaining high utility," a statement about what an agent may do during a run and not about what the run retained afterward (Shi et al., 2026).

What should survive is a record of the run rather than a copy of the value. A tether describes authority rather than capability, so destroying the sandbox ends the authority, and the record has to show what the authority was used to read (What Is a Tethered Agent?).

The Model Context Protocol's guidance names the failure directly: "poor scope design increases token compromise impact, elevates user friction, and obscures audit trails" (Model Context Protocol, 2026). Those are the three things a teardown record should make visible: what the credential could reach, who had to approve its use and where the trail was stored.

What does a governed environment change?

A governed environment is a control class that acts where the screen is rendered, 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 DEPLOY_KEY_01 and the page it submits is filled from a store it never reads. Real values resolve only at the approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action. 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 in what destruction is for. When the run holds only tokens, the transcript, the log and the summary are records of placeholders, and destroying the sandbox ends a run that never had a value to revoke. The grant that a teardown ends is the approver's, not the model's: a person approved the actions, and the record names that person screen by screen. The question of what was retained gets a short answer, because what was retained is a token with no use outside the environment that issued it.

Its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so a credential placed in a sandbox's environment, in the tree or in a shell remains the territory of the sandbox design and the short lifetimes described above.

Methodology and limitations

This page rests on two research preprints, one on credentials in source code and one on privilege control for agents, the 2026 Verizon breach report, vendor documentation from OpenAI, Cursor, Anthropic, HashiCorp and Microsoft, the Model Context Protocol security guidance, and existing research pages on credential custody. Vendor pages were read between October 20, 2026 and October 21, 2026, and each Sources line carries the date for its page. Quoted facts appear in the source's own wording. The SecretBench figure describes a dataset rather than any tool's performance, and the breach report's findings are cited as it states them, including the point it does not settle for stolen passwords.

RedactSure did not test any sandbox, console or agent hands-on. Where this page says a behavior is not described in the pages reviewed, that means the recorded documentation for that product does not cover it, not that the product lacks the capability. Vendor features change and the page carries its date, so a release after that date should be treated as 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 sandbox destroyed with a token in its environment, and not an organization.

Determinations about whether a credential's lifetime, scope or record meets a contractual, regulatory or audit 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, run against a test credential, with the transcript and the grant's expiry read afterward.

What the record shows

Destroying a sandbox ends a process and the state stored with it. It does not end the transcript, the log or the workspace copy, and it does not recall a value the run already read. The two placements are the whole answer: a credential inside is one the run could copy, and a credential outside is a grant that expires with the session that used it. The designs that keep it outside are documented and narrow, and each governs a call rather than a page, which leaves the model's own reading of a screen as the exposure a teardown cannot reach. The design that makes teardown quiet is the one that never puts a real value in front of the model, which is where RedactSure's environment sits. For the test, a team names one agent and one task, runs it with a test credential in the environment, destroys the sandbox, and then reads the transcript and the grant's expiry together.

Frequently asked questions

Does destroying an agent sandbox destroy the credentials inside it?

It destroys the machine and the process, not the copies. A value in the process's environment could be printed, sent or written to the workspace during the run, and anything the model was shown is in the conversation, which is stored outside the box. Read the transcript and the logs from before the teardown, not the teardown log, and check whether the value appears in either. A mounted directory that survives the container is the usual reason it does.

If the token was only in an environment variable, did the run expose it?

The variable belongs to the process, so every command the agent runs inherits it, and output that includes it carries it out. HashiCorp's wrapper exports a delegated token as VAULT_TOKEN and launches the agent, and that page does not say whether the agent reads it. A run that never printed the variable may still have logged it, so treat the variable as disclosed if the run had a channel to write. It is the easiest copy to make and the easiest to forget.

What does a deletion promise cover?

A deletion promise covers what the provider stores: the sandbox, its disk and its snapshot. It does not cover what the run sent to a model, what the conversation holds, what a log pipeline captured or what the agent wrote to a mounted directory. Ask for the deletion scope in writing and compare it with the places the run could write, because the two lists are different in kind. The gap between them is where a copy sits.

What is the difference between a credential inside the sandbox and one in an adapter outside?

Placement. Inside, the value is part of the process state, so the run can read it, print it and copy it, and destruction removes only the original. Outside, an adapter or cloud identity holds the value and attaches it to a call the agent requests, so the box holds a reference or a short-lived token and nothing to copy. The second ends with the grant; the first ends with the box. Write down which one the tool uses before the first run.

How long should a credential for an agent run last?

No longer than the task. HashiCorp's tutorial reduces token lifetime "from days or weeks to minutes" and scopes the agent's token to a single credential, and a cloud identity can issue a token with no stored credential at all. The interval that matters runs from issuance to the last call the task needs, and anything beyond it is exposure with no purpose, especially after a teardown. A grant that outlives the task is a credential the teardown cannot end.

What should a team record when a sandbox ends?

The credential's identifier and scope, when it was issued and when it expired, which pages the agent read while it held the value, which actions ran, and who approved each one. That record answers the two questions a teardown review asks: what the run could reach and what it retained. Keep it beside the transcript from the same run, so the record and the run can be read together. That pairing turns a log into evidence of what happened.

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 Ends a Run Without a Live Credential in the Box

By teardown the agent has already read and printed whatever it could, and short-lived tokens and outside adapters limit a leaked value's reach, not what the model saw.

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

Before: the agent opens a cloud console's access key page and reads the key it displays once into its summary. Inside: the page renders ACCESS_KEY_01, the model submits that token, and a named person's approval resolves the real key at the console only.

RedactSure is deploying now with enterprise and government customers. One 2025 count found commits co-authored by AI coding agents leaking credentials at roughly double the baseline rate.

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

See it on your own workflow

Destroying the sandbox does not recall a credential the agent already wrote into its summary. Bring a cloud key task your team delegates and see, with test values, what the summary would contain at the end. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.