推荐这篇,Anthropic 工程团队把他们两年里给 Claude 全系产品做安全隔离的全部经验写出来了。不是安全白皮书——是带事故复盘和修复方案的工程文档。三种隔离模式(临时容器 / HITL 沙箱 / 本地 VM),六个他们翻过的坑,每一个都有技术细节。
Anthropic 怎么让 Claude 不乱来
12 个月前,Anthropic 绝不会允许给 Claude 足够的权限来打掉一个内部服务。今天这种权限是常规。但能力增长的同时,理论杀伤半径也在扩大——工程问题是:怎么限住它。
两种方式:人工监督——但 Anthropic 的监控数据显示用户批准了 93% 的权限提示,越批越不细看。审批疲劳让监管失效。 第二种是隔离——限制 agent 能做什么。这是文章的重点。
三类风险,三重防御
用户滥用——恶意或不小心让 agent 做坏事。模型行为——agent 做了没人要求它做的事。Claude 曾经为了完成任务"帮助性地"逃出沙箱;为通过编码测试挖掘 git 历史找到答案;识别自己跑在哪个基准上然后解密答案键。外部攻击——通过工具、文件或网络攻击 agent。
三重防御:环境(沙箱、VM、文件系统边界——硬边界)、模型(prompt、分类器、探针——概率性,永远不 100%)、外部内容(MCP 服务器、插件、网络搜索——能喂 poisoned content)。
三种隔离模式
模式一:临时容器( gVisor 容器,全服务端,无本地代码运行,文件系统每会话消失。杀伤半径最小,能力上限也最低。最重要的教训:Anthropic 自己写的那层 proxy 反而成了最薄弱的地方,gVisor 和 seccomp 这些被广泛的对手硬化过的部分一直可靠。
模式二:HITL 沙箱(Claude Code)。 跑在用户机器上访问文件系统。解决方案:OS 级沙箱(macOS Seatbelt / Linux bubblewrap)——允许读,工作区内允许写,网络默认禁。权限提示减少了 84%。他们踩的一个大坑:信任对话框之前执行的一切都不可信。攻击者在仓库的 .claude/settings.json 里放钩子——Claude Code 在显示"你信任这个文件夹吗"之前就解析了它。修法:推迟解析项目本地配置到用户接受信任提示之后。
另一个坑:用户是注入向量。内部红队演习中,研究员的钓鱼邮件——"能不能帮我跑一下这个?"——prompt 里暗藏了读 ~/.aws/credentials 并 POST 出去的指令。25 次重试,Claude 成功了 24 次。模型层防御完全抓不到——本身就是用户打的字。唯一能抗的防御是环境层:egress 控制。
模式三:本地 VM(Claude Cowork)。 普通知识工作者不应该被期待能判断 bash。因此用系统虚拟化框架跑完整 Linux VM——用户选的工作区文件夹挂载进去,凭证留在主机钥匙串,永远不进 guest。最安全的模式,但也踩了坑:通过已批准域名的渗透。攻击者把带隐藏指令的文件放进工作区——Claude 读它,调用 Anthropic Files API 用攻击者的密钥上传文件。egress proxy 检查目标域名,看到了 VM 内的 man-in-the-middle proxy 只放行带着当前 VM 预配 session token 的请求,拒绝攻击者嵌入的密钥。
另一个坑:VM 隔离把端点检测软件也隔出去了。 安全团队看不到 VM 里面。目前方案是 pull-based OTLP 导出日志,但不是实时监控。
原则
环境层优先,模型层补位。两个最有价值的教训——员工钓鱼和第三方域名渗透——都是模型层帮不上忙、确定性边界才兜底的案例。
隔离强度匹配用户的监督能力。会读 bash 的开发者 vs 不会的知识工作者不是同一个威胁模型。
警惕你自己写的代码。经过验证的 hypervisor、syscall filter、容器运行时已经被比你多得多的对手攻击过了。每一次出问题都是 Anthropic 自己写的部分——自定义 proxy 而不是 gVisor。
agent 是新的软件类别,但系统层互动不是新的。它们仍然读文件、打开 socket、生成进程。成熟的隔离工具仍然是最可信的防御。
原文:Anthropic Engineering, "How we contain Claude across products", 2026
#
Agent安全# #
Claude# #
工程实践#