Cloudflare 探讨 AI 智能体带来的中间人挑战并推出可见性与访问控制功能

AI 代理（AI Agents）现在正为数百万用户在网络上代为行事。对于一个网站（Site）来说，代理可以呈现多种形态。它可能与执行任务的人类用户无法区分，也可能表现为一个访客承载了多名用户。这剥夺了网站识别、服务和追究代理背后一个或多个用户责任的能力，并导致网站在出现问题时独自承担代价。本文认为，为了让网站最大程度地向代理开放访问权限，生态系统必须开发新的机制来维护网站与用户之间的关系。在传统安全与欺诈防范中，这通常需要三要素：身份（Identity）、声誉（Reputation）和问责制（Accountability），从而让网站能够回答：行动者的真实身份是否属实？此人是否值得信赖？以及谁来为该行为负责？

“个人 AI 代理”（简称“代理”）是指接受人类（“用户”）指令并通过控制云端计算机或浏览器来追求目标的自动化程序。它们通常由“运营商”（“Operator”）托管和维护，作为托管服务或消费级产品的一部分。例如 Meta 的 Muse 和 OpenAI 的 dots，而且此类产品仍在不断推出。代理有可能在网上执行其用户能够进行的任何操作，且不受制约人类的限制。它们不知疲倦、全天候运行、并行运作，并能忍受任何人类无法容忍的阻碍。互联网的大部分内容，从网站规划容量的方式到它们赚钱的方式，都建立在这些限制之上。

从根本上说，远程托管的代理就是中介。中介是指位于用户和网站之间的任何事物，因此网站看到的是中介而不是用户。代理是最新的一种中介，但中介已经存在很长时间了。云浏览器（代表用户由软件控制的托管浏览器）和代理服务器（中继用户流量的服务，包括 VPN）也属于中介。改变的是发展轨迹。代理流量正在迅速增长，并可能在不久的将来超越互联网上传统的 ngunit 人类浏览。这迫使所有运营网站的人必须正视这一问题。过去，网站可以简单地拦截中介流量并要求用户禁用中介服务。当大多数流量都是代理流量时，这种方法就行不通了。一旦拦截不再可行，网站运营商就得面对中介历来带来的问题。网站会失去关于用户的直接信息，并且必须在没有这些信息的情况下决定是否信任该中介。

本文探讨的是托管在用户设备之外的代理。本地代理（例如 OpenClaw）或在用户自己的设备、自己的浏览器中运行的代理，不在本文探讨的核心主题范围之内（见下文“关于开源与本地代理”）。

本文基于一个原则：

中介原则：无论是否存在中介，用户与网站之间的业务关系以及每个参与者的安全责任都必须得到维护。

正如用户直接访问时一样，网站需要新的工具来识别、服务和追究通过代理行事的用户。代理及其背后的运营商也必须具备可识别性和可问责性，因为代理能够做出人类无法做到的事情。代理能够近乎无限制地扩大人类的访问规模，因此它们带来了新的风险，即使是对以前属于良性的行为也是如此。

中间人问题

认识 Ezra。Ezra 在她所在的城市为人们担任私人助理。她的最大客户是当地的首席执行官 Amy，但她同时也为 Bob、Charlie 和 Debra 工作。她为他们跑腿：买杂货、预约、处理文书工作和预订航班。Ezra 融入了人群中。

街角的杂货商以前认识 Amy。他知道她买什么，并把她可能喜欢的东西留给。现在只有 Ezra 一个人进来，带着四个人的订单，杂货商分不清谁的偏好是谁的。他不想把 Ezra 赶走，因为她给他带来了很多生意。

接着，Bob 让 Ezra 帮他买一部 iPhone。一周后，他打电话给商店，称自己从未授权这笔费用，并把手机留下了。为了赢得这起纠纷，商店必须证明是 Bob 要求购买的。但商店见过的唯一一个人却是 Ezra。

