识别和防护 AI Agent 的滥用行为

作者：Reed McGinley-Stempel

AI Agent 已经不再只是索引你的内容。借助 OpenAI Operator、Anthropic Computer Use API 和 BrowserBase Open Operator 等工具，这些 Agent 能够浏览网页、模拟真实用户，甚至大规模执行操作。真正的挑战在于：如何判断它们是在改善用户体验，还是在为滥用行为打开方便之门？

在某些场景中，如果 Agent 能够改善易用性并提高产品采用率，应用或许会鼓励用户使用它；但在另一些场景中，它可能给应用开发者带来无法接受的风险，或被用来发起恶意攻击，例如凭证填充或批量创建虚假账户。

无论是哪种场景，可观测性都至关重要。应用必须知道访问自己网站的究竟是什么流量——这是人类、bot、善意 bot，还是恶意 bot？只有这样，才能明智地决定如何管理流量，并执行预期的使用规则。AI Agent 又让问题变得更加复杂，因为用户已经开始把自己的凭证交给 Operator 等工具。这意味着，即便一个 Agent 的初衷是好的，也可能给应用及其用户带来潜在风险。

关键问题是：如今，你能检测出应用中的 AI Agent 流量吗？

我们在多个高流量消费级网站上测试了多种 AI Agent 工具包，结果非常明确：传统检测技术——CAPTCHA、IP 封禁和 user-agent 过滤——基本都不起作用。以下是我们的发现。

bot 流量的新现实：AI Agent 流量是什么样的

传统上，bot 检测依赖 CAPTCHA、IP 封禁和 user-agent 过滤。但现代 AI Agent 从设计之初，就被打造得与真实用户十分相似：

真实的指纹：它们使用真实的 IP 地址和 user agent，甚至会模拟鼠标移动。

以人类速度进行无头浏览：它们的交互方式会模仿自然的浏览行为，从而避开限流机制的触发条件。

来自数据中心——但并非总是如此：有些 Agent（例如 OpenAI Operator）来自已知的 Azure 数据中心；另一些 Agent（例如 Anthropic API）则可以在本地运行，借用你机器的属性。

从表面上看，AI Agent 流量与普通人类用户的流量可能非常相似。下面是不同 AI Agent 的浏览器和网络属性示例：

Chrome on Linux（标准指纹）

Firefox on Ubuntu（较为稳定，在本地运行时除外）

Chrome on Mac（具有隐身功能）

已知的 Azure 数据中心 IP

情况不一——取决于是在本地还是云端部署

已知的 AWS 数据中心 IP

San Francisco, California

OpenAI Operator 和 BrowserBase Open Operator 都会启动远程数据中心或容器托管的 Chromium 实例，而不会在你的本地机器上安装任何软件。由于这些方案源自云托管环境，其 IP 地址及其他特征都与服务商的基础设施绑定，因此，如果服务商的 IP 地址范围广为人知，就更容易通过 ASN 查询等方法检测出来。

相比之下，截至目前，Anthropic 的 “Computer Use” 功能只能通过其 API 使用，而你可以自行选择如何运行这个 API，例如直接在自己的机器上运行，或是在 VM、容器中运行。如果在本地运行，它会继承本地系统的 IP、ASN 等属性；如果托管在云端，它就会使用相应云服务商提供的环境。不同方式会给指纹识别和检测带来不同影响。

目前，Anthropic 为使用其 Agent 提供了两种选择：

直接使用你的计算机环境（不推荐，因为不受限制的访问权限会带来安全隐患）。

搭建一台仅具有最低权限的虚拟机或容器来运行 API。你既可以在本地运行，也可以使用 Docker 将其部署到云服务商。部署到云端后，它就不会继承用户的网络属性。

Reddit 等限制更严格的网站会直接封禁 OpenAI 和 BrowserBase，而 Anthropic 的方案在本地运行时，甚至能成功绕过这些严格网站的限制：

借助 BrowserBase 等工具，如今也出现了一些用于构建浏览型 AI Agent 的开源方案，使潜在攻击者能够进一步提高无头浏览环境的隐蔽性。这意味着，我们应该预期某些 Agent 用例会继续快速迭代，并变得更难检测。例如，BrowserBase 提供了隐身能力更强的高级套餐，用于绕过 CAPTCHA 和其他检测技术：

如今，大多数网站都允许 Agent 流量自由访问。至于这些网站是否检测到了这类流量的异常，只是选择不采取行动，目前很难判断。对 Reddit 和 YouTube 等网站而言，它们对 OpenAI Operator 的封禁表明，其意图是限制 Agent 流量。当这些 AI Agent 绕过网站限制时——具体情况将在下文展开——这是一个很明确的信号：这些工具目前确实没有被网站察觉，而不是得到了网站的正式许可。

对于另一些允许此类流量的网站，它们可能确实是为了方便用户而鼓励这种做法；也可能在某些情况下存在反常的利益驱动，愿意放行一定数量的 bot 流量。Ticketmaster 就可能是一个例子，因为一定程度的 bot 活动能够提高门票购买率，进而让它从中受益。然而，还有更多网站只是缺乏识别这些 AI Agent 所需的流量情报，这也解释了它们为什么能够自由运行。

