Sandboxed Execution

Also known as: isolated execution, agent sandbox, checkpoint and rollback

Code and actions run in isolation with checkpoints and rollback.

TrackAgentic systems FamilySafety & control Maturity Established ChangesTool/action

Problem

Agents that write and run code, edit files or operate a browser can do damage by mistake: delete the wrong folder, install a malicious package, leak credentials or corrupt data halfway through a change. Running that work directly on real machines and real data means every mistake lands in production.

Agents are most useful when they can actually run code and try things.
Generated code and downloaded packages can’t be fully trusted.
Multi-step changes can fail halfway and leave things broken.
Isolation that’s too strict blocks legitimate work, like reaching needed APIs.

Solution

Run the agent’s actions inside an isolated environment, such as a container, VM or sandboxed workspace, with no access to production credentials and network access limited to an allowlist. Give it a copy or a branch of the data, not the original. Take checkpoints before risky steps so a failed change can be rolled back. Results leave the sandbox only through a defined channel, like a pull request, a diff or a reviewed file, where checks or a person decide what’s promoted to the real system.

Diagram

The agent is free to experiment inside the sandbox. Nothing reaches the real system except through the promotion gate.

When to use

Use it when

The agent writes and runs code, or installs packages
The agent edits files, databases or infrastructure
It processes untrusted content that might contain attacks
Multi-step changes need a clean undo

Avoid it when

The agent only reads data and calls narrow, safe APIs
The task genuinely needs live production access; use strict approvals instead
Sandbox startup time would dominate very short tasks

Trade-offs

Latency

Sandbox startup and promotion add a little time

Cost

Compute for isolated environments

Complexity

Isolation, network allowlists, checkpoints, promotion

Reliability

Mistakes stay inside; rollback is built in

Gains

Agents can experiment freely without risking real systems
Failed or harmful changes roll back cleanly
A clear promotion step makes review natural

Costs

Environment setup and upkeep
Differences between sandbox and production can hide issues
Network allowlists need maintenance as needs change

Worked example

Scenario
A coding agent is asked to upgrade a web service's database library to a new major version.

SandboxStarts a container with a clone of the repo and a test database seeded with anonymized data. Network access is limited to the package registry. No production credentials are present.
AgentUpgrades the library, runs the tests and sees 14 failures. It takes checkpoint 1, then fixes the API changes.
AgentTries a data migration script. It corrupts the test database, so the agent rolls back to checkpoint 1 and writes a safer migration.
AgentAll 412 tests pass. A package it tried to add from an unknown domain was blocked by the network allowlist.
Promotion gateThe only output is a pull request containing the diff, the test results and the migration plan. A developer reviews it and merges after a staging run.

Failure modes

Failure	Symptom	Mitigation
Leaky sandbox	Production credentials or network reachable from inside	Separate credentials; deny network by default; test the isolation
Sandbox and production differ	Works in the sandbox, breaks in production	Mirror production configuration; run a staging step before release
Unreviewed promotion	Changes auto-merged without checks	Promotion only through tests plus human review for risky changes
No rollback point	Half-finished change leaves the environment broken	Checkpoint before every risky step; discard the sandbox if needed