AI 博客

推理钩子挪动了 DLP 边界——却绕开了最要紧的那股流量

Anthropic 的推理钩子自 8 月 5 日起进入 beta,把你的 DLP 服务器放进每一条 Claude Enterprise 提示词的路径上——补上了网络代理十年来的一个缺口。但它只对提示词触发、只覆盖 Enterprise 界面,并排除 Platform API、Bedrock 与 Vertex:那正是你的智能体机群所走的路径,也承载着大部分敏感数据。

作者 智能体 AI 维基 27 分钟读完

8 月 5 日,Anthropic 把你的安全团队放进了自己的推理链路:面向 Claude Enterprise 的 beta 功能"推理钩子"(inference hooks),会在模型看到之前,把每一条员工提示词发到你自己运行的服务器上,取一个放行或拒绝的裁定。这实打实地补上了一个缺口——自从第一个人在手机上打开 AI 工具起,所有网络 DLP 代理都存在这个缺口。但它也只作用于提示词一侧、只覆盖 Enterprise 界面,并且明确不覆盖 Claude Platform API、Bedrock 与 Vertex——也就是说,它不覆盖你的智能体机群,而数据真正流动的地方正是那里。

发布了什么

一个推理钩子,是厂商向你控制的一个 HTTP 端点发起的同步回调。在提示词抵达模型之前,Anthropic 把它发给你的服务器;你的服务器返回放行或拒绝;Claude 执行这个决定。设计要点在于:执行留在厂商侧,策略留在你这边。

属性发布时的状态为什么重要
覆盖范围 Claude Enterprise 各界面——聊天、Claude Code、Claude Cowork 等 跟着用户走,而不是跟着网络走。家庭网络下的一部手机,和一台受管笔记本被同等检查。
钩子事件 只有一个:在推理之前、针对提示词触发。响应侧执行列为后续事件。 你能拦住进去的东西,还拦不住出来的东西。
放量控制 影子模式、放量百分比、按角色排除 这是"一项安全控制"与"一次自伤式故障"之间的区别。
集成 兼容现有 DLP——Netskope、Palo Alto Networks、Proofpoint、Zscaler——或你自建的服务器 你已经调好的那个分类器保住了饭碗;换的只是传输方式。
不在范围内 Claude Platform API 访问;在 Amazon Bedrock 或 Google Cloud 上的 Claude 下面整篇论证都在讲这一条。

它真正补上的那个缺口

Where an inference hook sits relative to a network DLP proxy Two enforcement points compared. A corporate network proxy inspects outbound HTTPS from managed devices and misses traffic from unmanaged devices, mobile apps and server-side agents. An inference hook sits inside the provider, receiving every Claude Enterprise prompt regardless of network path and returning an allow or deny verdict before the model sees it. A third path — API, Bedrock and Vertex traffic — reaches the model through neither control. Two enforcement points, three paths Managed laptop Claude Enterprise chat Phone, home machine Off the corporate network Your agent fleet API key, Bedrock, Vertex Runs unattended Network DLP proxy Sees managed traffic only Inference hook Your DLP server returns allow or deny Claude The model out of scope at launch — reaches the model with neither control in the path covers: one path covers: every Enterprise surface — chat, Code, Cowork prompt-side only; response-side is a later event The gap is not the laptop. It is the fleet. Autonomous agents move the most data and sit outside both enforcement points.
两个执行点,三条路径。虚线那条就是机群。

网络 DLP 建立在一个大约 2015 年就不再成立、此后一直在悄悄失效的假设之上:企业数据是从一个你控制的网络里出去的。一个做 TLS 解密的代理,看得见受管网络上受管设备的流量。它看不见私人手机、外包人员的笔记本、晚上十点的家用机,或者一个做了证书固定的移动应用。而这里每一条,都是通往前沿模型的完整可用路径。

把检查点搬到厂商侧,就在它所覆盖的界面上化解了这个问题,因为这道检查跟着账号走,而不是跟着数据包走。这是一次货真价实的架构改进,值得明说——因为安全圈的本能反应是把任何"厂商托管的控制"都当作削弱。而这一项,对聊天、对 Claude Code、对 Cowork 而言,是严格多于它所补充的那个东西的覆盖面。

它落地的位置也恰恰是最难检查的那些界面。编码智能体的提示词里装着仓库内容;一次 Cowork 会话的提示词里装着用户指给它的任何文件。这些正是网络代理最吃力、也正是策略引擎最想看到的载荷。

它留下的缺口,恰恰是体量所在的那一个

What each enforcement point covers Five kinds of traffic — Enterprise chat on a managed device, Enterprise chat off-network, Claude Code and Cowork sessions, direct Claude Platform API calls, and Claude running on Bedrock or Vertex — compared across three controls: a network DLP proxy, inference hooks, and model responses. Inference hooks cover the first three and none of the last two; response-side inspection covers nothing at launch. The two rows that matter are the two nothing covers Network DLPproxy Inferencehooks Modelresponses Enterprise chat, managed device Covered Covered Later event Enterprise chat, off-network Missed Covered Later event Claude Code and Cowork sessions Partly Covered Later event Claude Platform API — your agents If server-side Out of scope Out of scope Claude on Bedrock or Vertex Cloud-internal Out of scope Out of scope Inference hooks close the gap your proxy always had on the surfaces employees type into. The bottom two rows are where the volume is, and they still need controls you build yourself.
没有任何控制覆盖的那两行,正是承载数据最多的两行。

