Agent Sandboxes, Explained: Why TrueForge Treats the Sandbox as a Tool

A sandbox can isolate code, file, and shell execution without becoming the agent’s entire runtime. That choice changes cost, credential exposure, lifecycle, and recovery semantics.

A sandbox answers a narrower question than “is the agent safe?”

An agent may need to execute code, manipulate files, inspect a repository, or run shell commands. Those operations should not share an unrestricted process boundary with the orchestration server or the organization’s production infrastructure. A sandbox creates a constrained execution environment for that work.

But “sandboxed agent” is an imprecise phrase. It can mean the entire agent loop runs inside an isolated machine, including model clients, tool credentials, and state. Or it can mean the agent loop remains in a managed runtime and invokes an isolated environment only for execution-heavy tasks. TrueForge chooses the second design: sandbox as a tool.

The distinction changes what is isolated, when compute exists, where secrets live, and what survives a failure. It also prevents a sandbox from becoming a magical security label. The boundary protects only the operations and traffic actually placed behind it.

The architecture keeps the secret-bearing model and MCP clients on the harness side while giving code and shell work a separate execution boundary. The connector is a capability path, not a transfer of credentials into the sandbox.

Two architectures, different tradeoffs

In an agent-inside-sandbox architecture, each run or agent environment may contain the orchestration loop, model client, tools, credentials, and working files. Isolation is conceptually simple because most activity occurs inside one boundary. The costs are heavier provisioning, more complex secret injection, and image rebuilds when runtime dependencies change.

In TrueForge’s documented sandbox-as-tool architecture, the agent loop runs on the TrueForge server. The sandbox is provisioned only when the agent needs code, file, shell, a skill, or Code Mode. Simple conversational turns and MCP calls do not require sandbox compute. Model and MCP credentials remain in the harness, and Code Mode MCP calls are bridged back to the harness rather than giving the sandbox those tokens.

This reduces the secret-bearing surface and allows conversation state to survive a sandbox crash. It also means the sandbox is not the network perimeter for every model and tool call. Model-provider traffic and MCP operations originate through the harness path, and they need their own gateway, identity, credential, and network controls.

The documented lifecycle is session-scoped

TrueForge documents the sandbox as off by default for each agent. When enabled and needed, it is provisioned on demand. The sandbox is reused across turns in the same session, so files persist while the conversation continues. After an idle period it is stopped, then archived and eventually deleted according to provider settings.

That lifecycle is more useful than “one disposable container per prompt,” but it introduces state-management questions. A file from Turn 1 can influence Turn 5. A malicious archive extracted early can remain present after the immediate task is forgotten. A dependency installed during one turn can change later execution. Session continuity is a feature; unmanaged state accumulation is a risk.

Applications should label artifacts with their source event, content digest, data classification, and intended lifetime. Before a later turn executes a file, verify that it still belongs to the active task and that the current user is authorized to access it. When reproducibility matters, record the sandbox snapshot or image identity, dependency lock state, and commands that produced the artifact.

Reuse across turns is shown as a feature and a risk. Files can preserve useful work after a pause, but every restored artifact needs provenance, classification, and a lifecycle rule rather than inheriting trust from the session alone.

Credentials outside the sandbox reduce—but do not remove—authority

Keeping model and MCP credentials in the harness prevents arbitrary sandbox code from reading those secrets directly. That is a strong boundary. Yet a sandboxed script may still be able to ask the harness to perform an MCP call through a controlled bridge. The relevant security question becomes: which calls can this code request, with whose identity, using what arguments, and under which policy?

The bridge should expose a narrow capability rather than a generic credential. Tool definitions, subject identity, destination, data classification, cumulative budgets, and approval requirements should be evaluated outside the sandbox. Results returned to code should be minimized because they can become files, logs, or command input inside the environment.

Likewise, the absence of model credentials does not prove the sandbox has no egress. Provider configuration determines network reachability. A robust deployment separately defines outbound destinations, DNS behavior, package installation policy, metadata-service access, filesystem mounts, resource limits, and termination controls. TrueForge orchestrates the sandbox provider; the organization still validates the provider and its configuration against its threat model.

Map the trust boundaries explicitly

Surface