核心 GUIDE
Sandbox Permissions（沙箱权限）
Sandbox Permission 用来限制 Code/Agent 能读、写、执行与访问哪些 Network Resource，使 Experiment 或 Generated Action 不会默默继承 Host Environment 的完整 Authority。
核心心智模型
把 Sandbox 看成 Capability Envelope。Isolation 限制 Blast Radius，Permission 决定哪些 Resource 可以跨 Boundary、使用什么 Identity；如果 Sandbox 一开始就拿到 Host-level Credential，隔离价值会被削弱。
为什么重要
AI Coding 与 Automation System 经常执行 Untrusted 或 Model-generated Operation。只有 Container 并不能阻止 Secret Exposure、Destructive Mount 或 Unlimited Outbound Call。显式 Permission Design 才能让“运行在 Sandbox”从标签变成真正 Enforceable Security Boundary。
01
只授予 Task 必须的最小 Resource
尽量从 No Host Secret、No Privileged Mode、Read-only/Empty Filesystem 开始。只有 Task 确实需要时，才增加 Narrow Mount、Credential、Command 与 Network Destination。区分 Build-time 与 Run-time Permission，使用 Ephemeral Credential，并记录 Denied Capability Request，让缺失权限可诊断而不是默认扩大 Sandbox。
02
示例：Code-generation Sandbox 能读 Developer Cloud Credential
Local Coding Agent 虽运行在 Container，却为方便挂载整个 Home Directory。Generated Code 会扫描 Config，Dependency Script 也能读取 Cloud Key。改造后只 Mount Repository，提供 Ephemeral Test Credential，并限制 Outbound Destination，模型生成代码就无法继承 Operator Ambient Authority。
常见失败模式
- 认为 Containerization 自动等于 Least Privilege。
- 为了方便 Mount 大范围 Host Directory 或 Long-lived Credential。
- 每次 Permission Error 都直接扩大 Sandbox，而不检查 Task Necessity。
工程启发
- 从 Deny-by-default 开始，只按 Task 增加 Capability。
- Secret 尽量 Ephemeral，并与 Model-visible Filesystem 分离。
- 记录 Denied Operation 与 Permission Change，方便 Review Capability Drift。
关键结论
- 01Sandbox 的安全性取决于跨 Boundary 的 Permission。
- 02Isolation 与 Least Privilege 是互补 Control。
- 03Generated Code 不应继承 Operator 的 Ambient Authority。
阅读记录
这里只记录你真实做过的动作，不代表掌握、熟练或认证。
用于这些学习路径
这个 Concept 会在多个 canonical 学习路径中复用。