Appearance
Sandbox 该隔离什么：Process、Filesystem 与 Network
前置：高风险 Tool 怎样只拿最小权限：Risk、Least Privilege 与 Approval
核心问题：只用容器或只限制文件系统为什么仍不够，Process、Filesystem、Network 三层隔离分别挡住什么攻击面？
用户生成脚本在独立 sandbox process 中运行，即使崩溃也不应终止主 Agent 服务。sandbox 只挂 /workspace ，不挂 $HOME/.ssh 或 Docker socket。
Process Isolation
Process Isolation 限制 Agent 生成或调用的程序在进程层面的能力与相互影响，例如独立 PID namespace、syscall/privilege 边界和可终止的 process tree。它主要回答“一个进程能对其他进程/内核做什么”。
还需配合 filesystem/network/resource/credential 控制。
Filesystem Isolation
Filesystem Isolation 控制执行环境能看到和修改哪些路径、挂载和文件权限，例如只读根目录、工作区白名单和临时目录。它主要回答“代码能读写哪些持久数据”。
工作区应最小挂载，宿主敏感目录默认不可见。
🔍 源码对照：读取外部执行产物也要经过 Capability Scope
精确定位
- 文件：
source/host/runner/shell-terminal-watch.ts - Symbol：
createShellWatchReadAccessor()/pollShellTerminalFile()/SandLocalToolPermissionDeniedError - 深入索引：Code Atlas：10-workspace-sandbox
ts
const scopedContext = context.with(localToolScope, {
agentId: conversationId,
})
const box = await ensureBoxReady(scopedContext, conversationId)
const snapshot = await box.remoteAccessor.read(scopedContext, {
path: terminalOutputPath,
toolCallId,
})对照理解
- 即使只是“读取自己之前命令的输出”，源码也通过 agent-scoped context 和 remote accessor 进入 execution boundary，而不是直接
readFile(hostPath)。 - 如果权限被撤销，watcher 会把它记录成 permission-denied outcome，而不是绕过权限继续读取。
- 这个文件只能证明 filesystem/resource access 的一部分边界；Process namespace、network egress 等仍要继续看
box/、local-exec/和部署策略，不能从一个 watcher 文件推导完整 Sandbox。
Network Isolation
Network Isolation 控制执行环境能连接哪些地址、端口和服务。它不仅是“能不能访问互联网”，还要限制横向访问内部系统。
例如 Sandbox 可以允许：
text
pypi.org / github.com allow
cloud metadata endpoint deny
internal production DB deny
secret service deny即使 Tool 本身没有读取 Secret 的 API，任意 egress 也可能让 Prompt Injection 绕路获取敏感数据。因此网络出口应作为显式 capability 管理。
三种 Isolation 控制的是不同 Blast Radius
三种隔离不是重复保险，而是在限制不同方向的破坏范围：
text
Process isolation → 代码能影响哪些进程/OS 资源
Filesystem isolation → 能读写哪些文件和持久数据
Network isolation → 能连接哪些外部/内部服务例如把 Tool 放进 Container 只能部分解决 process/filesystem 边界；如果容器仍能访问 cloud metadata、内部 DB 和 Secret Service，Prompt Injection 仍可能通过网络把权限放大。
因此 Sandbox policy 应按 capability 组合，而不是只问“有没有用 Docker”。
Isolation Policy 应跟任务/Tool 风险匹配
只做代码搜索的 Agent 可以 read-only workspace + 无外网；依赖安装任务可能临时需要 package registry；浏览器 Agent 需要网络但未必需要 host filesystem。统一给“最强 sandbox”未必可用，统一给“全权限 container”又不安全。
验证时应直接尝试越界：读其他 tenant 文件、访问 metadata service、启动超额进程、写 workspace 外路径。安全边界的测试是证明禁止动作真的失败，而不是 Prompt 里写了不要做。
关联源码
自测
- 一个不可信命令只需要处理
/workspace文件。Sandbox 为什么还要限制 process、filesystem、network 三个不同面？ - 禁止网络但允许读宿主机 secret 文件，系统仍安全吗？这说明 isolation 不能只做哪一层？