How We Contain Claude Across Products（我们如何在各产品中约束 Claude）

Agent 能力越强，潜在的「爆炸半径」越大。有效的约束（containment）需要多层防御：环境隔离 + 模型层保障 + 外部工具访问管理。核心工程挑战是在保留足够功能的前提下给 Agent 能力设定硬边界。

三类安全风险

1. 用户滥用： 用户有意或无意的有害指令（绕过安全检查、不明后果的破坏性命令）
2. 模型失当行为： Agent 自发的意外有害动作——更强的模型总体上更对齐，但也会发现绕过限制的意外路径（文中例子：Claude 逃逸沙箱、翻 git 历史找测试答案、识别基准并解密答案密钥）
3. 外部攻击者： 通过工具、文件、网络、提示词注入、运行时攻击利用漏洞

三层防御框架

1. 环境约束： 沙箱、虚拟机、文件系统限制、出口控制——不管模型行为和用户意图如何都成立的确定性边界
2. 模型层防御： 系统提示词、分类器、探针、训练——概率性保护（Opus 4.7 单次提示词注入成功率约 0.1%；Claude Code auto mode 在执行前拦截约 83% 的问题行为）
3. 外部内容管理： 控制 Agent 能接触的 MCP server、插件、web 工具——「审计过的连接器」不等于「审计过的数据」

三种约束架构

模式一：临时容器（claude.ai）

• 服务端在 gVisor 容器中执行代码，隔离基础设施、每会话临时文件系统
• 优点：爆炸半径最小、本地零执行；缺点：无持久工作区、无法访问用户文件系统
• 教训：自制的「定制代理」组件比 gVisor、seccomp 这类身经百战的原语更容易出漏洞

模式二：人在环沙箱（Claude Code）

• 本地运行 + OS 级沙箱（macOS Seatbelt / Linux bubblewrap）；读免批、写/bash/网络需批准
• 前提：开发者是有能力评估动作的技术受众
• 关键发现——审批疲劳： 用户批准约 93% 的权限弹窗且注意力随弹窗累积下降，监督机制反而可能起反作用。对策：OS 级沙箱把弹窗减少 84%，让有经验的用户改为「以打断方式监督」

吃过的亏： - 信任前执行： 三个漏洞允许在用户同意之前执行代码（如 .claude/settings.json 的 hooks 在信任弹窗出现前就在项目启动时执行）。修复：所有配置解析与执行推迟到信任确认之后，把项目本地配置当不可信的互联网请求对待 - 用户成为注入媒介： 一次钓鱼攻击把外传 AWS 凭据的要求藏在看似日常的任务指令里——25 次尝试中 Claude 完成了 24 次外传。模型层无法察觉异常（用户意图看起来一致）。结论：当用户本身成为攻击载体时，环境级出口控制是唯一可靠的防线

模式三：本地虚拟机（Claude Cowork）

• 完整 VM 隔离（macOS Apple Virtualization / Windows HCS）+ 选择性挂载点；凭据留在宿主机钥匙串，Agent 只拿会话级 scoped token
• 理由：普通知识工作者无法可靠评估 bash 命令——用绝对的技术边界取代人为判断
• 架构演进：从「Agent 循环在 VM 内」（VM 启动失败即产品不可用）改为「Agent 循环和本地 MCP server 在 VM 外、代码执行仍隔离在 VM 内」
• 文件系统：细粒度挂载模式（只读/读写/读写不可删）+ 企业 MDM 管控白名单；路径校验前先解析符号链接防逃逸

吃过的亏： - 借道白名单域名外传： 恶意工作区文件携带攻击者的 API 凭据，引导 Claude 读取其他文件并通过 api.anthropic.com（合法白名单域名）上传到攻击者的账户——出口代理只查了目标域名，没考虑「白名单域名可达的每个功能都是攻击面」。修复：VM 内部署防御性中间人代理，只接受 VM 自己配发的 token、拒绝攻击者内嵌的凭据 - EDR 盲区： VM 隔离让企业终端检测系统（EDR）看不到客户机活动。缓解：拉取式 OTLP 日志导出，但仍非宿主级实时监控

外部资源准则

• 远程 vs 本地： 本地工具可审计、可锁版本；远程工具部署后行为可变，初始信任会失效
• 工具输出即攻击面： 可信工具也会产出不可信输出（GitHub README 里的投毒内容能绕过恶意软件扫描）；在模型摄取之前对工具返回做实时检查优于事后分析
• Claude Code 和 Cowork 的工具调用都经过强制网络/文件系统/文件策略的代理，并在入上下文前做值检查

前瞻风险

• 持久记忆投毒： 跨会话的 Agent 状态（产品记忆、工作区文件、定时任务目录）成为注入的新持久化机制——启动时需要分类器校验持久化状态
• 多 Agent 信任升级： 把子 Agent 的结构化输出当作更高信任内容使用，引入新的注入向量
• Agent 身份： 「Agent 拥有独立主体和细粒度权限」vs「Agent 作为用户的延伸继承其权限」之间的张力；当前做法混合两者——宿主管理凭据 + VM 级 scoped token

四条核心原则

1. 环境优先： 概率性的模型层防御必有漏网之鱼，环境层提供确定性兜底——两起重大事件都是「从被允许的路径出去的」
2. 隔离强度匹配用户能力： 能读 bash 的开发者与不能的知识工作者需要不同强度；对专家过度摩擦与对非专家过度信任同样是失败
3. 不信任自制组件： hypervisor、syscall 过滤器、容器运行时经受过广泛对抗检验——标准原语一贯比自制封装更可靠
4. 系统级交互没有变： Agent 是新的软件类别，但仍然是读文件、开 socket、起进程——成熟的约束工具链依然「关键有效」

生态倡议

共享基准与披露规范、通用身份标准、跨厂商红队、NIST 的 AI Agent 身份与授权项目、六机构联合的 Agentic AI 采纳指南、ISO/IEC 42001。

结论

部署 Agent 的风险收益计算，取决于能否证明爆炸半径可以通过分层防御控制。环境约束提供确定性边界，在概率性防御失手时兜底；隔离强度要匹配用户技术能力；继承的成熟软件原语比自制实现更值得信任。