RU
Get in touch
Chapter 16

Separate Sandbox, Approvals, and Secrets

A sandbox answers where the process can reach. An approval decides when to stop. A secret store defines which credentials are available at all. None of these layers replaces the others - and confusing them gives a false sense of protection.

Five controls and the question each answers are convenient to keep in one table.

Control · Question · Example of denial

  • Tool permission - Can the action run automatically?; Require approval for the deploy tool
  • Filesystem sandbox - Which paths are available to the process?; Forbid writes outside the workspace
  • Network policy - Which destinations are reachable?; Allow only the registry and the test service
  • Secret scope - Which credentials are issued to the task?; Only a read-only token for the test tenant
  • Application authorization - What is the identity allowed to do?; Forbid the production object regardless of the prompt

The three products document their boundaries differently, and you need to know them precisely. In Codex, sandbox mode and approval policy are separate settings; for local CLI and IDE the default has the network off and writes limited to the active workspace. In Claude Code, permission rules apply to tools, while the OS sandbox limits Bash and its child processes, but MCP servers and hooks stay separate host processes unless the whole Claude Code is isolated by an external container. In Cursor, the run modes govern approvals for shell, MCP, and Fetch, and the official documentation says plainly that the auto-review classifier is not a security boundary.

To run a specific task through the choice of boundaries - sandbox, network, secrets, approval - use the lab.

Interactive lab 4

Set the run boundaries

A trusted repository doesn't cancel the sandbox: check the active config and dirty files.
Keep the filesystem read-only.
Network deny.
External side effects aren't needed; don't grant write credentials.

And a rule more reliable than any appendix to a prompt.

Don't mount secrets out of habit. If the test doesn't use a cloud account, don't pass a cloud token. If Git read is needed, don't grant write. The most reliable secret for a task is the one that isn't in the environment. Application authorization must forbid the production object regardless of what the prompt says.

Rights and boundaries are set. Now let's turn tests from a final ritual into feedback that leads the agent to the cause.

Knowledge check

What does secret scope define, unlike sandbox and approval?

Links