Default to a fresh sandbox per task and persist only what you choose, such as a cache or a named output folder. A persistent sandbox saves setup time but carries files, tokens and tampered content from one run into the next, which makes problems harder to trace and to clean up.
What persistence means
Some products give each task a clean environment that disappears afterward. Others keep a workspace alive across tasks so installed tools, cloned repositories and intermediate files remain. A few offer both. The question is not which is better in general, but what carries over and who controls it.
What can carry over
- Files the agent wrote, including scratch notes and partial outputs
- Installed packages and tools
- Cached credentials or tokens left in environment variables or config files
- Cloned repository copies and their local branches
- Conversation or task memory the product stores for the agent
Each item helps or hurts. Installed packages save minutes. A cached token that outlives its task extends the window in which a leak matters.
Fresh versus persistent
| Factor | Fresh per task | Persistent |
|---|---|---|
| Setup time | Longer each run | Short after first run |
| Cross task contamination | Low | Possible |
| Secret exposure window | Short | Long unless cleared |
| Reproducibility | High | Drifts over time |
| Forensics | Needs logs | State itself is evidence, until altered |
| Cost | Compute per start | Storage and idle time |
Contamination deserves a second look. Content the agent processed during one task, such as a hostile document, can leave behind files that a later task reads. OWASP's guidance on excessive agency notes that triggers include indirect prompt injection and earlier invocation of a compromised extension, and in agent systems each call feeds the next. Persistent state gives an injected instruction a way to survive a restart.
Questions for the vendor
- Is each task in a fresh environment by default?
- If state persists, what exactly persists and for how long?
- Can an admin or user wipe it, and is deletion verifiable?
- Are secrets ever written to persistent storage?
- Can two users or two projects share one persistent environment?
- What is retained after the account is closed?
Question 5 is a quiet one. A shared persistent workspace means one person's files are visible to another person's tasks.
A sensible policy
Use fresh environments for anything touching untrusted input, such as public issues, emails or third party documents. Allow persistence for trusted, internal work, scoped to one project and one team, with a retention limit and a scheduled wipe. Pass secrets at run time with short lifetimes and scoped permissions, and make sure they are not written to disk inside the sandbox.
Test it
Ask an agent to create a file with a unique name and plant a dummy token in an environment variable. End the task, start a new one, and look for both. Then try as a second user. What you find is the real default.
Record the outcome, and review again after major product updates, since persistence defaults can change.
Safeguard's policies and guardrails help set limits on what agents may do with the access they hold, and its asset discovery can help you find where agent environments exist.
A worked example: a long running migration
A team asks an agent to migrate a codebase from one framework version to another over several days. A fresh sandbox per task would reinstall dependencies and clone the repository each time, costing minutes per step and losing the agent's notes on what it already changed. A persistent workspace keeps progress, which makes the job practical.
The trade-off is visible. The workspace now holds a repository copy, installed packages, scratch notes and maybe a token used to push branches. If the agent read a hostile file on day two, content derived from it could sit in the notes on day four. So the team picks a middle path: persist the repository copy and a named notes file, nothing else. Tokens are issued per task and expire in hours. The workspace is wiped when the migration ends.
Step by step: design a state policy
- List what the task needs to keep. Be specific: repository copy, a cache directory, a notes file.
- Persist only that. Mount or snapshot those paths and let everything else reset.
- Scope secrets per task. Issue short lived tokens at the start of each run.
- Separate by project and user. No shared workspaces across teams.
- Set a lifetime. Define when the workspace expires and who can extend it.
- Wipe on completion. Verify with the marker file test.
- Log what persisted. Keep a list of workspaces, owners and expiry dates.
| Item | Persist? | Reason |
|---|---|---|
| Repository copy for a long task | Yes, scoped | Saves time and keeps progress |
| Dependency cache | Often yes | Speed, low sensitivity |
| Notes the agent writes | Yes, reviewed | Continuity, but treat as untrusted |
| Tokens and secrets | No | Short lived, per run |
| Output from untrusted sources | No | Avoid carrying injected content |
Treat persisted notes as untrusted input
If an agent writes notes and reads them back later, those notes can contain content copied from hostile sources. Handle them as you would any external input: do not let them expand the agent's permissions or change its instructions without review. Some teams have a person skim the notes file at checkpoints.
Cost angle
Persistent workspaces cost storage and sometimes idle compute. Fresh ones cost start up time. Ask the vendor how each is metered and whether you can cap either, without assuming one is cheaper. Set budget alerts and look at actual usage after a month.
Try it yourself
Click through it at your own pace, or open it full screen. See how a gate stops a change until a rule passes, the same idea as an approval step around an agent.
Quick check
Is a persistent sandbox always worse?
No. It suits trusted, scoped work. Avoid it for tasks that handle untrusted input, and cap what persists.
How do I know a wipe worked?
Run the marker file test after a wipe, and ask the vendor how deletion is performed and logged.
Who should own agent workspaces?
A named team or person per workspace, recorded with an expiry date, so unused environments do not linger.
Sources
Last reviewed: 19 October 2026.
