Module 22 · 55 min

Permissions Are Not a Sandbox

You can lay out the seven layers between an agent and real damage, and place any given control in the right one instead of trusting it to do another layer's job.

Workbench tag
module-22
Draft

This page is not written yet. The outline below is the plan of record from curriculum/BUILD_TRACK_PLAN.md; the prose, the code, and the verified block land with the workbench’s module-22 tag.

What this page will cover:

  • The layer stack, kept distinct: consent, permission policy, hooks, capability, process and OS, network, credentials. Each layer does one job, and trusting one to cover another’s is the mistake this module is built around.
  • How rules actually match: bash commands parsed into a syntax tree, with unparseable constructs requiring explicit approval. Claude Code matches the command’s shape, not its consequences, yes, really.
  • The scope of bash sandboxing per the sandbox-environments page: Bash and its children, and none of the file tools, MCP tools, or hooks.
  • The proxy pattern from the secure-deployment page: your proxy injects the credential, so the agent never holds it.
A sealed conduit set into a wall, with a key visible but unreachable behind a small glazed inspection port.
  • Ship: a PreToolUse hook enforcing app policy, plus an egress-restricted container profile for the workbench.