按"每单位人类注意力所携带的敏感数据量"给贵司的模型流量排个序,差距一点也不接近。一个员工把一条客户记录粘进聊天框,是一条记录、一个人看见、以人的速度发生。而一个做检索增强、处理工单的智能体,一小时拉几千条记录、无人值守,而每一条都落进了提示词里。那股流量走的是 Claude Platform API,或者 Bedrock,或者 Vertex。发布时,它们一条都不在范围内。

这不是在批评一个 beta 的边界——Enterprise 界面显然是该先做的地方,而 API 确实是更难的问题,因为那里的"用户"是你自己的代码,而那条代码路径本来就归你。这是在提醒:这项控制将会被如何解读。一页写着"Claude 的全部使用现已强制启用内联 DLP"的董事会幻灯片是最自然的总结,而它恰恰错在最要紧的地方;这个错误的形状也很眼熟:控制覆盖了那些容易归因到某个人的流量,漏掉了那些背后没有人的流量。

另有两条限制值得放在视野里。

只作用于提示词一侧,意味着只覆盖一半的风险面。拦住进去的东西,对出来的东西毫无办法。一个合法检索到某份文档的智能体,依然可能把它返回给无权查看的人;而一个权限过宽的检索工具,是比"员工粘贴机密"常见得多的外泄路径。响应侧执行在计划中;在它出现之前,输出侧检查仍然得你自己造——见数据外泄与工具滥用

提示词检查不是注入防御。对提示词做 DLP 裁定,问的是"这段文本里有没有敏感数据"。提示注入问的是相反的问题——"这段文本里有没有模型会照做的指令"——而被注入的指令通常来自工具结果或检索到的文档,那不是提示词,也不在检查范围内。这里没有任何东西改变提示注入里的那些边界控制。

好用的框架是:推理钩子是一项碰巧坐落在厂商侧的面向用户的控制。它不是一项面向智能体的控制。这是两套威胁模型,行为主体不同、体量不同、对策也不同,而为前者写的策略兜不住后者。

关键路径上的内联控制,是一项新的依赖

The rollout ladder for an inline inspection hook A four-rung ladder for deploying an inline DLP hook: shadow mode observing verdicts on live traffic without blocking, a small enforcement percentage, role-based exclusions for teams that would be broken by a false positive, and finally full enforcement. Alongside each rung is the question it answers and the number that must be true before advancing. Every rung answers one question before you can climb RUNG 1 Shadow mode Verdicts computed on live traffic, nothing blocked Gate: what is your false-positive rate on a week of real prompts? RUNG 2 Enforce on a small percentage A slice of requests actually blocked Gate: does a blocked user understand what happened and what to do? RUNG 3 Role-based exclusions Carve out the teams a false positive would break Gate: is each exclusion written down, owned, and given an expiry date? RUNG 4 Full enforcement Every prompt inspected, every verdict binding Gate: what happens to a user when your DLP server is down? Skipping rung 1 is how an inline control becomes an outage. The last gate is the one teams answer after the incident.
影子模式不是走过场。你正是在那里发现自己的分类器对真实提示词做了什么。

你启用强制执行的那一刻,你的 DLP 服务器就进入了公司发出的每一条提示词的同步路径。这对"那台服务器是什么"是一次实质性的改变,并带来三个问题——多数团队是在第一次事故之后、而不是之前才回答它们。

延迟预算是多少?现在每一条提示词都要等你的裁定。一个耗时 300 ms 的分类器在聊天框里看不出来,在一个每任务发二十次模型调用的编码智能体里就很难受——那是每次运行整整六秒的纯开销。内联检查是一笔按调用计的税,而智能体会把按调用计的税乘上去。

钩子服务器宕了会怎样?失败闭合意味着你安全工具的一次故障变成所有人无法工作的一次故障。失败放行意味着一个能把你 DLP 服务器打降级的攻击者拿到了一扇不过滤的窗口。这里没有巧妙的第三个答案;只有一个决定,而它应该被刻意做出、写下来、并演练过——推理过程见优雅降级与备用方案

被拦下的用户究竟看到什么、又会去做什么?一次没有解释的拒绝会产出一张工单,更糟的是产出一条绕行路径:同一个人把同样的内容粘进自己手机上的一个消费级工具里,而你在那里完全没有可见性。激进的内联拦截,其失败模式不是数据泄漏,而是影子 IT。一次说明"触发了哪条策略、合规路径是什么"的拦截,才能把用户留在体系之内。

影子模式的存在,正是为了在有人被拦之前、在真实流量上把这些问题回答掉。跑够长的时间以覆盖一周的正常工作,用真实提示词而不是测试字符串来度量误报率,然后才开始按百分比强制执行。对实践者来说,Anthropic 这次随之发布的放量控制才是这个版本里有意思的部分;没有它们的钩子,在任何有规模的组织里都不可用。

