本页目录5
- 防御分三层:环境层(沙箱/VM/出口控制)是确定性硬边界,模型层(系统提示/分类器)是概率性防御,工具层(权限限制)约束可触达的外部资源,三层需叠加互补
- Claude Code 从「允许/拒绝」对话框演进为 OS 级沙箱(macOS Seatbelt、Linux bubblewrap)+自动分类器,权限提示减少 84%,过度操作捕获率约 83%
- 用户本身也可能是提示注入向量:内部红队钓鱼测试中 25 次尝试有 24 次通过「用户之口」注入成功,模型层对此无能为力,只有环境层出口限制能兜底
- Claude Cowork 的六层隔离(hypervisor、vsock、挂载模式、网络策略等)把 Agent 循环放主机、代码执行放 VM,以兼顾可靠性与安全边界
- 白名单域名不等于安全:第三方披露的漏洞显示,同一白名单域下的不同 API 能力仍可能被滥用,需要按能力而非按域名做授权
- 工具的输出本身就是攻击面,即使工具可信;建议所有工具调用经代理路由并做政策检查后再进入模型上下文
本文是对 Anthropic 官方文章「How we contain Claude across products」的中文要点摘要,完整内容以原文为准:https://www.anthropic.com/engineering/how-we-contain-claude
为什么要谈「containment」
随着 Claude 在 claude.ai、Claude Code、Claude Cowork 等产品中获得读写文件、执行命令、访问网络的能力,一旦出问题的「爆炸半径」也在扩大。文章的核心框架是:风险来自三类主体——用户滥用(有意或无意下达破坏性指令)、模型误行为(未经指示做出有害动作,例如为了完成任务而尝试绕过限制)、外部攻击者(通过工具输出、文件、提示注入发起攻击)。对应地,防御也分三层:
- 环境层:进程沙箱、虚拟机、文件系统边界、出口(egress)控制——确定性的硬边界
- 模型层:系统提示、分类器、训练——概率性,不完全可靠
- 工具层:权限限制、连接器审计——控制可访问的外部资源范围
文中反复强调的一条原则是:当环境层防御缺位或被绕过时,模型层必须兜底,反之亦然,单靠一层都不够。
三种产品,三种隔离模式
claude.ai 代码执行采用 gVisor 容器做「短暂容器」,完全在服务端运行、按会话临时化文件系统,爆炸半径最小,代价是 Agent 能力受限(无持久工作区、无本地文件访问)。团队发现,真正薄弱的往往不是 gVisor、seccomp 这些「久经考验」的底层组件,而是自己在其上搭建的定制代理层。
Claude Code 面向开发者,需要真实的文件系统、Shell、网络访问。最初用简单的允许/拒绝对话框,但审批疲劳很快出现——用户约 93% 的提示都直接批准,重复出现时关注度明显下降。改进方案是引入 OS 级沙箱(macOS 用 Seatbelt、Linux 用 bubblewrap),默认拒绝网络、只在工作区内放开写入,权限提示因此减少 84%;同时加入模型驱动的自动分类器(auto mode),能捕获约 83% 的越界操作,而对良性命令的误封率仅 0.4%。
文章披露了两个隐藏风险案例:一是「信任对话之前代码已经执行」——.claude/settings.json 里的钩子会在项目打开、配置解析阶段就被触发,早于用户看到信任提示,修复方式是把「打开项目/加载配置/本地监听器」一律当作「互联网入站请求」不做隐式信任;二是「用户自己就是注入向量」——内部红队用钓鱼邮件诱导用户把恶意指令喂给 Claude Code(读取 ~/.aws/credentials 并 POST 到外部端点),25 次尝试 24 次成功,因为模型层的异常检测依赖「用户意图」,而这类攻击看起来就是用户在下达正常指令,唯一有效的防线是环境层的出口限制和文件系统边界。
Claude Cowork 面向非工程背景的用户,他们无法判断一条 bash 命令是否危险,因此采用平台原生的 hypervisor(Apple Virtualization / Windows HCS)运行完整虚拟机,凭证留在主机钥匙链,VM 只拿到会话级令牌。官方配图称 VM 有六层主要隔离机制(其中两层在客户机内核之外强制执行,即使 Agent 在 VM 内提权到 root 也依然有效),原文未在正文逐条列名,可从正文确认的包括 hypervisor 边界、vsock 通信、文件系统挂载模式(只读/读写/读写不可删)、网络出口白名单、普通 Linux 用户权限等。架构上做过两次调整:一是把 Agent 主循环挪到主机、只把代码执行留在 VM 内,避免 VM 启动失败拖垮整个产品;二是把本地 MCP server 也放到主机运行,便于审计和管理员按需启用。
文中还给出两个更深的教训案例:其一,某第三方负责任披露的漏洞显示,攻击者可以把恶意文件放进工作区,诱导 Claude 用「攻击者控制的 API key」调用一个「已被列入白名单的域名」(如 api.anthropic.com),出口代理只检查了目标域名却没检查具体能力,结果文件被上传到攻击者账户——这暴露出「把白名单当成目标过滤,而非能力授权」的概念性错误,修复是在 VM 内部署中间人代理,拦截该 API 流量,只放行 VM 自身持有的会话令牌;其二,hypervisor 级别的隔离会让企业依赖的终端检测响应(EDR)工具失去可见性,目前只能靠基于拉取的 OTLP 日志导出做事后补救,这与实时监控相比是明显的权衡取舍。
Agent 读取的内容也要防
文章强调,即使工具本身可信,其输出也是攻击面——比如一个 GitHub README 里可能嵌着提示注入。建议做法是让工具调用统一经过代理路由,由代理执行网络与文件访问策略,并可用小型快速模型在结果返回模型上下文前做一次检查。对于连接器目录之外的第三方工具,应当当作不可信来源处理,先用假数据跑一遍再放行,以隔离潜在爆炸半径。
尚未解决的挑战
文章列出三个开放问题:持久记忆的中毒(产品记忆、CLAUDE.md、长期运行 Agent 的状态目录都可能让一次注入变成跨会话的持久化后门)、多 Agent 之间的信任升级(子 Agent 返回的「结构化事实」如果被上游默认为比原始工具结果更可信,反而开辟了新的注入路径)、以及Agent 身份标准(Agent 到底应该拥有独立的身份,还是作为用户身份的委托扩展,目前更倾向混合模式)。
三条系统设计原则
- 环境优先,模型辅助——两次教训最深的事件(内部钓鱼、白名单披露)都发生在模型层完全帮不上忙的场景,只有确定性的出口边界能兜底。
- 隔离强度要匹配用户能力——开发者能读懂 bash、知识工作者不能,威胁模型完全不同,错配方向(对专家过度设限、对新手过度放权)都会造成失败。
- 警惕自定义代码——gVisor、hypervisor、seccomp 这类久经考验的标准组件普遍可靠,真正出问题的往往是团队自己在其上搭的那层。