查看你的 AI 账单时，很难判断是否有异常。你首先需要一个基线，才能看清哪些发生了变化——无论是某个失控的智能体，还是某个员工的使用量暴涨了 10 倍。能够发现这些变化，你才能开始调查，而到目前为止，这些变化一直很难被察觉。
弄清楚谁在用 AI 做什么，是当前组织面临的关键挑战之一。斯坦福大学的一份报告发现，59% 的组织表示，知识缺口是它们实现负责任 AI 治理的最大障碍。
这既是财务问题，也是安全问题。解决这些问题需要两件事：每个请求上都有经过验证的身份（这样每一次使用量激增背后都能对应到一个具体的人），以及该身份“正常行为”的画像。今天我们同时宣布这两项功能。
集成 Cloudflare Access 的身份感知 AI Gateway 现已进入公开测试阶段，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 密钥。
- 设置策略，精确控制哪些人可以访问你的网关。
- 将请求发送到干净的主机名，例如 ai.example.com，URL 中不包含账户 ID 或网关 ID。
现在，每个经过身份验证的请求都会携带来自 Access 的用户身份。AI Gateway 会将经过验证的 Access 用户 ID 作为 cf.user_id 添加到请求元数据中，因此你可以按实际发起请求的人员来筛选日志、分析和支出。
结合支出限制，该身份就成了一种预算管理工具。由于每个请求现在都携带真实用户信息，你可以设置按用户的支出限制：为每个用户分配独立的预算额度，当额度用尽时阻止后续请求或回退到更便宜的模型。不再有意外账单，也不再因共享 API 密钥而无法追踪谁花了多少钱。
我们的早期采用者之一 Flexport 恰好遇到了这个问题。
“共享 API 密钥让我们几乎无法判断谁在使用 AI 服务，也无法应用我们已有的员工访问规则，”Flexport 的高级安全工程师 Max Baumgarten 表示。“将 Cloudflare Access 置于 AI Gateway 之前，为每个请求提供了经过身份验证的身份，让我们能够在网关层使用现有的身份策略。我们的团队可以采用 AI 工具，而无需为每个客户端单独创建一套身份验证系统。”
在不久的将来，你将能够使用用户的身份提供商组来设置支出限制，或控制某个组可以访问哪些模型。例如，让你的机器学习团队访问前沿模型，限制支持团队的支出，或为某个特定项目的所有参与者设定预算范围——所有这些都可以映射到你在身份提供商中已管理的组。
新的 User Insights 标签页
在 AI Gateway 中，你现在会看到一个名为 User Insights 的标签页。User Insights 会读取流经网关的流量，并将其转化为每个账户的行为画像。它会学习每个账户的正常行为模式，识别出偏离该模式的账户，并为你提供足够的上下文，以便区分恶意智能体与忙碌的工程师。它直接作用于已经流经网关的流量，因此无需任何额外配置。
User Insights 会跟踪成本，包括成本被浪费在哪些地方，例如缓存命中率低和上下文窗口过大。很多工具已经能做到这一点。但它们不会告诉你某个账户的行为是否正常。这正是我们选择关注的重点，同时兼顾成本控制。
为每个账户建立基线：人类与智能体
每个账户都会随着时间留下行为指纹，无论背后是人类还是智能体。一个每三小时汇总一次工单的智能体，其行为紧凑且一致。人类则更杂乱，提示词多变、时间不规律，遇到难题时会进行长时间会话。两者都是合理的，因此同样的偏差对一方可能是噪声，对另一方却是真正的信号。
在 User Insights 中，我们首先对会话进行评分，而不是对单个请求评分。绝对阈值在这里行不通：重度用户多花 500 美元可能很正常，而一个平时只花 5 美元的智能体出现 50 美元的会话，是 10 倍的变化，却可能被忽略。因此，我们将每个会话与该账户自身的历史记录进行比较，使用其过去 30 天内会话成本的 95 百分位（p95）作为基准。这样我们就能了解该账户的正常运作方式，任何超过其 p95 两倍以上的情况，都是异常行为的有力候选。
以下分析概述了我们如何得出这些数值。
图 1：会话成本异常检测
如何阅读上图
该图绘制了来自我们内部流量的真实会话。每个点代表一个单独的会话（以对数刻度绘制）：
- X 轴（会话成本）：以美元计的总成本。
- Y 轴（x 用户 p95）：会话超出用户个人基线的倍数。
两条虚线阈值线将会话划分为四个类别：
- 右上角（★ 星标）：同时超过 2 倍用户 p95 基线和账户级 p99 上限。这些是代表有意义异常支出的高相对峰值，将触发警报。
- 左上角：高相对峰值（2 倍用户 p95），但低于账户 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 之后，后者现已进入公开测试阶段。费用和异常视图在没有 Access 的情况下也能正常工作，但关联身份才能把匿名账户 ID 变成你可以真正采取行动的名称。建议先以监控模式运行，了解你的基线数据，然后再实施任何强制策略。
我们很想了解你目前是如何管理 AI 的。欢迎加入 Discord 上的讨论，或联系你的客户团队。