Anthropic 在 Claude 里装了一道安全闸，Proofpoint、Check Point 等安全厂商火速接上

8 月 5 日，Anthropic 为 Claude Enterprise 上线了 Inference Hooks（beta），一个开放协议：企业在每一条 prompt 和每一次工具调用到达模型之前，先经过自有安全服务器的 allow-or-deny 实时裁决。不需要代理，不需要 TLS 拦截，不需要在员工设备上装任何东西。

被拒绝的请求永远不会进入模型。用户会看到是哪条策略拦住了自己。

Proofpoint、Check Point、Cyera：安全厂商排队接入了同一个 webhook

协议公开当天，Proofpoint 就发布了集成，将已有的 DLP 策略直接延展到 Claude prompt 上。博文指出：同一套防止敏感数据通过邮件、终端和云端外泄的策略，现在可以作用于发给 AI 模型的内容。

Check Point 的集成在次日完成。Check Point 团队在 8 月 10 日的中说明：复制租户的 hook endpoint URL 到 Claude Enterprise 设置，粘贴签名密钥，五分钟内完成对接。"We built our integration against the protocol the next day," 博文写道。

Cyera Agent Guardian 在 8 月 6 日接入，Reco 在 8 月 7 日，Akto 自己在 Anthropic 公告后 24 小时内完成了支持。Cato Networks 在 8 月 6 日已支持。Anthropic 的官方中还列出了 Netskope、Palo Alto Networks 和 Zscaler 作为可直接指向的 DLP 目标。

Bandwidth 信息安全副总裁 Andrew Grimmett 在 Anthropic 公告中给出了企业侧的评价：「Inference hooks 增加了一个检查点，在模型看到任何内容之前实时检查流向 Claude 的东西。这让我们可以在不放弃控制权的前提下，更快地推进 AI。」

近九成企业已把 AI 助手推过试点，42% 出过事

Proofpoint 在 2026 年 AI 与 Human Risk 报告中指出，近九成全球组织已将 AI 助手推过试点阶段，而 42% 已经遭遇过可疑或已确认的 AI 相关安全事件。问题不是 AI 太危险以至于不能采用——采用已经发生了。问题是控制手段有没有跟上。

在此之前，企业如果想在 prompt 到达模型之前拦截它，选择极为有限。Web 网关和 DLP 工具是为网站和 SaaS 应用设计的，不是为与 AI 模型的对话设计的。唯一的原生方案是 Claude Code 的客户端 hooks，跑在用户本机上，覆盖不了 chat 和 Cowork。把安全决策塞进 AI 助手的路径里，意味着要拥有这条路：正向代理、TLS 拦截、每台笔记本上的 agent。每一样都是一个部署项目，每一样都有地方会断。

Anthropic 的 Compliance API（5 月推出）提供事后审计能力，能看见对话里触碰了哪些敏感数据。但它拦不住：数据在被发现之前，已经过了模型。

没有代理，不截 TLS，一个 webhook 覆盖所有 Claude 入口

Inference hooks 把检查点放在了 Anthropic 自己的基础设施里，夹在请求离开客户端之后、推理启动之前。一个组织级配置，同时覆盖 claude.ai 聊天、Claude Code（web、桌面、CLI）、Claude Cowork，以及通过 MCP 连接器、skills 和插件触发的工具调用。

机制很简单：用户提交 prompt → Anthropic 通过签名 HTTPS 连接把对话文本发给企业指定的安全服务器 → 服务器在可配置的超时内（默认 5 秒）返回 allow 或 deny → allow 则推理继续，deny 则请求止步，用户看到拦截原因。工具调用也走同样的流程：Claude 调用工具后，工具的返回内容在送回模型前先过一次检查。

协议是 webhook 架构，schema 公开，请求按 Standard Webhooks 规范签名。判决是二元的——允许或拒绝，不支持改写或遮蔽 prompt。安全服务器收到的内容是对话文本、工具调用及其结果、附件中提取的文字，不会收到原始文件字节、图片、系统 prompt 或 Anthropic 内部上下文。

上线节奏可控：影子模式（shadow mode）只观察不拦截，可按百分比逐步放量，可按角色排除特定团队。故障处理由企业自选：安全服务器不可达时，要么拦掉所有请求（fail closed），要么放行（fail open）。持续故障会触发断路器，自动停止 enforcement 并通知管理员。

当前的限制同样清楚：仅覆盖 prompt 侧（响应侧的 enforcement 已列入后续计划），不支持语音模式，不检查纯图片内容。判决不可改写。仅限 Claude Enterprise 组织，API 访问（Claude Platform）、Amazon Bedrock 和 Google Cloud 部署不在范围内。Anthropic 的逐条写明了这些边界。

与 Compliance API 的关系不是替代，是互补：Inference hooks 在模型运行前拦住违规 prompt，Compliance API 在事后提供审计和导出能力。Proofpoint 的博文把这对组合概括为「预防与检测，同一个包裹的两半」。

AI 厂商第一次把「不」的权利交到了客户手里

此前的 AI 安全格局，安全厂商是在追着 AI 流量跑。网络层控制能看到穿过线路的内容，但面对加密、分散的 AI 流量越来越吃力。Check Point 此前选择的路是把 AI prompt 检查嵌入防火墙，在网络层拦截模型流量——这是在报道中描述的"镜像式方案"。Inference hooks 走了相反的方向：不是安全厂商去抓 AI 流量，而是 AI 厂商主动调用安全厂商的判决 API。

这个反转改变了部署模型。旧路径下，每增加一个 AI 入口，安全团队就要部署一套新的拦截方案。Inference hooks 的架构是：企业把 hook 指向已有的 DLP 服务器——就是邮件、终端和云端已经在用的那一台——一条规则覆盖所有 Claude 入口。Proofpoint 的博文强调，不需要新控制台，不需要新策略语言，不需要单独建一套 AI 安全技术栈。

但这也意味着覆盖范围的边界由 Anthropic 划定。Inference hooks 只管 Claude Enterprise 的入口；企业在 Bedrock 或 Google Cloud 上跑的 Claude 实例不受这套机制约束。网络层方案则相反，看不见 Claude 内部的文本，但能覆盖所有模型的流量。

Anthropic 这一步改变了行业里长期存在的分工。此前，安全控制要么跑在网络层（防火墙、代理），要么跑在客户端（Claude Code hooks），AI 平台本身的推理管线里没有一个让客户安放自己策略的原生位置。Check Point 的博文将此举定性为一个信号：「AI 厂商正在把安全直接嵌入平台。安全团队从被动监控转向主动治理的那一天，已经可以落地。」

控制点从网络层移到了模型门口

Inference hooks 不是又一个 API。它意味着 AI 厂商承认了一件事：客户有权在自己的基础设施里，对每一句即将进入模型的话说不。这不是安全厂商在模型外面加的一层壳，而是模型厂商自己在推理管线里留出的一个位置——谁坐在这个位置上，谁就决定了 AI 能看到什么、不能看到什么。