Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Does Each Agent Task Need a Fresh Sandbox?

Yes, as the default: a fresh sandbox removes files, state and credentials an earlier task left behind, which is why Copilot documents an ephemeral environment per task and Codex removes task credentials before its agent phase. The cost is setup time, so check what the image carries into the next task and what the model reads on the page.

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

Teams running coding agents often treat a fresh sandbox per task as a budgeting question, until they count what a reused environment hands to the next task. A sandbox built for one job is discarded with that job's files, its installed packages, its shell history, its signed-in browser sessions and any token that drifted into a variable or a settings file. Building it again costs minutes, and caching the image is the standard answer to that cost. Neither the rebuild nor the cache settles the second question, which is what the model reads while the task runs. A clean machine still renders a token settings page, and a token shown on that page enters the context whether the disk is new or old. Rebuilding controls what the task can touch and leaves what it can see unchanged. This page takes the two questions in order: what a fresh sandbox removes, why Copilot and Codex build environments this way, what caching does to the setup cost, and what environment hygiene cannot change. The worked record is one type of event, a leftover token in a reused sandbox, followed from the environment onto the page where it becomes readable, then run again in a fresh environment to show what changes and what does not.

Key findings

  • GitHub's Copilot coding agent documentation states that it "can edit files and run tests and linters in an ephemeral cloud development environment" and that it can "only work on one branch at a time," a fresh machine per task that says nothing about what the model reads on a page (GitHub, Copilot, 2026).
  • OpenAI's cloud environment documentation, which the vendor marks legacy, states that credentials "are removed before the agent phase starts" while "environment variables are set for the full duration of the chat (including setup scripts and the agent phase)," so a value in a variable outlives the credential that was removed (OpenAI, Codex Cloud, 2026).
  • Wiz found that 65% of the 50 AI companies it examined "had leaked verified secrets on GitHub," the population that makes a stale environment a liability rather than an inconvenience (Wiz, 2025).
  • A governed environment replaces a value with a consistent token before any model reads the screen, so an agent that opens a token settings page works with TOKEN_001 and never holds the string (What Is Render-Layer Tokenization?).
  • Real values resolve only at the approved destination at the moment of an approved action, so a task can use a credential without the model ever receiving it (What Is Least Exposure?).

What does a fresh sandbox actually remove?

A sandbox governs the machine an agent runs on: its files, its processes and its network. A governed browser environment governs another layer: what the agent reads and does on a rendered page, such as a dashboard, a console or a settings page. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. The two controls answer different questions, and this page needs both: a task can start clean and still read a live credential off a page.

Rebuilding the environment removes what the previous task wrote into it: cloned repositories, installed packages, shell history, temporary files, exported variables and, in a hosted environment, the browser profile that held the previous task's sessions. What the rebuild does not remove is what the task already sent out: a token pasted into a prompt, a summary written into a chat, a value committed and pushed to a remote.

The record here is one type of event, a token issued for one task and left behind in a reused sandbox. The second task inherits the token without asking, and the token page the agent opens renders it as a live credential that the second task did not create. GitHub's guidance to treat access tokens like passwords, and fine-grained tokens limited to specific repositories, describe the material a token page carries (What Can an AI Agent See in Your GitHub Settings?).

A fresh environment is a statement about capability, not authority. The tether that describes where an agent may go is set by the person who connected it, as What Is a Tethered Agent? sets out.

Why do Copilot and Codex build a new environment for each task?

Copilot's documentation puts the work in an ephemeral cloud environment, where the agent "can edit files and run tests" and "can only work on one branch at a time," a run boundary that says nothing about what the model reads on a page (GitHub, Copilot, 2026).

OpenAI's cloud environment documentation describes the task boundary from the credential side. Credentials "are removed before the agent phase starts," while "environment variables are set for the full duration of the chat (including setup scripts and the agent phase)," so the credential is gone and a variable is not (OpenAI, Codex Cloud, 2026). The page is marked legacy, so the design is evidence of a pattern rather than a promise about the current product.

Codex's local mode is a different arrangement. Locally it "uses an OS-enforced sandbox that limits what it can touch (typically to the current workspace)," "by default, the agent runs with network access turned off," and "Codex asks for approval to edit files outside the workspace or to run commands that require network access" (OpenAI, Agent, 2026). That sandbox sits on a machine that persists between tasks, and the approval is about the host, not about what the model read.

The reason for the rebuild is blast radius: a per-task environment makes the previous task's leftovers irrelevant to the next one and gives the run a known starting state. The limit is the same at every vendor. The environment changes what the task can reach on the machine, and it changes nothing about what the model reads on a page the task opens.

What do the vendors themselves say?

The vendor pages reviewed describe isolation at the machine layer, credential handling at the task boundary and scanning at the repository. None describes a per-task policy for which values the model may read on a page.

