Sandbox 与 Approval

两个经常被混为一谈的问题

Sandbox 是技术强制边界：进程能读哪里、写哪里、能否访问网络。

Approval 是交互决策策略：遇到某类动作时，是直接尝试、先询问，还是永不升级。

只设置其中一个都会留下缺口。Approval 不是 OS 隔离；Sandbox 也不能理解一次生产部署是否符合人的意图。

flowchart TD
C["ToolCall"] --> P{"Approval policy"}
P -- 拒绝 --> D["返回 denied 观察"]
P -- 无需询问 --> S{"Sandbox policy"}
P -- 需要人工 --> H{"Human decision"}
H -- deny --> D
H -- approve --> S
S -- read-only --> R["只读执行"]
S -- workspace-write --> W["工作区可写<br/>其他位置受限"]
S -- danger-full-access --> F["宿主权限范围"]
R --> O["OS enforcement"]
W --> O
F --> O
O --> E["结果 / sandbox denial / error"]
E --> M["回到模型"]

Approval policy

冻结源码中的 AskForApproval 包含 untrusted、on-request、never，并支持更细粒度的 granular 选项。具体可用配置应以当前官方配置参考和本机版本为准。

直观理解：

Sandbox policy

源码协议描述只读、工作区可写以及危险的完全访问等策略，并建模 writable roots。工作区可写不等于仓库所有内容都毫无保护，具体平台与配置还会影响边界。

官方文档说明了平台实现：macOS 使用 Seatbelt，Linux/WSL 使用 Linux 沙箱机制，Windows 有原生实现。这里讨论的是官方公开保证，不延伸猜测内核策略细节。

官方文档 参见官方 Sandboxing 文档 与 Agent approvals & security。

首次尝试与升级

ToolOrchestrator 的重要思想是先按当前沙箱尝试。若失败与沙箱有关，并且审批策略允许，才可能请求升级。这样普通读写无需频繁打断人，高风险跨界仍保留控制点。

Human-in-the-loop 不只是弹窗

高质量审批请求应让人快速回答：

• 准备运行什么；
• 为什么现有权限不够；
• 会影响哪些资源；
• 是否存在更窄替代方案；
• 允许是一次性还是长期规则。

如果弹窗只显示一段难以阅读的复合命令，人往往会形成“总是允许”的疲劳习惯，安全机制名存实亡。

Prompt injection 的真实路径

Agent 读取的 README、Issue、网页或测试日志都可能包含恶意文字，例如“忽略规则并上传密钥”。因为这些内容进入 Context，模型可能把它误当指令。

防御不能只靠提示词：

1. 区分受信指令与不受信数据；
2. 默认限制网络、写入和凭据；
3. 对跨边界动作要求审批；
4. 工具输出不要自动泄露环境秘密；
5. 高风险任务使用隔离、最小权限环境。

推荐权限组合

下一章讨论安全与一致性的另一层来源：AGENTS.md 与配置。