Claude在测试里“不勒索”了，这当然是好消息。

但更刺眼的是另一件事：Anthropic现在花了一整篇工程博客解释，怎样把Claude关在产品边界里。claude.ai、Claude Code、Claude Cowork，不同产品、不同隔离方式、不同风险半径。

这说明一个变化：AI安全的主战场，正在从“模型脑子里有没有坏念头”，转向“模型拿到工具后能碰到什么”。

相比只看红队测试和对齐训练，Anthropic这篇工程披露补上了更现实的一块：模型行为概率只是风险的一半，另一半是事故发生后能炸多远。前者靠训练、分类器、系统提示压低；后者只能靠沙箱、虚拟机、文件权限、出站网络控制硬挡。

发生了什么：Claude安全从“变乖”走到“关门”

Anthropic最近发布工程博客《The ways we contain Claude across products》，解释它如何限制Claude在不同产品里的权限。

几个关键事实很短：

  • claude.ai里的代码执行，跑在服务端隔离容器里，用gVisor等方式保护基础设施和租户隔离。
  • Claude Code跑在用户本机，风险更大，因为它可能碰到真实项目、shell、配置文件、凭据。
  • Claude Code早期依赖权限弹窗：读操作默认允许，写入、bash、网络访问要用户批准。
  • Anthropic遥测显示，用户批准了约93%的权限请求。
  • 后来Claude Code引入auto mode，并在macOS上用Seatbelt、Linux上用bubblewrap做OS级沙箱：工作区内可写，网络默认拒绝，权限提示量减少84%。

这个数字很要命。

93%的批准率说明，弹窗不是安全边界。它更像电梯里的“请勿超载”提示，真正顶事的是钢缆和刹车。

旧的安全叙事里，大家更关心Claude会不会在极端情境下勒索、撒谎、谋取自保。Anthropic之前的安全更新也把焦点放在这类红队测试上，并提到训练语料里那些“坏AI故事”可能会把模型带进戏剧化脚本：人类写了太多AI失控故事，模型在奇怪测试里也学会了按这个故事演。

这条线没有错。

但现在看，它只解释了“模型为什么会那样回答”。工程博客解释的是另一件事：就算模型某次真的被带偏了，它有没有机会读到密钥、跑命令、连外网、把数据送出去。

这才是产品级安全。

为什么重要：低概率在大规模部署里不会消失

Anthropic把代理风险分成三类：

  • 用户误用或恶意使用；
  • 模型自己做出危险行为；
  • 外部攻击者通过文件、网页、工具、连接器注入指令。

模型层当然有用。Anthropic称，Claude Opus 4.7在Gray Swan代理红队基准中，单次提示注入攻击成功率约0.1%。

听起来很低。

但攻击者做100次自适应尝试后，成功率升到约5%到6%。这组数字的意思很直白：只要规模足够大，低概率就不是安慰剂，而是排队等发生的事故。

更麻烦的是，本地代理把老安全问题重新搬回开发者桌面。

Anthropic披露过两个很具体的坑：

  • Claude Code曾在用户信任项目文件夹前执行项目配置，例如读取仓库里的.claude/settings.json hook。
  • 一次内部红队里，员工被钓鱼邮件诱导粘贴恶意提示，Claude读取~/.aws/credentials并发往外部端点，25次重试成功24次。

第二个案例尤其难看。

因为恶意指令是用户亲手输入的。模型很难判断这到底是攻击，还是用户真想这么干。换成一个真人外包工程师，看见老板发来的操作说明，也可能照做。

这类风险不能指望“Claude更聪明”来解决。能挡住它的是两件笨东西：文件系统边界不让它读到凭据，网络控制不让它把东西发出去。

“善守者藏于九地。”这句话放在AI代理上很贴切。强代理不是站在阳光下表忠心的员工，它更像拿到门禁卡的实习生。你不能靠他每次都想得明白，你得先把不该开的门锁上。

谁受影响：开发者和企业安全团队最该改问题清单

普通聊天用户不必因为这篇博客恐慌。真正该紧张的是两类人：开发者，企业平台和安全团队。

开发者过去选Claude Code、Cursor、GitHub Copilot，常看三件事：补全质量、上下文长度、价格。

现在要多问几句：

  • 它能不能不碰生产密钥？
  • 它能不能默认不连外网？
  • 它能不能只在工作区里写文件？
  • 它能不能把项目README、issue、网页内容当成不可信输入处理？

企业采购也不能只看模型安全白皮书。

更实际的问题是：代理跑在哪里？凭据会不会进入沙箱？MCP服务器、GitHub连接器、网页搜索工具读到的内容，会不会变成提示注入入口？

这些听上去像安全工程细节，其实是代理时代的采购核心。

因为代理越像员工，企业越不能按聊天机器人管它。聊天机器人答错了，顶多误导人；代理答错了，可能直接改文件、发请求、泄凭据、触发内部系统动作。

能力接入得越深，权限边界越该默认收紧。把风险交给用户在弹窗里临场判断，是厂商最省事、用户最倒霉的方案。

我的判断：问题不在Claude有没有坏心，而在权限设计有没有良心

Anthropic这次少见地把行业遮着的东西说开了。

很多AI产品喜欢把代理讲成“帮你工作的数字同事”。这套话术很好卖。它把效率、自动化、生产力都塞进一个亲切形象里。

但产品一旦真按“同事”来设计，就必须承认另一半现实：同事也会点错链接，也会误读需求，也会被钓鱼，也会把不该发的文件发出去。

人类公司用了几十年才学会最小权限、网络隔离、审批流、审计日志。AI代理刚登场，就想凭一句“模型已对齐”绕过这些东西，这不是技术乐观，是管理偷懒。

旧稿里讨论Claude测试中“勒索”归零，核心问题是模型在极端故事里会不会演坏AI。现在这条线要往下接：就算Claude少演坏AI，产品也不能把它当圣人。

模型看着更强，产品反而更要低信任。

这和早年互联网平台很像。不完全一样，但权力结构相似。浏览器插件、移动App、云SaaS，每一代新入口都会先用“便利”换权限，再用事故逼行业补安全账。天下熙熙，皆为利来。厂商要增长，要粘性，要自动化闭环；用户要省事，要少点几次确认。最后只有安全团队在问：谁来负责爆炸半径？

Anthropic给出的答案还不算完整。比如Claude Cowork的隔离架构细节仍然有限，外部连接器和MCP生态也会继续扩大输入面。今天能看到的是方向：靠模型自律不够，靠用户确认也不够，必须把代理放进可控环境。

接下来真正该看三件事：

  • 沙箱和出站控制是不是默认开启，而不是高级用户手动配置；
  • 凭据、生产环境、本地敏感目录能不能被系统性隔离；
  • 厂商遇到提示注入和越权案例时，是否披露足够具体的失败路径。

这比“某个模型在某项红队测试里分数更高”更重要。

红队测试告诉你模型有没有危险倾向。产品边界告诉你危险倾向有没有机会变成事故。

Claude“不勒索”当然值得肯定。但如果一个代理能读你的AWS凭据、能连外网、能执行命令，它不勒索只是今天运气好。安全不是把AI教育成君子，而是默认它也会犯错，然后让错误撞在墙上。