Firecracker's design documentation states that it "is designed to assure secure isolation using multiple layers" and that "all egress traffic from a guest is therefore considered untrusted, and should be filtered at the host-level," isolation between tenants, not credentials inside the guest (Firecracker, Design, 2026). The jailer documentation adds that a flag "causes the jailer to spawn the provided binary into a new PID namespace" and that the jailer can drop privileges to a provided uid and gid, one process tree per task (Firecracker, Jailer, 2026).

GitHub's Actions documentation states that "secrets are not passed to the runner when a workflow is triggered from a forked repository" and that teams should "mask all sensitive information that is not a GitHub secret," a log control that leaves the value in the environment (GitHub, Using, 2026). Its secure use reference calls it "good security practice" to set the default permission for GITHUB_TOKEN to read access only for repository contents (GitHub, Secure, 2026), and push protection "acts as a frontline defense mechanism by scanning code for hardcoded secrets at the time of the push" (GitHub, Push, 2026). Each governs what reaches the repository. None governs what reaches the model.

Dimension What the documentation states What a buyer should verify
Freshness Copilot runs each task in an ephemeral cloud development environment Whether the image is rebuilt or reused, and what the cache carries
Credentials at the task boundary Codex cloud removes secrets before the agent phase; variables persist for the whole chat Which values are secrets and which are variables
Isolation Firecracker uses multiple layers and treats guest egress as untrusted Whether egress is filtered at the host and logged
Privileges The jailer starts a process in a new PID namespace and can drop uid and gid Which user the agent process runs as
Repository scope Copilot changes only the repository named at task start and works one branch at a time Whether a broad token sits in the environment
Log masking Actions masks values that are not GitHub secrets Whether the mask covers every log the task writes
Token default GITHUB_TOKEN can default to read-only repository contents Who can widen it, and for how long
Push scanning Push protection scans at the time of the push What happens after a bypass

What does a fresh environment cost, and does caching fix it?

Rebuilding repeats work: installs, downloads, authentication and, for a hosted environment, provisioning. None of the vendor pages reviewed puts a time on that work; they describe the mechanism and leave the minutes to the team that operates it.

Caching the image addresses the cost, and it changes the residue question. A cache built from a base image and a dependency list is a copy of the toolchain, not of a task. A cache built from a machine that ran a task is a copy of that task's environment, which can include the browser profile, the exported variables and the token that was supposed to disappear with the task. The question is not whether the image is cached but what the cache is a copy of, and whether the base is rebuilt from source on a schedule.

Credentials at setup are the other cost. A build step that fetches a private dependency needs a credential, and a long-lived key baked into the image is the wrong place to put it; OIDC settles how the pipeline authenticates, and How to Set Up S3 and GitHub With Cowork or Dots sets out the arrangement for one pair of services.

The research record is a caution against treating the rebuild as a defense. A benchmark of LLM agent attacks and defenses reported "critical vulnerabilities in different stages of agent operation" and "limited effectiveness shown in current defenses" (Zhang et al., 2025). A fresh environment limits what a hijacked task can reach after it starts. It does not stop the hijack, and it does not change what the model was shown before the task began.

What does a fresh environment not remove?

One thing survives every rebuild: the page. A task that creates a token sees the confirmation page that displays it once, and a task that reads an existing token sees the settings page that lists it. The model reads the page as rendered, so the value enters the context in a fresh environment as surely as in a reused one, with one difference: in the reused environment the token was there before the task started, and in the fresh one the task created it.

That difference matters to an incident review and not to the exposure. A study of neural code completion tools found that "two valid credentials were identified during our experiments" and that the tools "can not only return the precise piece of their training data" (Huang et al., Your, 2024). A token the model read is a token the model can repeat, whether it arrived through a page it opened or a value it typed.

The scale is the argument for treating this as a design problem. Wiz's figure above, 65% of the 50 AI companies it examined with a verified leak on GitHub, describes repositories after the fact; the token page is where a credential becomes readable during the task. A durable key makes it worse: AWS states that it strongly recommends not creating access keys for the root user, which rules out the simplest durable top-level credential an agent might be handed (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?).

So the fresh environment answers the machine question and leaves the page question open; the control that answers it has to act before the page reaches the model.

What does a governed environment change?

A governed environment is a control class that acts where a page 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 TOKEN_001, and the same placeholder stands for the same value on every page the task opens. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action, and the record of every screen, action and approval exports to the organization's own monitoring.

For this page's question, that changes two things a fresh sandbox cannot. The first is what survives the rebuild. A fresh environment resets the machine, and the token a task creates is still rendered to the model on the page that confirms it; under render-layer substitution that page shows TOKEN_001, and the transcript, the summary and any later page carry the placeholder rather than the value. The second is the record. A rebuild produces a clean machine and no statement of what the model saw; the governed environment produces the statement, screen by screen, with the name of the person who approved the action.

