> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/handbook/3.-runtime-sandbox-and-autonomy/3.1-what-even-is-an-ai-sandbox.md). # 3.1 What Even is an AI Sandbox? What AI sandboxes give you, which AI work products support them, and how security teams should configure, test, and evidence the boundary. *Last reviewed: August 18, 2026* {% hint style="info" %} A sandbox is a control boundary. It limits what an agent can read, write, execute, and reach over the network. It is not, by itself, a complete audit trail. {% endhint %} ## The short version An AI sandbox gives you **control**. It narrows the blast radius when an agent works with files, code, tools, connectors, and the network. A good sandbox answers four questions before a task starts: * What can the agent read? * What can it write? * What can it execute? * What can it reach over the network? The sandbox gives some **visibility** when the platform records its mode, working directory, allowed paths, blocked paths, approval decisions, and network denials. For investigations, that is useful context, but it is not enough. Pair sandbox settings with OpenTelemetry, provider audit records, endpoint logs, SaaS audit logs, and the approval history for the task. The practical rollout lesson from ChatGPT Work and Claude Cowork is simple: separate **hosted work** from **local execution**. A local Codex or Claude Code sandbox does not automatically protect every hosted Work or Cowork task. Browser actions, Computer Use, connectors, scheduled tasks, artifacts, and publishing rights need their own control review. ## What it gives you | Security value | What the sandbox does | What it does not do | | ---------------- | ------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | Control | Limits file access, write scope, command execution, network egress, and sometimes subprocess behavior. | It does not decide who should have the product, connector, or data source in the first place. | | Containment | Keeps a mistaken or hijacked task from touching unrelated files, secrets, internal networks, or production systems. | It does not make prompt injection harmless if the approved workspace already contains sensitive data. | | Approval support | Forces sensitive actions through a human approval step when configured that way. | It does not guarantee that the approver understood the full downstream effect. | | Evidence context | Records mode, allowed paths, network policy, denials, and sometimes approval outcomes. | It does not replace runtime telemetry or target-system logs. | Use the sandbox as the floor for agentic work, not the ceiling of the control program. ## Product support | Product | Sandbox support | What security gets | Watch-outs | | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Claude Cowork | Yes, for remote sessions by default, with local execution still relevant for some desktop deployments. | Per-session temporary isolation, proxy-mediated egress, no private-network reach by default, and Desktop-mediated local file access. | Chrome, Computer Use, connectors, scheduled work, and shared artifacts still need separate controls and evidence. | | Claude Code | Yes. Claude Code has an explicit sandbox on macOS, Linux, and WSL2. | Local file and network boundaries, `/sandbox` inspection, managed settings, fail-closed behavior, and controls for unsandboxed commands. | Native Windows support is different. Full local access and unmanaged settings should be exception-only. | | Claude Tag | Limited from a practitioner sandbox-control perspective. Tag work runs in Anthropic-managed thread isolation, but reviewed docs do not expose a user-tunable sandbox mode. | Isolation for thread work, Agent Proxy controls, default-deny outbound hosts, and credential injection outside the sandbox. | Treat Tag as a channel, service-account, Agent Proxy, and audit problem. Do not manage it like Claude Code. | | ChatGPT Codex | Yes, especially for local Codex. | `read-only`, `workspace-write`, and full-access style modes, approval policy, working-directory scope, and network restrictions. | `danger-full-access` removes the useful boundary. Local settings do not cover every hosted Work surface. | | ChatGPT Work | Partial. Hosted Work runs in managed environments; desktop Work can touch local files and apps with permission. | Hosted task isolation, workspace access controls, connector controls, and local desktop permissions where applicable. | The ChatGPT Compliance Logs Platform may capture prompts and responses without file/action/tool-call detail. Do not assume Codex local sandbox settings cover hosted Work. | ## How to use it technically Start by classifying the work surface. A coding task in a local repository needs a different boundary from a hosted research task, a browser-driven task, or a scheduled task that can run unattended. For local coding-agent work, the technical baseline should look like this: 1. Use the smallest practical working directory. Keep home directories, cloud drives, password stores, SSH material, API keys, and unrelated repos outside scope. 2. Default to read-only or workspace-write. Full access belongs in disposable environments, not normal employee machines. 3. Keep broad network access off unless the workflow needs it. Prefer allowlists over open outbound access. 4. Block escape hatches. If the platform supports fail-closed behavior when the sandbox is unavailable, enable it. 5. Separate approval policy from sandbox policy, but review them together. A permissive approval mode can quietly widen what runs without friction. 6. Record the effective policy at session start: product, user, group, sandbox mode, working directory, writable roots, denied paths, network mode, and approval mode. For Codex local work, a conservative managed profile is the useful starting point: ```toml sandbox_mode = "workspace-write" approval_policy = "on-request" ``` For Claude Code, use managed settings to enforce the equivalent posture: sandbox enabled, fail if the sandbox is unavailable, restrict unsandboxed commands, restrict unmanaged read paths and unmanaged network domains where the product supports it, and keep the `/sandbox` view available for operator inspection. For hosted Work and Cowork, do not stop at the word "sandbox." Check where code actually runs, whether browser or Computer Use is involved, whether connectors can read or write, whether scheduled tasks can run without a human present, and where local files are copied for processing. ## How to use it as a practitioner A useful rollout is more operational than theoretical. * Create separate groups for ChatGPT Work, ChatGPT Codex, Claude Cowork, Claude Code, admins, connector builders, and exception users. * Block full-access local modes for normal users. Make the exception path explicit, time-limited, and tied to disposable environments. * Treat browser automation, Computer Use, scheduled tasks, publishing, and connector write actions as elevated risk, even when the core runtime is sandboxed. * Require a working-directory standard for code tasks. A repo root is reasonable. A home directory is not. * Run a canary test before production: denied secret file read, denied write outside workspace, denied network call, approved safe edit, and approved safe command. * Keep sandbox evidence near the runtime telemetry. Investigators need to know whether a task was read-only, workspace-write, remote sandboxed, or full access before they can read the rest of the logs correctly. The clearest practitioner mistake is to say "the agent is sandboxed" without naming the product, surface, mode, network policy, and approval policy. Those details are the control. ## What to evidence For each sandboxed surface, collect enough to reconstruct the boundary: | Evidence | Why it matters | | ----------------------------------- | ----------------------------------------------------------------------------------------------------- | | Product and surface | ChatGPT Work web, Codex local, Claude Cowork remote, and Claude Code local do not share one boundary. | | User and group | Confirms the task ran under an approved role and policy set. | | Sandbox mode | Shows whether the task was read-only, workspace-write, remote sandboxed, or effectively unrestricted. | | Working directory and mounted paths | Reveals whether sensitive folders were inside the boundary. | | Network policy | Shows whether outbound access was blocked, allowlisted, proxied, or open. | | Approval settings and decisions | Explains why a risky action did or did not run. | | Denials | High-signal evidence of the control doing work. | | Linked telemetry | Connects the boundary to the prompt, tool call, target system, and outcome. | ## Questions to ask before enabling a product * Which tasks run locally, and which run in a hosted environment? * Can admins enforce sandbox mode, or can users change it? * What folders are readable and writable by default? * Is network access off, allowlisted, proxied, or open? * Can a browser, Computer Use surface, connector, plugin, MCP server, or hook bypass the sandbox boundary? * Does the sandbox fail closed when unavailable? * Where do denials and approval outcomes appear? * How long is the evidence retained? ## Sources and related guidance * [Securing ChatGPT Work: A Practitioner's Guide](https://www.harmonic.security/resources/securing-chatgpt-work-a-practitioners-guide) * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) * [Claude Code sandboxing](https://code.claude.com/docs/en/sandboxing) * [Claude Cowork architecture overview](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview) * [Claude Tag security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data) * [Codex sandboxing](https://developers.openai.com/codex/concepts/sandboxing) * [ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex) ## Related handbook guidance * [3. Runtime, Sandbox & Autonomy](/handbook/3.-runtime-sandbox-and-autonomy.md) * [3.2 Approval policies and least-privilege autonomy](/handbook/3.-runtime-sandbox-and-autonomy/3.2-approval-policies-and-least-privilege-autonomy.md) * [3.3 Network egress control](/handbook/3.-runtime-sandbox-and-autonomy/3.3-network-egress-control.md) * [3.8 File and filesystem access controls](/handbook/3.-runtime-sandbox-and-autonomy/3.8-file-and-filesystem-access-controls.md) * [5.1 Prompt injection: the connective risk](/handbook/5.-threats-and-adversarial/5.1-prompt-injection-the-connective-risk.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://handbook.harmonic.security/handbook/3.-runtime-sandbox-and-autonomy/3.1-what-even-is-an-ai-sandbox.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.