iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To let an AI agent run code or use tools safely, separate what the model may propose from what trusted infrastructure permits it to execute. Keep the agent harness and sensitive control-plane services outside model-directed compute, run work in an isolated environment with narrowly scoped files and network access, broker credentials, and independently authorize consequential actions at the point of execution. A prompt or approval dialog alone is not a security boundary.
What an execution boundary means
An execution boundary separates the agent’s control plane from the environment where model-directed work takes place. In OpenAI’s Agents SDK documentation, the harness manages the agent loop, model calls, tool routing, handoffs, approvals, tracing, recovery, and run state; the sandbox is the execution plane for work such as reading and writing files, running commands, installing dependencies, using mounted storage, exposing ports, and saving state. OpenAI’s sandbox agents documentation describes this distinction.
The important idea is not that every model call needs a sandbox. A short response with no persistent workspace may need only a simpler runtime. Isolation becomes more important when the task requires a workspace, code execution, tools, mounted data, generated artifacts, preview services, or resumable work. Choose a boundary based on what the agent can reach and the consequences of its actions.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Keep sensitive application functions—such as authentication, billing, audit records, human review, and recovery—under application control rather than placing them inside model-directed compute. The model can request an operation; trusted components should decide whether that particular operation is permitted.
#1 Best Overall
Why the boundary matters
Untrusted input can influence actions
Agents may read content that contains manipulated instructions and also have tools that can change files, call services, or communicate externally. That combination creates a route from misleading input to real side effects. OWASP’s AI Agent Security Cheat Sheet recommends validating authorization, scope, privileges, and approval state independently before execution. In practical terms: the agent can propose an action, but a policy service or execution component should independently validate scope, privilege, and approval state before execution.
Every action path needs controls
A visible shell command is only one path to impact. Filesystem access, subprocesses, mounted storage, network requests, tool servers, and MCP connections can also carry risk. OpenAI notes that agent-generated code can access files, credentials, and network resources available to its environment in its sandbox security guidance. Anthropic’s 2025 sandboxing article describes OS-level restrictions that also apply to commands and subprocesses launched from the sandboxed command. That is a description of Anthropic’s implementation, not a guarantee that every agent sandbox controls every connector in the same way.
Isolation requires more than one control
Filesystem and network restrictions address different paths. Filesystem controls limit what local data code can read or alter; network controls limit where it can send data or reach services. Anthropic explicitly presents them as complementary in its article, “Beyond permission prompts: making Claude Code more secure and autonomous with sandboxing”, published October 20, 2025. Neither control replaces the other.
How to design the boundary
1. Keep control-plane services trusted
Run identity checks, authorization, billing, audit logging, human review, and recovery in infrastructure controlled by the application. Give the execution environment only the workspace, mounts, packages, and tools needed for the current task. Where workloads must not share data, use separate per-user or per-workload environments.
For stateful jobs, define what persists, how a session resumes, and what is deleted when the work ends. Persistence helps with long-running work, but it also creates data and state that need governance.
2. Scope files and mounts
Define a workspace contract for each session: which inputs, repositories, output directories, and mounts the agent may use. Mount only the data necessary for the task, and review artifacts before moving them out of the isolated environment—especially if private documents or other mounted data were available.
For self-hosted environments, Anthropic’s self-hosted sandbox security model assigns operational responsibilities to the operator. Relevant hardening measures include running processes as non-root, removing unnecessary Linux capabilities, considering a read-only root filesystem, and mounting only required directories.
3. Restrict network paths
Start with outbound access denied unless a workflow requires it, then allow only necessary destinations. Account for where each connection originates: an executor in your infrastructure and a remote MCP connection may use different network paths. A proxy can enforce destination rules and attach scoped credentials to approved requests.
Do not assume that restricting network access protects local files, or that limiting file access prevents data from being sent through an allowed connection. Treat the two as separate controls.
4. Keep credentials out of model-directed execution
Do not put long-lived application keys in prompts, instructions, images, source code, or logs. OpenAI states that an executor environment key is readable by agent-generated code and recommends keeping the application key outside that environment. Environment variables are not secret from code running in the same environment.
For third-party APIs, use a trusted proxy or application-side function that retains the credentials, checks the request, and returns only the result the agent needs. Use scoped, short-lived credentials where access must be delegated.
Free tools Windows power users keep installed
One-click scans. No signup required.
5. Authorize each consequential action at dispatch
Enforce deterministic policy checks in the component that actually dispatches an action—not only in the prompt or user interface. Check the actor, tool, target, normalized parameters, and required approval state. Classify actions by risk; a narrowly defined low-risk action may be allowed without review, while unknown or high-impact actions should require stronger controls.
For consequential operations, bind approval to the specific operation and its parameters, with a timestamp and expiry. Add replay protection and step-up authentication for critical actions. Make operations idempotent when possible, and fail closed if authorization, approval, or audit checks fail.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choosing a hosted or self-hosted approach
Provider documentation describes hosted and self-hosted patterns, but it does not establish an independent cross-vendor security benchmark. Compare deployments against the needs and responsibilities that matter to your workload rather than treating a product label as proof of equivalent isolation.
| Decision axis | Questions to answer |
|---|---|
| Trust boundary and ownership | Who operates the harness, execution worker, sandbox image, and tool processes? What responsibilities remain with your team? |
| Isolation scope | Are files, subprocesses, mounted storage, and network access controlled separately? Which tools or MCP servers run inside the same boundary? |
| Network control | Can outbound destinations be allowlisted? Is a proxy used? Where do remote tool connections originate? |
| Credential exposure | Are application keys kept outside execution? Are credentials scoped per session, and can a proxy broker third-party access? |
| Data location and lifecycle | Where do session content, memory copies, logs, and artifacts live? Who retains and deletes them? |
| Operational fit | Does the task need resumable work, persistent state, package installation, mounted data, or exposed ports? |
Provider guidance is specific to each provider’s documented design and deployment assumptions; it does not independently verify security effectiveness or establish that two providers’ boundaries are equivalent. For self-hosted systems, the operator also owns runtime hardening, egress rules, data retention, image integrity, and isolation between tools within the sandbox.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesWhat sandboxing does—and does not—show
Anthropic reported that its internal Claude Code usage had 84% fewer permission prompts after introducing sandbox boundaries. This is a vendor-reported internal observation from 2025, not an independent test, a measure of attacks prevented, or a result teams should expect to reproduce. Fewer prompts are not by themselves evidence that a system is secure.
A sandbox changes where work runs and what resources it can reach; it does not remove the need to govern tools, credentials, data, approvals, and runtime configuration. The effective boundary is the combination of isolation and the trusted policies that determine which operations may cross it.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
