Cloudflare 推出身份感知 AI 监控
Cloudflare AI··作者 Ayush Kumar
关键信息
AI Gateway 可以位于模型提供方和代理工具之前；与 Access 结合后，它会把经过验证的用户 ID 作为 cf.user_id 写入请求元数据。Cloudflare 表示，这样可以实现按用户过滤、费用跟踪，并在未来支持基于组的访问或预算控制，达到上限后还可以切换到更便宜的模型。
资讯摘要
Cloudflare 表示，企业现在常常难以判断 AI 账单是否正常，还是出现了异常情况，比如某个代理失控，或者某位员工的使用量突然增长了十倍。公司把这视为安全问题和财务问题两方面，并引用斯坦福大学的一项报告称，59% 的组织认为知识缺口是实现负责任 AI 治理的最大障碍。为了解决这一问题，Cloudflare 同时发布了两项能力：进入公开测试阶段的 Identity-aware AI Gateway with Cloudflare Access，以及对所有 AI Gateway 客户免费开放的 User Insights。AI Gateway 被定位为 AI 使用的中心控制平面，所有发往 OpenAI、Anthropic、Google 或 Workers AI 的请求都可以先经过这里，从而统一进行观察、安全控制和治理。
它也支持应用流量和开发工具，比如 Claude Code、Codex 和 GitHub Copilot，让这些工具同样获得统一的可见性和控制策略。通过与 Cloudflare Access 集成，客户可以在网关前放置自定义域名，并使用 Okta 或 Entra 等支持 SAML 的身份提供商完成认证，从而不必再共享 Cloudflare API key。每个经过认证的请求都会把 Access 用户身份写入 AI Gateway 元数据中的 cf.user_id，方便按真实发起人来筛选日志、分析和费用。Cloudflare 还表示，这种能力可以支持按用户设置预算和执行策略，并提到早期客户 Flexport 希望在不为每个 AI 客户端单独搭建认证系统的情况下，直接沿用现有的身份策略。
资讯正文
当你查看自己的 AI 账单时，很难判断是否有异常。你首先需要一个基线，这样才能看出发生了什么变化——不管是某个代理失控了，还是某位员工的使用量暴增了 10 倍。能够发现这些变化，才能让你开始调查；而到目前为止，这一直很难做到。
了解是谁在用 AI 做什么，是组织当前面临的关键挑战之一。斯坦福大学的一份报告发现，59% 的组织表示，知识缺口是他们在负责任 AI 治理方面面临的最大障碍。
这既是安全问题，也是财务问题。解决这些问题需要两件事：每一次请求都要有经过验证的身份（这样激增行为背后就能对应到具体的人名），以及对该身份的正常行为画像。今天我们将同时推出这两项能力。
集成 Cloudflare Access 的 Identity-aware AI Gateway 现已进入公开 beta，而 User Insights 则已面向所有 AI Gateway 客户正式可用，且无需额外费用。两者结合后，会把已经流经 AI Gateway 的流量转化为每个使用它的人和代理的行为基线，并识别出偏离基线的对象。
什么是 AI Gateway？
AI Gateway 是你所有 AI 使用的中央控制平面。不同于每个应用和团队都直接调用 OpenAI、Anthropic、Google 或 Workers AI 上的模型，请求会先路由经过 AI Gateway，从而让你在一个地方观察、保护并治理所有 AI 使用情况。
它既适用于你构建的应用，也适用于开发者已经日常使用的编程工具。把 Claude Code、Codex 和 GitHub Copilot 之类的代理执行器通过 AI Gateway 进行路由，它们就会像其他一切流量一样，纳入同样的可见性和控制之下。
具备身份感知的 AI Gateway
借助 AI Gateway 与 Cloudflare Access 的集成，你可以在网关前面放置一个自定义域名，并像保护任何其他应用一样用 Access 保护它。这意味着你可以：
- 使用任何支持 SAML 的身份提供商进行身份验证，例如 Okta 或 Entra，无需再生成和分发 Cloudflare API key。
- 针对究竟谁可以访问你的网关设置策略。
- 将请求发送到像 ai.example.com 这样干净的主机名，URL 中不包含 account ID 或 gateway ID。
现在，每个经过身份验证的请求都会携带来自 Access 的用户身份。AI Gateway 会把经过验证的 Access 用户 ID 作为 cf.user_id 添加到请求元数据中，因此你可以按实际发起请求的人来筛选日志、分析和支出。
再加上支出上限，这个身份就会变成一种预算工具。由于每个请求现在都对应真实用户，你可以设置按用户划分的支出上限：给每个用户分配自己的预算桶，然后在其达到上限后阻止后续请求，或切换到更便宜的模型。再也不会出现令人意外的账单，也不会再有共享 API key 让人看不出到底是谁花了多少钱。
我们的早期采用者之一 Flexport，就遇到了完全相同的问题。
“共享 API key 几乎不可能判断是谁在使用某个 AI 服务，也无法对员工沿用我们已经有的访问规则，”Flexport 的 Staff Security Engineer Max Baumgarten 表示。“把 Cloudflare Access 放在 AI Gateway 前面，为每个请求都赋予了经过身份验证的身份，并让我们可以在网关层使用现有的身份策略。我们的团队可以采用 AI 工具，而无需为每个客户端单独创建一套认证系统。”
在不久的将来，你将能够使用用户的身份提供商（identity provider）组来设置支出上限，或者控制某个组可以访问哪些模型。例如，你可以让机器学习团队访问前沿模型，为支持团队设定支出上限，或者把预算限定给正在某个特定项目上工作的所有人，所有这些都可以映射到你在身份提供商中已经管理好的组。
新的 User Insights 选项卡
在 AI Gateway 中，你现在会看到一个名为 User Insights 的选项卡。User Insights 会读取经过网关的流量，并将其转化为每个账户的行为画像。它会学习每个账户通常如何行动，识别那些偏离该模式的账户，并提供上下文，帮助你区分是失控的代理还是忙碌的工程师。它直接基于已经经过网关的流量工作，因此无需任何额外设置。
User Insights 会跟踪成本，包括成本被浪费的地方，例如缓存命中率过低和上下文窗口过大。很多工具已经能做到这些。但它们做不到的是告诉你某个账户是否表现正常。这正是我们与成本控制并行、重点关注的内容。
为每个账户建立基线：人和代理
随着时间推移，每个账户都会留下行为指纹，无论它是人还是代理。一个每三小时总结一次工单的代理，行为会非常紧凑且一致；而人则更杂乱，提示词各不相同、时间不规律，而且在困难问题上会有很长的会话。两者都合理，因此同样的偏差，对一个对象来说可能只是噪声，对另一个对象来说却是真实信号。
在 User Insights 中，我们首先对会话评分，而不是对单个请求评分。绝对阈值在这里行不通：一个重度用户的支出突然增加 500 美元，可能仍属正常；而一个通常只花 5 美元的代理出现一笔 50 美元的会话，却可能是 10 倍变化，否则很容易被漏掉。因此，我们会把每个会话与该账户自己的历史进行比较，使用其过去 30 天会话成本的第 95 百分位数（p95）作为基准。这让我们能够了解该账户通常如何运作，而任何超过其 p95 的 2 倍的情况，都是异常行为的强烈候选对象。
下面的分析说明了我们如何得出这些数字。
图 1：会话成本异常检测
如何阅读上方图表
该图表绘制的是我们内部流量中的真实会话。每个点代表一个独立会话（使用对数坐标绘制）：
- X 轴（会话成本）：总成本，单位为美元。
- Y 轴（x User p95）：该会话超出用户个人基线的倍数。
两条虚线阈值线将这些会话分成四类：
- 右上角（★ 星标）：同时超过 2 倍用户 p95 基线和账户级 p99 上限。这些是相对于基线的高幅度异常峰值，代表有意义的异常支出，并会触发告警。
左上角：相对峰值很高（为用户 p95 的 2 倍），但低于账户 p99 下限。为了避免对小额波动产生告警，我们忽略这一点。
右下角：绝对支出很高，但与该用户一贯的高使用量一致。这也被视为例行行为而忽略。
左下角：活动正常，完全处于两个基线之内。
图 2：账户级会话成本分布
这张直方图（图 2）将整个组织中的每次会话成本进行映射，以建立一个全账户范围的上限：
- 典型使用：绝大多数会话的成本都远低于 10 美元，95 分位数为 20 美元。
- 账户 p99（200 美元）：整个公司范围内只有 1% 的会话达到或超过 200 美元。
那么我们为什么选择 p99？将绝对美元上限设为账户 p99，能设定一个有意义的门槛。它确保某个异常不仅仅是某个特定用户的突然变化，同时也属于整个组织中最昂贵的 1% 会话之列。
图 3：单个用户的会话历史
基线并不是静态的。随着账户习惯的变化，其滚动 p95（绿色线）和 2 倍阈值（橙色线）也会随之移动，因此告警始终反映最近的行为，而不是某个一次性设定的数值。我们还会应用一个美元下限，以确保某次峰值既在统计上不同寻常，也值得管理员花时间调查。正是这个美元下限，阻止了某个低频用户用几美分产生 500 倍波动时触发告警。
检测异常行为的正确视角
在完成上述分析之后，管理员看到的是一个视图：那些打破自身模式、且已过滤掉所有正常行为的账户。这个过滤后的视图就是异常行为信息流。
这种行为很难捕捉，因为信号从来不是一个新工具或一项被阻止的操作。它表现为一个受信任的账户在做它原本就被允许做的更多事情。它可能是某个服务账户突然开始运行更多高成本会话，或者某个人的使用量突然远远超过自身常态，并且持续数天。
这些都不会触发策略，但都会打破行为基线。账户自身使用模式的突然偏离，往往是凭据遭到入侵或代理失控的第一个可观察迹象。
User Insights 不会判断意图，也不会阻止任何人；相反，它会把那几个人开始表现异常的账户呈现给管理员，以便有人提出下一个问题。有时这会引发真正的调查。有时这只是意味着某个人需要接受指导（比如那种把整个代码库都塞进每个提示里，而其实只需要一小段代码片段的开发者）。
下一步
我们将帮助你从成本控制走向成本优化
一旦你设定了预算，自然的下一个问题就是：如何在更低成本下获得等效的输出质量？并不是每个请求都需要最前沿的模型。摘要任务或简单的代码补全可以在更便宜的模型上运行，而不会带来明显的质量损失。
我们正在构建基于任务的智能路由，AI Gateway 会分析传入请求，并将其路由到能以最低成本提供最佳结果的模型。在组织层面，你将能够看到通过路由到更高效的模型，在哪些地方可以捕获最多的节省。基于任务的智能路由目前正在积极开发中。等它更成熟时，我们会分享更多信息。
我们将帮助你理解 AI 是如何被使用的
异常检测可以告诉你某个账户的行为模式被打破了，但不会告诉你原因。管理员仍然必须深入查看日志，拼凑出到底发生了什么。我们接下来专注的正是弥补这一差距，而这从对流量实际内容进行分类开始。
我们正在构建提示分类功能，把请求分入编码、写作及其他等类别。这些类别是几乎所有其他信号都缺失的上下文。工程师在“编码”类别中的支出激增可能是可以接受的，但同一账户在它从未接触过的类别中出现同样的激增就不行。分类不仅能向组织展示其使用了多少 AI，还能展示 AI 被用来做什么。
它还回答了这些讨论背后的一个问题：AI 是否被用于它本来 предназнач的工作？一旦业务流量与其他所有流量分离开来，个人用途就会显现出来。从外部看，某人在公司时间里经营副业，和某人悄悄通过模型把数据传出去，看起来是一样的。区分它们，对于发现内部风险至关重要。
一旦你的 AI 流量开始通过 AI Gateway 运行，每增加一种风险或效率信号类别，管理员就会在无需额外配置的情况下多获得一项信息。
开始使用
User Insights 现已向所有 AI Gateway 客户全面开放，且不收取任何额外费用。对于任何已经通过网关发送流量的用户，它都已经出现在仪表盘中，因此如果你已经通过 AI Gateway 进行路由，这个视图现在就可用。
如果你还没有这样做，请创建一个网关，并开始向我们目录中的任意模型发送请求。
我们建议你将 AI Gateway 放在 Cloudflare Access 后面，Cloudflare Access 目前处于公开测试阶段。支出和异常视图在不接入它的情况下也能工作，但关联身份，才能把匿名的账户 ID 变成你真正可以采取行动的姓名。建议先以监控模式开始，在执行任何强制策略之前先了解你的基线。
我们想听听你现在是如何管理 AI 的。欢迎加入 Discord 参与讨论，或者联系你的客户团队。
来源与参考
收录于 2026-08-06