Permissions, Sandboxing, and Human Approval

Permissions, Sandboxing, and Human Approval

Fact-check status

Reviewed claim by claim on 2026-09-02 against the primary or official sources identified inline as S1 and S2. Recommendations are design guidance unless a cited standard makes them normative.

Key jargon

Term Plain-language meaning
Least privilege Granting only the access needed for a specific task and duration. S1
Sandbox An enforced execution boundary limiting files, network, processes, or other resources. S1
Approval gate A pause requiring an authorized human decision before a sensitive action. S1
Blast radius The maximum harm possible if a component fails or is compromised. S1

Key concepts

Concept map

flowchart LR
    A["Model requests capability"] --> B["Policy narrows permission"]
    B --> C["Sandbox contains execution"]
    C --> D["Human approves high impact"]

Diagram semantics verified against S1 and S2 on 2026-09-02.

Control stack

  1. Identity: who is requesting and which workload acts? S1
  2. Scope: what resources and actions are allowed? S1
  3. Isolation: what can execution reach if it behaves unexpectedly? S1
  4. Preview: what exact effect is proposed? S1
  5. Approval: does the current human authorize this effect now? S1
  6. Commit: re-check state and policy at execution time. S1
  7. Evidence: record outcome and any external effect identifier. S1

Standing permission is convenient but broad. Per-action approval is safer only when the preview is comprehensible and the reviewer has time and context. Automated reviewers also need evaluation. S1

Sandbox rule

Assume model-generated code and untrusted content can be hostile. Use disposable environments, no ambient credentials, restricted filesystem/network, resource limits, and explicit artifact export. S1

Exercise

Classify ten hypothetical tools as read-only, reversible write, destructive write, external communication, or financial/legal effect. Define approval and isolation for each.