Permissions, Sandboxing, and Human Approval
Permissions, Sandboxing, and Human Approval
Fact-check status
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
- Permissions must be enforced by code or infrastructure, not by asking the model to behave. S1
- Require approval according to consequence and reversibility, not merely because a model expresses uncertainty. S1
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
- Identity: who is requesting and which workload acts? S1
- Scope: what resources and actions are allowed? S1
- Isolation: what can execution reach if it behaves unexpectedly? S1
- Preview: what exact effect is proposed? S1
- Approval: does the current human authorize this effect now? S1
- Commit: re-check state and policy at execution time. S1
- 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.