The two controls compose. A team can rebuild the environment per task, cache the toolchain rather than the task, and still put the render layer in front of the pages the agent reads. The rebuild governs what the task can reach; the render layer governs what it can see.

Its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, where the sandbox and the credential store do their work.

Methodology and limitations

This page rests on two research preprints on agent attacks and credential memorization, vendor documentation from Firecracker, OpenAI and GitHub, one vendor research post from Wiz, 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 the two OpenAI pages are cited as the vendor published them, including the page OpenAI marks legacy. The research pages are cited for the findings their abstracts state, and the vendor pages for the mechanisms they document; neither is treated as a measurement of the other.

RedactSure did not test any of the products named here hands-on. The vendor pages concern isolation mechanisms and credential handling at a task boundary; none of them sets out a per-task policy for which values the model may read on a page, and that absence is reported as what the pages reviewed contain rather than as a claim about what a product does. Vendor features change, and the page carries its date; a release after that date is unreviewed until the test at the end is repeated. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The worked example describes a record type, a token left in a reused sandbox and read on a settings page, and not an organization.

Determinations about whether a sandbox, an image cache or a token policy meets a contractual, regulatory or internal 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 in its own environment, repeated after each change to the image or the model.

What the record shows

The record answers the title in two parts. A fresh sandbox removes the files, state and credentials an earlier task left on the machine, and the vendor pages show the pattern in Copilot's ephemeral environment and Codex's credential removal. What the rebuild does not remove is the page. A token created or displayed during the task is rendered to the model, and the model can repeat what it read. The cost is setup time, and caching the toolchain rather than the task keeps that cost down without restoring the residue; caching a machine that ran a task restores it. RedactSure's environment is built on the render-layer route, which is the one that answers the page question. A fair test for a team names one agent and one task, runs the task in a reused environment and in a fresh one, and sets what the model received on the token page beside who approved the action that used the token.

Frequently asked questions

Does every agent task need a fresh sandbox?

A fresh environment is the safer default for any task that touches a credential, a repository or a customer record, because it removes the previous task's files, sessions and leftover tokens. It is not the only control and not always affordable: a task that reads a public page and writes a summary gains little from a rebuild. Sort tasks by what they can reach, rebuild wherever the previous task held a credential, and write the reason beside the task.

What does a fresh sandbox actually remove?

Everything the previous task wrote into the environment: cloned code, installed packages, shell history, temporary files, exported variables and the browser profile that held its sessions. It does not remove what the task already sent out, such as a token pasted into a prompt or a value pushed to a remote. The rebuild resets the machine, not the transcript the task produced, and a file the task wrote and never opened again is gone while a message it sent is not.

Why do Codex and Copilot use ephemeral environments?

Both vendors describe isolation as part of the task model. Copilot's documentation puts each task in an ephemeral cloud development environment with one branch and one pull request; OpenAI's cloud environment removes credentials before the agent phase, so setup credentials do not sit in the agent's reach. The shared reason is blast radius: a task that starts clean cannot inherit the last task's mistakes, and a fresh environment is the cheapest way to get there, which is why both vendors document it.

Does caching the image bring the cost down?

Yes, when the cache holds the toolchain rather than a task. A base image with dependencies and no session state removes most of the rebuild time without restoring residue; a snapshot of a machine that ran a task can carry the browser profile and exported variables forward, which is the thing the rebuild was for. Check what the cache is built from, not only how fast it starts, and ask whether the base is rebuilt from source on a schedule.

Can a fresh sandbox keep a token out of the model's context?

No. The sandbox governs what the task can touch, and the model reads the page the task renders, including the confirmation page that displays a new token. A study of code completion tools found two valid credentials returned during its experiments, which is the risk a token carries once it is in model-facing text. Keeping it out of the context takes a control at the page, and the rebuild is still worth doing because it answers a different question.

What should a team require from a sandbox vendor?

A written statement of what the environment is rebuilt from, which values are secrets and which are variables, where egress is filtered, which user the agent process runs as, and what record shows what the model read. Ask for the same statement for the image cache, because a cache is the one path by which a clean environment can inherit a task. Then confirm it with one task and one token, and repeat the test after each image 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 Keeps a Leftover Token Off the Page

A fresh environment clears residue at the machine layer but leaves alone the token a settings page renders for the model to read.

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

Before: a second task starts in a reused environment and the repository's token settings page shows the live token, which enters the transcript and the next request. Inside the governed environment that page renders TOKEN_001, and the value resolves only on a named person's approval under Supervised Delegation.

RedactSure is deploying now with enterprise and government customers. Wiz found that two-thirds of the AI companies examined had leaked a verified credential on GitHub.

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

See it on your own workflow

A fresh sandbox clears the disk, not a token the next settings page shows. Bring a task your agent repeats and see, with test values, what the model reads on the token settings page. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.