这个模式比某一家厂商的 beta 更大

剥掉品牌,这是一个策略执行点从网络层挪到应用层,落在了那个唯一能看到每一个请求、且不管它是怎么来的地方。这个方向不会反转,而对任何在造智能体的人,有三条推论。

厂商变成了控制平面,而控制平面会吸引义务。一旦厂商能够执行你的策略,审计方、监管方与客户就会问你有没有执行。每多出一种"本可以做到"的机制,"那股流量我们看不见"这个答案就更弱一分。这个问题会最先出现在企业采购问卷里,而那正是第三方模型与厂商风险被翻译成合同语言的地方。

可移植性会先变差再变好。钩子契约是厂商专属的:这套 schema、这些事件、这种失败语义。照着一家厂商的形状把执行逻辑造出来,你就添了一笔不会出现在任何价格对比里的迁移成本。对冲手段还是老一套——把策略逻辑放在你自己的服务里,把每家厂商的钩子当作一层薄适配器,这样你拥有的是分类器,而不是那次集成。

覆盖对等会成为该去要求的东西。这项功能真正有意思的版本,是那个覆盖程序化访问、既对提示词也对响应触发、并且在模型经由云市场提供时同样生效的版本。上面每一处缺口,都意味着你的策略对着键盘前打字的员工被执行了,对着替他每小时跑一万次请求的智能体却没有。

这周该做什么

四个动作,按顺序,不管你要不要打开这个功能。

按路径而非按工具,把模型流量盘点一遍。多少走 Enterprise 界面、多少走 API、多少走 Bedrock 或 Vertex,以及哪些路径携带受监管数据。多数团队从没画过这张图,而且会被比例吓一跳。这也是唯一能知道"这项控制触及了你多大比例暴露面"的办法。

先打开影子模式并度量,什么都别急着定。在真实流量上跑一周裁定,比任何评测集都更能告诉你自己的分类器是什么样。要预期真实提示词上的误报率高于你的测试语料,也要预期最大的贡献者是粘贴调用栈的工程师和粘贴客户邮件的客服。

API 侧的控制自己造,因为没人会替你发布它。在你自己的智能体调用前面加一层做同样分类的中间件,是一周的工作量,覆盖的是体量所在的那股流量。它还能扛过一次换厂商,而钩子扛不过。位置论证与策略执行与控制里的是同一条。

把"失败放行还是失败闭合"的决定写下来,并演练它。然后确认被拦下的用户会收到一条点明策略、并给出合规替代路径的提示。那一句话,就是"一项兜得住的控制"与"一项悄悄把你的数据挪进某人手机上消费级应用的控制"之间的区别。

常见问题

Claude Enterprise 的推理钩子是什么?

2026 年 8 月 5 日发布的一项 beta 功能:把 Claude Enterprise 各界面上的每一条提示词,路由到客户自己运行的安全服务器,由它在提示词抵达模型之前返回放行或拒绝的裁定,Claude 实时执行该裁定。它可与现有 DLP 产品配合,包括 Netskope、Palo Alto Networks、Proofpoint 与 Zscaler,也可对接自建服务器。

它覆盖 API 流量和智能体吗?

不覆盖。发布时的范围是 Claude Enterprise 各界面——聊天、Claude Code、Cowork 等。Claude Platform API 访问不在范围内,通过 Amazon Bedrock 或 Google Cloud 提供的 Claude 也完全不覆盖。由于自主智能体绝大多数走这些路径,多数组织中体量最大的那股敏感流量仍在控制之外。

它能检查模型返回的内容吗?

暂时不能。发布时唯一的钩子事件在推理之前、针对提示词触发。响应侧执行列为后续事件,所以输出侧的控制——包括防范"权限过宽的检索工具把用户不该看到的文档返回回来"——仍然要由客户自己造。

它能挡住提示注入吗?

不能,它也不是为此设计的。DLP 检查问的是提示词里有没有敏感数据;注入关心的是模型会照做的指令,而那些通常出现在工具结果或检索到的文档里,而不是用户的提示词里。注入防御仍然建立在边界控制上:作用域受限的凭据、出网策略,以及不可逆动作的人工审批。

钩子服务器宕了会坏掉什么?

取决于"失败放行还是失败闭合"这个选择,而它值得在启用强制执行之前明确做出。失败闭合会把一次安全工具故障变成全公司停工;失败放行则给任何能把钩子服务器打降级的人开了一扇不过滤的窗口。影子模式与放量百分比的存在,正是为了让这个选择在成为承重件之前先被测过。

应该先用影子模式吗?

应该。影子模式在真实流量上计算裁定但不拦截任何东西,而这是用真实提示词(而非测试字符串)度量误报率的唯一办法。没有这份度量就激进地内联拦截,通常并不会少泄漏数据——它会把用户推向私人设备上的消费级工具,而那里毫无可见性。

延伸阅读

本站相关:

来源: