Pi / 05
安全模型深入：容器化隔离的实际边界
为什么这个问题值得关注
01 篇已经说明了 Pi 不内置权限系统的设计选择。但”把安全交给容器”是一句话，落到生产环境里要回答更具体的问题：容器隔离的实际边界在哪里？什么场景下这个假设会失效？当它失效时，补救方案的成本有多高？
这不是理论讨论。一个 Agent 拥有 Shell 执行能力意味着它可以做任何操作系统用户能做的事。隔离方案的选择直接决定了”模型幻觉”的最大爆炸半径。
Pi 的显式声明
Pi 的 README 明确列出了它不限制的四类访问：
- 文件系统：可以读写任何路径
- 进程：可以启动、终止任何进程
- 网络：可以访问任何端口和地址
- 凭据：可以读取环境变量、配置文件中的 secrets
这不是缺陷列表，而是接口契约。Pi 告诉你：如果你需要约束这些行为，请在 Pi 外部解决。
三种容器化方案
Gondolin micro-VM
最强隔离级别。每个 Agent 会话运行在独立的轻量虚拟机中，拥有独立的内核、文件系统和网络栈。
- 隔离强度：硬件虚拟化级别，宿主机攻击面极小
- 启动开销：百毫秒级，比传统 VM 快但比容器慢
- 适合场景：多租户 SaaS、处理不受信任的代码、需要合规审计的企业环境
- 代价：资源占用高，宿主机资源共享需要调度，调试困难（无法直接 attach 到 VM 内部进程）
Docker 容器
大多数团队的默认选择。文件系统和网络通过 namespace 隔离，进程通过 cgroup 限制资源。
- 隔离强度：操作系统级别，共享宿主内核
- 启动开销：秒级，CI/CD 流水线中可接受
- 适合场景：开发环境、CI/CD、中等信任级别的自动化
- 代价：共享内核意味着内核漏洞可以逃逸，需要定期更新宿主机
典型配置示例：
services:
pi-agent:
image: pi-agent:latest
read_only: true
tmpfs: ["/tmp"]
network_mode: "none" # 禁止网络访问
volumes:
- ./workspace:/workspace # 只挂载工作目录
cap_drop: ["ALL"]
network_mode: none 加 read_only 加 cap_drop ALL 三重限制，把爆炸半径控制在挂载的 workspace 目录内。
OpenShell sandbox
轻量级进程沙箱，通过 seccomp 和 namespace 限制系统调用。
- 隔离强度：进程级别，比容器弱
- 启动开销：毫秒级，几乎无感
- 适合场景：本地实验、快速原型、信任度较高的场景
- 代价：隔离粒度粗，绕过可能性更高，不适合多租户
容器隔离 vs 内置权限：工程 tradeoff
两种安全路线的核心差异不是”哪个更安全”，而是安全成本在哪里支付。
| 维度 | 容器化隔离（Pi） | 内置权限系统（Claude Code） |
|---|---|---|
| 安全检查时机 | 部署前一次性配置 | 每次工具调用前检查 |
| 运行时开销 | 零（隔离已在环境层生效） | 每次操作增加审批延迟 |
| 粒度 | 粗——按文件系统/网络/进程整体控制 | 细——可以区分读/写/删/某个具体目录 |
| 安全基线维护者 | 运维团队（Dockerfile、VM 配置） | 框架维护者 + 用户配置 |
| 扩展开发负担 | 无需考虑权限声明 | 每个工具必须声明所需权限 |
| 用户理解成本 | 需要理解容器化概念 | 需要理解权限规则语法 |
关键观察：容器化方案的运行时开销为零，但前置投入高。内置权限方案的前置投入低（框架已实现），但每次交互都有成本。对于高频自动化（CI/CD 中每天跑几百次 Agent 任务），零运行时开销的优势显著。对于低频人工交互（开发者偶尔使用 Agent 辅助编码），审批延迟可以接受。
容器化假设什么时候失效
Pi 的安全模型建立在一个核心假设上：Agent 所需的一切资源都可以在容器内提供。以下场景会打破这个假设：
需要宿主机硬件资源
GPU 直通（模型推理、CUDA 编译验证）、USB 设备、特定物理端口。Docker 的 --gpus 和 --device 可以映射设备，但映射就意味着打破隔离——容器可以通过 GPU 驱动访问宿主机内存。
需要宿主机网络服务
Agent 需要访问宿主机上运行的本地数据库、API 网关或 VPN 隧道。network_mode: host 直接废掉网络隔离。端口映射虽然更安全，但增加了配置复杂度。
团队缺乏容器化运维能力
容器配置看起来简单，但生产环境中的容器安全需要：镜像扫描、基础镜像更新、密钥注入（非环境变量）、日志收集、资源限制调优。如果团队没有这些能力，容器反而成为安全盲区——配置错误比没有隔离更危险，因为它给出虚假的安全感。
需要细粒度操作审批
“允许读 src/ 但不允许写 src/core/”——容器做不到这个粒度。文件系统 mount 是目录级别的，不支持读写分离的路径控制。如果你的合规要求需要这种粒度，容器化方案不够用，需要在容器内部加一层权限代理，这等于回到了内置权限路线。
BreachWeave：容器隔离的天然适配场景
BreachWeave 是腾讯云黑客松冠军项目，一个基于 Pi 的多 Agent 渗透测试系统。它的架构说明了什么时候容器化隔离不是”够用”，而是”最优解”：
- 渗透测试 Agent 需要执行恶意代码片段来验证漏洞——这正是容器隔离的最佳用途
- 每个攻击向量的探索运行在独立容器中，互不干扰
- 容器销毁后痕迹消失，不需要清理
- 网络隔离可以精确控制 Agent 的攻击范围（只能触达目标网段）
这个场景下，内置权限系统反而是负担——你不会想让渗透测试 Agent 每次执行 exploit 都弹审批对话框。
与 DSH 策略平面的对比
DeepSeek Harness 的安全方案是策略平面：Approval 插件 + Sandbox 插件 + Policy 引擎。三者可以独立替换。
| 维度 | Pi 容器化 | DSH 策略平面 |
|---|---|---|
| 安全边界定义位置 | 运行环境（Docker/VM 配置） | 代码中（Policy DSL） |
| 可编程性 | 低——容器配置是声明式的 | 高——可以写任意审批逻辑 |
| 动态调整 | 需要重启容器 | 运行时热加载策略 |
| 审计能力 | 依赖外部日志系统 | 内置（Decision Log） |
| 适合 | 边界固定、高频自动化 | 边界动态变化、需要审计追溯 |
DSH 的策略平面更灵活，但复杂度也更高。Pi 的方案更粗暴但运维模型更简单——如果你的安全边界不需要运行时动态调整，容器配置就足够了。
实践建议
- 裸机绝对不要跑不受信任的 Agent 任务。无论用 Pi 还是其他框架，Agent + Shell 执行 + 无隔离 = 灾难等待发生。
- Docker 是默认起点。
read_only+network_mode: none+ 最小化 volume mount 覆盖 80% 场景。 - 细粒度需求出现时再加层。不要预先设计复杂的权限体系。观察实际需要的控制粒度，按需引入。
- 安全配置要版本化。Dockerfile 和 compose 文件进仓库，和代码一样 review。
小结
Pi 的容器化安全模型是一个”该 tradeoff”而非”该回避”的设计选择。它在容器化环境成熟、安全边界固定、运行频率高的场景下是最优解。它在需要细粒度控制、缺乏运维能力、边界动态变化的场景下会失效。
判断它是否适合你的关键问题不是”容器安全吗”，而是”你的安全需求能不能用容器边界表达”。