然后，Charlie 给 Ezra 了一份密码清单：“我忘了我的密码，但应该是这几个之一。”Ezra 耐心地在 Charlie 的银行尝试每一个密码。银行能看出攻击正在发生，但它能封禁的唯一一个人却是 Ezra。封禁 Ezra 同时也封禁了 Amy、Bob 和 Debra。

这些企业主中没有人对 Ezra 本人有意见。他们的问题在于，他们只能看到 Ezra，而看不到她所代表的人。如果把 Ezra 换成 AI 智能体（AI Agent），把这些企业换成网站，这就是今天的互联网。

网站所有者希望获得足够的可见性，既能防止不良行为，又能有效地从其网站中实现变现或获取价值。但正如 Ezra 的例子一样，随着 AI 智能体的出现，许多这样的可见性消失了。以下是网站所有者可能希望解决的一系列操作，这些操作以前已得到解决，但在允许智能体介入后变得更具挑战性。

在几乎上述的每一个挑战中，网站都要承担主要的成本。这一结果源于涉及中间人时信任机制的运作方式。

我们的愿景

我们的目标是打造这样一个互联网：所有用户对网站的访问权限等于或大于以往。在智能体出现之前，网站通常能够通过一系列技术来缓解这些风险，包括对用户的设备、会话和历史记录进行数字指纹识别。用户仍然可以使用无痕浏览模式进行浏览，我们认为智能体也应该能够做到这一点。但在没有额外验证的情况下，它们可能无法登录银行。

所有这一切并不要求智能体表现得像人类，也不要求人类在每次操作时都在场。它要求网站拥有相应的方法来获取或要求获取有关用户的信息，以便在适用的情况下追究其责任，无论是否有智能体参与。

人们尝试过的方法及其局限性

一个常见的提议是让智能体将网站的验证码（CAPTCHA）传给用户来解决。这只能证明某个时刻有某个人在场（即“人在回路”或 HITL），仅此而已。HITL 主要是一种用于防止因目标不对齐而导致错误的机制。目标不对齐是运营商与用户之间的问题，解决它并不能解决上述的大多数问题。例如，它无法将 Bob 与其他人区分开（流量混杂），并且它也没有说明智能体在其余时间代表谁行事。此外，智能体存在的意义就是消除摩擦，而 HITL 重新引入了这种摩擦，因此运营商有动力为用户移除或绕过它。

另一个常见的提议是使用严格限定范围的访问控制。Agent 的构建初衷是代用户做任何事，因此在实际操作中，它们会请求并获得做所有事的权限。"所有"的范围对网站来说毫无意义。即使是一个狭窄的范围，也只能说明 Agent 被允许做什么。它并没有回答当 Agent 搞砸时由谁来承担责任，而这正是网站真正需要得到解答的问题。

网络需要什么

网络需要各种工具和协议，让网站和 Agent 能够协作以确定允许哪些行为和操作，并向 Agent 表达网站的偏好和策略，同时所有这些都必须以所有网站和 Agent 都能合理支持的方式进行。幸运的是，在所有这些方面都已经有相关工作在推进，其中许多（如果不是全部的话）问题都可以通过应用现有标准来解决。

协议

Agent 和网站可以参与显式协议来解决上述某些问题。例如，MOLE 是一种即将推出的方法，旨在实现不需要用户特定标识符的速率限制，使网站能够从隐式身份过渡到使用显式协议来实现相同的目标。这类似于 x402 protocol，后者旨在实现网络支付，同时保持隐私保护。我们正在积极探索如何利用现有协议来解决其他问题，并在现有解决方案不足时探索设计新协议。

身份