在一组高流量消费级网站上测试三种主要的 AI Agent 浏览工具包时，我们发现，只有 YouTube 和 Reddit 会持续封禁此类流量：

如今，很少有网站会封禁流行的 AI Agent，这意味着它们要么缺乏检测能力，要么对是否执行限制持无所谓的态度，也可能两者兼有。Reddit 和 YouTube 是少数几个重要的例外：只要能够识别出这类流量，它们就会将其封禁。

不过，各个 Agent 之间的差异依然很有意思。值得理解的是，为什么 Anthropic 或 BrowserBase 有时能够绕过那些原本会封禁此类流量的网站。以 BrowserBase 为例，它会在每个会话中生成略有不同的 user-agent。这个 user-agent 有时与底层 Chromium runtime 相符，有时又会通过声称自己是另一个版本来进行伪装，因此企业能否正确检测到它也更加不确定。

LinkedIn 和 X 等公司对网站上的数据抓取行为尤其敏感，因此它们没有采取限制措施着实令人意外。这表明，它们目前还无法确定这些流量是否来自程序。

如何区分 Agent 与人类

这里最显而易见的问题是：只通过 IP 或 user agent，不就应该很容易检测出来吗？

答案是：既是，也不是。对于 OpenAI Operator 来说，由于其特征稳定、来源固定，检测起来相当直接。但对 Anthropic、BrowserBase 以及正在进入市场的新 Agent 而言，情况就要复杂一些。

已知的 Azure 数据中心

取决于你如何运行它：

与 Operator 不同，你可以直接在自己的机器上本地运行它，也可以采用推荐方式，在 Docker 容器中运行。在这种情况下，它会继承你设备自身的 IP 和其他特征。

在生产环境中，你可能会将其托管在 AWS、Azure 等平台上，流量也会来自已知的数据中心。

提供自动解决选项

以下是一些值得了解的关键因素：

OpenAI 和 BrowserBase 都基于 Chromium 运行。要检测后者，能否区分 Chromium 浏览器与真正的 Chrome 至关重要，因为 BrowserBase 会修改 IP、user agent 等属性，以增强隐蔽性。

OpenAI 的流量来自一个已知的 Azure 数据中心，而 BrowserBase 的流量来自一个已知的 AWS 数据中心。

OpenAI 会把非隐形 CAPTCHA 交给最终用户完成，而 BrowserBase 则提供自动解决 CAPTCHA 的选项。

理想情况下，你应该采用比已知数据中心 IP 这类粗粒度标识更深入的方式检测此类流量，从而让检测能力能够充分抵御 Agent 流量未来可能做出的调整。实现这一点的核心，是能够高度确定与你的网站交互的浏览器，究竟是真实浏览器，还是无头自动化工具。

在这方面，我们发现 Machine Learning 非常有用，它可以帮助我们构建一个浏览器测谎仪。我们会分析范围非常广泛的浏览器信号，还下载了目前能够找到的每个浏览器版本的完整历史存档，并使用这些数据训练模型，让它了解真实浏览器与异常或具有欺骗性的浏览器分别是什么样的。

为了提供这种可见性，每当新的浏览器版本发布时，我们都会自动加入相应的合法浏览器特征。我们会对它进行指纹识别，并交给模型处理，为当前浏览器版本建立一组真实信号，从而检测出那些试图以非自然方式模拟该版本的人。有了这套经过指纹识别的数据集，就可以使用 Machine Learning 高精度地检测异常。正是通过收集这些信号，我们才得以发现 OpenAI 和 BrowserBase 使用的是完整的 Chromium build，而 Anthropic 的 Firefox 浏览器则未能模拟真实用户 Firefox 实例中本应存在的某些特征。

规划下一步路线

无论你选择封禁、限制还是利用 AI Agent 流量，有效的可观测性都不可或缺。以下是我们目前采用的行动方案：

主动监控：首先检测并监控 AI Agent 指纹。在实施强硬限制之前，先了解它们的行为。

接纳合理用例：一些用户可能会利用 AI Agent 简化工作流，例如自动生成 dashboard 中的报告。既要识别这些机会，也要防范滥用行为。

快速迭代：AI Agent 在不断演进，你的检测策略也必须随之发展。投资基于 ML 的解决方案，让它们能够适应 Agent 的新行为。

AI Agent 正在改写 Web 交互的规则。它们带来了令人兴奋的 UX 进步，同时也带来了新的安全挑战。这场竞赛已经开始：要么升级检测能力，要么面临被恶意攻击者和意外滥用甩在身后的风险。

如果你想进一步了解如何检测这些 Agent 并执行特定的行为规则，欢迎联系我们深入交流，也可以了解我们用于检测它们的指纹识别技术。

试用 Device Fingerprinting

99.99% 的 bot 检测率、智能限流与逆向工程防护。

Agent 体验时代

保护 AI 免受 bot 攻击

人工智能时代的应用安全：适应新的挑战与机遇

开始使用 Stytch

面向消费级应用

面向 B2B SaaS 应用

主动风险评估

细粒度规则执行

Stytch 与 Fingerprint 对比

© 2020-2026 Stytch。保留所有权利。