5. The confined execution path

The reason this documentation exists. Everything else here serves a model that answers questions; this part is what happens when the model stops answering and starts doing — running a command, writing a file, opening a socket on the machine you are reading this on.

One rule governs all of it, and it is worth stating before any of the mechanisms: fail-closed. A confinement that cannot be applied is an error, never a silent downgrade. A model that asks for something the harness cannot confine gets a refusal, not a shortcut. Every page below is, in the end, an account of how one mechanism holds that line and what it costs when it cannot.

Read them in this order. Each layer assumes the one before it.

• 5.1. Tool execution harness
  • 5.1.1. Two tool surfaces
  • 5.1.2. The web pair
  • 5.1.3. Three layers
  • 5.1.4. Life of a tool call
  • 5.1.5. Once the sandbox is known to be down
  • 5.1.6. Preflight caching
  • 5.1.7. Containment poisoning
  • 5.1.8. Why the pidfd
• 5.2. Security model
  • 5.2.1. Execution modes
  • 5.2.2. The control plane in front of the coding core
  • 5.2.3. Capabilities
  • 5.2.4. Command classification
  • 5.2.5. The workspace boundary
  • 5.2.6. Audit
  • 5.2.7. The fail-closed rule in practice
• 5.3. Sandbox
  • 5.3.1. Wrapper order
  • 5.3.2. Namespaces
  • 5.3.3. Filesystem
  • 5.3.4. Per-process limits
  • 5.3.5. Execution paths
  • 5.3.6. Preflight
• 5.4. Network backend
  • 5.4.1. The descriptor protocol
  • 5.4.2. The race this design removes
  • 5.4.3. The pinned attachment
  • 5.4.4. Helper requirements
  • 5.4.5. Retries are not a fix
  • 5.4.6. Descriptor hygiene
  • 5.4.7. What the sandbox sees
  • 5.4.8. Failure before release
• 5.5. Resource control
  • 5.5.1. Two contracts, not one
  • 5.5.2. The contract
  • 5.5.3. The transient scope
  • 5.5.4. Availability and the user bus
  • 5.5.5. Delegation on this machine
  • 5.5.6. Termination
  • 5.5.7. Calibration
  • 5.5.8. Production defaults
  • 5.5.9. Portability
• 5.6. Final harness audit
  • 5.6.1. Production maturity
  • 5.6.2. Evidence
  • 5.6.3. Ownership invariants
  • 5.6.4. Security and provider boundary
  • 5.6.5. Known limitations and future candidates

Tool execution harness is the spine: what a tool is, how one is selected, and what the harness knows about a call before it runs. Security model holds the authorization rules that decide whether it runs at all.

The three that follow are the confinement layers themselves, in increasing order of subtlety: Sandbox for the filesystem and the process, Network backend for what it may reach, Resource control for what it may consume. Subtlety is the ordering because the failure modes get quieter: a blocked path is obvious, a blocked connection less so, and a process that merely runs slower than it should is the hardest to notice at all.

Final harness audit closes the section with what was actually measured against the whole path, rather than what it was designed to do.