在讨论 Agent 身份时，Web Bot Auth (WBA) 是我们首选的方法。WBA 允许 Agent 对其请求进行签名，这为 Agent 识别自身（以及隐式地识别运营商）提供了一种安全的方式。我们仍然必须定义一个支持多个中间件的机制：当 Agent A 在浏览器 C 中使用 Agent B 时，网站需要能够知道这一点，以便网站能够正确确保对 Agent A 访问的正确理解和控制，例如，为了防止 策略规避。

根据上下文的不同，可能还需要其他类型的识别信息，例如会话、账户甚至用户特定的 ID。我们正与相关标准合作，探索传此类识别信息的途径。

让我们来看看关于用户的身份类型。归根结底，身份是一个光谱，它权衡了关于用户的不同程度的信息，同时理想情况下遵循数据最小化原则。身份为我们提供了一种机制，在回答“你是谁？”的同时，进而回答后续问题：“你是你所说的那个人吗？”以及“我们可以信任你吗？”.

在许多情况下，并不需要识别信息，诸如通过 Privacy Pass 和 MOLE 等用于调节对 Agent 访问的隐私保护方法，可以帮助我们在无需回答“你是谁？”的情况下回答“我们可以信任你？”。Private Access Tokens 是我们早期尝试在不识别用户的情况下建立信任的一种方式，而 MOLE 旨在成为该技术的后继者。然而，在某些情况下，沿此光谱需要分阶段披露的形式，你通常可以将其归纳为以下几种方式：

无 - 用户可以在互联网上行动，而不带入任何标识符。
会话 - 网站需要某种方式将同一会话中的请求关联到单一代理（Agent）。这允许网站为特定会话建立信誉并做出相应的反应。例如，Poppy 正是为了这个目的而引入了会话 ID 的概念。
账号 - 网站需要一种跨会话将请求归属到同一用户的方法。这可能是由运营商或第三方分配给用户的稳定标识符，该标识符在运营商的账号中保持持久，例如单个代理每天使用相同的标识符访问同一网站。这可以支持的一个使用示例是：“将您的网站账号绑定到您的代理账号”。
唯一性 - 某些网站可能需要由第三方提供的、每个用户独一无二的标识符，该标识符在跨运营商、账号、代理和会话时保持不变。这对于高风险操作，或者对于需要提供对昂贵资源的受限访问、或具有非常严格的义务或合规要求的网站可能很有用。政府身份证、第三方身份验证以及像 Proof of Human 这样的去中心化技术，都是能够提供此功能的技术的例子。

归根结底，网站决定了它们需要客户端提供什么信息来回答“此请求背后的实体是否被允许在此时执行此操作？”在许多情况下，用于传递此信息的协议已经存在或正在开发中：用于传递代理平台身份的 WBA、用于传递用户信誉的 MOLE、用于传递账号身份的 OAuth 等等。

声明

除了身份之外，某些操作需要关于真实个人的事实，例如年满 18 岁或身为持卡人（身份验证中断、友好欺诈）。通常，运营商在注册时会对此进行验证，或者第三方已经拥有此信息。

为了允许代理访问具有此类限制的网站或操作，我们需要相应的机制，让网站能够请求此信息，并让运营商或第三方提供此信息。

网站代理访问策略

如今，代理通过尝试某项操作并解释网站的响应（通常是看它是否被阻止）来推断网站的规则。这浪费了双方的资源，在某些情况下还会让诚实的代理显得具有恶意。Robots.txt 指出了爬虫可以去哪里，但并不完全适合表达代理可以做什么。

网站需要一种机器可读的方式来发布允许代理执行哪些操作。互联网工程任务组（IETF）正在积极研究这方面的一些偏好表达机制，主要是在 AI Preferences Working Group 中。然而，该小组的重点是表达使用偏好（例如训练、推理和搜索），目前仍然没有一个小组专门关注这里讨论的更大规模的偏好表达机制需求。

关于开源和本地代理

不作为“中介”运行的代理（例如设备端代理，或本地托管的代理，如 OpenClaw）引发了不同的担忧。主要在于，它们看起来像（并且确实是）自动化，而且它们没有单一的方来建立信誉或承担责任。

对此有很多解决方案，其中之一就是要求这些代理提供唯一 ID。然而，解决这个问题并不是“受信任的代理委派”（Trusted Agent Delegation）最初的重点。

下一步计划

网站所面临问题的真实解决方案，不可能从碎片化的、特定供应商的机制中诞生。它们需要扎根于真实世界经验的、开放且可互操作的标准。我们过去一直在、并且将继续与整个生态系统积极合作，包括主要的运营商、身份验证公司、支付服务商、商家、发布商、代理服务商以及云浏览器公司，以将运营需求与 IETF 及其他地方针对这些问题的实际工作直接对接

我们的重点是在各个工作组以及 Web Bot Auth、AIPREFs、OAuth、WIMSE 和 MOLE 等活动之间，弥合运行中的代码与新兴规范之间的鸿沟。我们正在通过以下部分工作来实现这一点：共同编写和完善 WBA 和 MOLE 等开放协议，并大规模构建和部署这些协议的实现。

我们同时宣布成立 Trusted Agent Delegation (TAD) 联盟。TAD 的目标是将生态系统中的代表汇聚在一起，就本文提出的整个问题集进行讨论，检查所有现有协议，然后在必要时将定义更明确的问题或议题提交给 IETF 解决。我们计划未来在 IETF 举行周边会议和研讨会，以促进讨论。

如果您正在构建代理、代理运行时，运营边缘或云平台，或者管理商业或合规应用及基础设施，我们也需要您参与到这些工作中来。查看此页面以获取有关如何参与的更多信息。

您今天可以做些什么

一个开放且可互操作的基础正是我们前进的方向，将从 TAD 开始。但您不必等待新协议来开始重新获得可见性和控制权。从本周开始，Cloudflare 客户可以采取三个具体步骤：

查看哪些代理正在访问您的网站以及它们在做什么。安全分析 (Security Analytics) 现在将个人助理作为独立的流量类别进行细分，一个新的小部件列出了访问您网站的每个代理、每个代理发送的请求数量、它访问的路径以及它遇到的错误。无法解释的自动化流量变成了您可以进行推理的流量。对于 AI 爬虫和机器人如何影响您的业务的更广泛画面——包括每个运营商的爬取量与其回传流量的对比，企业级机器人管理 (Enterprise Bot Management) 客户可以使用商业洞察 (Business Insights)。

按您的条件、针对每个代理设置访问权限。通过使用 AI 爬虫和代理访问策略，您可以欢迎为您带来业务的代理，并限制那些不带来业务的代理——允许某个代理访问您的网站、仅在包含广告的页面上阻止它，或者完全阻止它。您的搜索和训练策略保持独立。

将 Agent 与其所服务的用户进行关联，并采取行动。对于使用 Account Abuse Protection（抢先体验）的网站，现在的每次登录和注册都会显示该请求是否由个人 Agent 发起，以及具体是哪个 Agent。当攻击者滥用某个账户上的共享 Agent 时，您可以通过针对其哈希用户 ID (Hashed User ID) 的 WAF 规则来缓解该账户的问题，而无需阻止其背后的其他所有合法用户所使用的 Agent。这是对上述流量混合 (Traffic commingling) 挑战的第一个具体解决方案：您终于可以透过 Agent 看到用户，并做出相应的响应。

这些是该愿景的第一批构建模块，目前已投入生产。随着标准的成熟，还将推出更多内容。

如果您的公司对 Agent 持有更具限制性的立场，我们非常希望能听到您的意见。请与我们联系并直接分享您的问题。我们致力于帮助构建这样一个互联网：网站所有者拥有可见性和控制权，同时 Agent 在这些控制范围内也能获得合理的最高访问权限。您可以联系您的客户支持团队，或发送电子邮件至 crawlercontrols@cloudflare.com 与我们联系。