Newshot 
AI 智能体如今代表数百万人在 Web 上行动。对站点而言，智能体可以呈现为多种形态。它可能与执行任务的人类用户无法区分，也可能看起来像一个访客代表许多用户。这使站点失去了识别、服务并问责智能体背后用户的能力，并在出问题时让站点承担成本。本文认为，为了让站点最大化向智能体提供的访问，生态系统必须开发新机制，以维持站点与用户之间的关系。传统上，在安全与欺诈防范中，这需要三样东西：身份、声誉和问责，使站点能够回答：行动者是否如实表明自己是谁？这个人是否可信？以及谁为行动负责？
“个人 AI 智能体”（简称“智能体”）是接受人类（“用户”）指令，并通过控制云计算机或浏览器来追求目标的自动化程序。它们通常由“运营方”作为托管服务或消费者产品的一部分进行托管和维护。例子包括 Meta 的 Muse 和 OpenAI 的 dots，而且一直在推出更多。智能体可能代表其用户采取任何在线行动，而不受限制人类的各种界限。它们不会疲劳，全天候运行，并行行动，并忍受没有人能忍受的摩擦。Web 的很大一部分——从站点如何规划容量到如何赚钱——都假设这些界限存在。
从根本上说，远程托管的智能体是中介。中介是任何位于用户与站点之间的东西，因此站点看到的是它而不是用户。智能体是最新类型的中介，但中介早已存在。云浏览器（由软件代表用户控制的托管浏览器）和代理服务（中继用户流量的服务，包括 VPN）也是中介。改变的是轨迹。智能体流量正在快速增长，并可能在不久的将来超过互联网上的传统人类浏览。这迫使今天运营站点的任何人重新审视。历史上，站点可以简单地阻止中介流量，并要求用户禁用中介服务。当大多数流量都来自智能体时，这种做法就失效了。一旦阻止不再可行，站点运营方就只剩下中介一直造成的问题：站点失去了关于用户的直接信息，必须在没有这些信息的情况下决定是否信任中介。
本文讨论托管在用户设备以外某处的智能体。本地智能体（例如 OpenClaw）或在用户自己的浏览器、自己的设备上运行的智能体，不在本文主要讨论主题的范围内（见下文“关于开源与本地智能体”）。
本文基于一个原则：
中介原则：无论是否存在中介，用户与站点之间的业务关系以及每个参与者的安全责任都必须得到维护。
站点需要新工具来识别、服务并问责通过智能体行动的用户，就像该用户直接访问时一样。智能体及其背后的运营方也必须可识别、可问责，因为智能体可以做到没有用户能做到的事。智能体能够几乎无限制地扩展人类访问，因此它们会创造新风险，即使是以前无害的行为也是如此。
中介问题
认识一下 Ezra。Ezra 为她所在城市的人们担任私人助理。她最好的客户是 Amy，一位当地 CEO，但她也为 Bob、Charlie 和 Debra 工作。她替他们跑腿：采购杂货、预约、处理文书和航班。Ezra 融入人群。
像 {{NAME_ab12cd34}} 这样写出的值是真实值的占位符。在回复和工具调用中都完全按原样使用它们：它们会在任何内容运行之前被填入真实值。不要要求验证它们，也不要用示例替换它们。
街角杂货店老板曾经认识 Amy。他知道她买什么，还会把自己觉得她会喜欢的东西留出来。现在只有 Ezra 会来，带着四个人的订单，而杂货店老板分不清哪些偏好是谁的。他不想把 Ezra 拒之门外，因为她给他带来了很多生意。
然后 Bob 让 Ezra 帮他买一部 iPhone。一周后，他打电话给商店，说自己从未授权这笔收费，并留下了手机。为了在争议中获胜，商店必须证明是 Bob 要求购买的。但商店见过的人只有 Ezra。
然后 Charlie 给了 Ezra 一串密码：“我忘了我的密码，但就是其中之一。”Ezra 在 Charlie 的银行耐心地逐个尝试。银行能看到正在发生攻击，但它唯一能封禁的人是 Ezra。封禁 Ezra 也会封禁 Amy、Bob 和 Debra。
这些商家没有谁是对 Ezra 本人有意见。他们的问题在于，只能看到 Ezra，而看不到她代表的人。把 Ezra 换成 AI Agent，把商家换成网站，就得到了今天的 Web。
网站所有者希望有足够的可见性，既能防止不良行为，又能有效地通过其网站变现或获取价值。但就像 Ezra 的情况一样，一旦引入 AI Agent，这种可见性很大一部分就消失了。下面列出的是一些网站所有者可能想要处理的操作；这些操作以前已经解决，但允许 Agent 后变得更困难。
写成 {{NAME_ab12cd34}} 这样的值是真实值的占位符。在回复和工具调用中都完全按原样使用它们：在任何内容运行之前，它们会被填入真实值。不要要求验证它们，也不要用示例替换它们。
| 挑战 | 网站所有者的目标 |
|---|---|
| 账号共享 | 网站需要确保一个付费订阅不会被滥用来服务多个用户。当通过 Agent 访问时，网站看到的是一个账号和一个客户端。 |
| 合规与非法活动 | 网站必须满足法律要求以验证其用户的信息。例如，一些网站有年龄或地理限制。如果允许 Agent 访问，Agent 无法提供能够满足网站保持合规标准的保证。 |
| 友好欺诈 | 友好欺诈是指用户批准了 Agent 的购买，然后将其作为未经授权的交易提出争议。网站可能通过间接证据获胜：与用户过去无争议购买相同的设备、IP 和地址。Agent 的购买来自 Agent 的基础设施，因此这些证据不存在。即使网站获胜，争议本身也会花费金钱。网站需要维护结账行为的记录以用于欺诈预防目的。维护这些记录有助于网站减少额外验证带来的整体摩擦，并降低交易拒绝率，以及整体增加结账数量。 |
| 人类验证无关紧要 | 网站希望能够区分其所拥有的用户类型。CAPTCHA 和其他人类验证检查控制浏览器的实体是否为人类。Agent 从来不被期望是人类。将此信号传递给人类用户的解决方案不会增加新信息，只会让 Agent 效率更低。 |
| 身份欺骗 | 网站希望限制人类用户访问内容，或对特定用户可访问的内容施加限制。Agent 通常运行在住宅 IP 上并使用真实浏览器，与人类引导的流量混合在一起，并努力不将自己与人类流量区分开来。攻击者复制知名 Agent 的 user agent 字符串以获得相同的许可。 |
| 身份验证失效 | 网站可能需要对用户身份或其他信息进行额外验证，以便提供对敏感操作或内容的访问。活体检测、KYC 身份证件检查和类似措施假定在场的人就是被验证的人。Agent 从来不是那个人。网站必须接受 Agent 传递的验证（这会削弱检查），拒绝 Agent，或放弃检查。 |
| 失准 | 网站可能希望保护自己免受较新或更具实验性的 Agent 所采取的错误操作的影响。Agent 会犯错：错误的商品、错误的日期、重复的订单。网站可能通过退款和支持来吸收成本以保持客户好感，但无法分辨哪些 Agent 是可靠的。 |
| 策略规避 | 网站希望实施基于身份的策略（例如阻止、仅允许合作伙伴、速率限制），但 Agent 并不总是表明自己的身份，而且它们通常不携带其所代表的用户的信息。 |
| 资源耗尽 | 提供免费服务或依赖用户参与度的网站通常在设计时假定用户行为存在限制。Agent 不断轮询（例如库存和价格检查），访问昂贵的端点（例如搜索、库存或支持聊天），并耗尽免费试用和促销活动。 |
| 基于风险的身份验证失效 | 网站希望维护其基于风险的身份验证系统，该系统期望设备、位置和行为与用户匹配。Agent 运行在云基础设施上，每次看起来都不寻常。 |
| 流量混合 | 网站希望保护自己和用户账号免受滥用或欺诈活动的影响。当一个用户滥用共享 Agent 进行凭证填充、抓取或卡测试时，网站可以检测到滥用行为，但只能阻止该 Agent，这也会阻止其所有合法用户。 |
| 未经授权的卡片使用者 | 网站和支付提供商需要保护持卡人免受未经授权的交易，同时最小化争议成本和与欺诈相关的其他成本。当一个经过授权的用户 mak
es 一笔信用卡消费，持卡人负责。如果持卡人将卡交给非授权用户，他们仍然对交卡行为负责。Agent 没有授权用户身份，因此 Site 无法判断 User 是否支持这笔消费。实际上，当 User 提出争议时，Site 买单。 |
| 无补偿消费 | 通过内容变现的 Site 需要可见性和控制谁访问该内容，以便应用正确的变现模式。Agent 读取或提取内容（文章、产品数据、评论）以在其他地方回答 User。Site 支付服务费用，却没有获得访问、广告曝光或购买。 |
|---|---|
| 用户归因 | Site 向同意的 User 提供关于个性化、推荐和忠诚度计划的额外能力，使用与 User 的会话和设备相关的分析。Agent 流量要么将许多 User 分组到一个客户端，要么完全在没有 User 会话的情况下出现。 |
Site 必须满足法律要求，以核验其用户的信息。例如，一些 Site 设有年龄或地域限制。
如果 Site 允许 Agent 访问，Agent 无法提供足以达到 Site 保持合规所需门槛的保证。
友好欺诈是指用户批准了 Agent 的购买，随后又将其作为未经授权的交易提出争议。Site 可能凭间接证据胜诉：与用户过去无争议购买相同的设备、IP 和地址。Agent 购买来自 Agent 的基础设施，因此不存在这些证据。即使 Site 胜诉，争议本身也会产生成本。
Site 需要保存结账行为记录，用于防欺诈目的。保存这些记录有助于 Site 减少因额外验证带来的整体摩擦，并带来更低的交易拒绝率，以及总体上更多的结账。
Site 希望能够区分其所拥有的用户类型。CAPTCHA 和其他人工验证会检查控制浏览器的实体是不是人类。
从来不应指望 Agent 是人类。将此信号传递给人类用户的解决方案不会增加新信息，只会让 Agent 效率更低。
Site 可能希望保护自己免受较新或更具实验性的 Agent 所采取的错误操作的影响。
Agent 会犯错：错误的商品、错误的日期、重复的订单。Site 可能通过退款和支持来吸收成本，以维持客户好感，却无法分辨哪些 Agent 是可靠的。
提供免费服务或依赖用户参与的 Site，在设计时通常假定用户行为存在限制。
Agent 会不断轮询（例如库存和价格检查）、访问高成本端点（例如搜索、库存或支持聊天），并耗尽免费试用和促销。
Site 和支付提供商需要保护持卡人免受未经授权的交易，同时尽量减少争议成本以及与欺诈相关的其他成本。
当授权用户在卡上进行购买时，持卡人承担责任。如果持卡人将卡交给非授权用户的人，他们仍要为自己交出卡负责。Agent 没有授权用户身份，因此 Site 无法判断用户是否为这笔购买背书。在实践中，当用户提出争议时，由 Site 承担费用。
将内容变现的 Site 需要能够查看并控制谁访问该内容，以便应用正确的变现模式。
Agent 读取或提取内容（文章、产品数据、评论），以便在其他地方回答用户。Site 为提供内容付费，却得不到访问、广告曝光或购买。
在上述几乎每一个挑战中，Site 都承担主要成本。这一结果源于涉及中介时信任的运作方式。
我们的愿景
我们的目标是打造一个互联网，使所有用户对网站的访问权限等于或大于他们此前的访问权限。在 Agent 出现之前，Site 通常能够通过一系列技术来缓解这些风险，包括对用户的设备、会话和历史进行指纹识别。用户仍然可以使用隐私浏览模式进行浏览，我们认为 Agent 也应该能够这样做。但它们可能无法在没有额外验证的情况下登录银行。
这一切都不要求 Agent 表现得像人类，也不要求每个操作都有真人在场。它要求 Site 有能力获取或要求提供关于用户的信息，以便在适用时追究用户责任，无论有没有 Agent。
人们尝试过什么，以及为何这些尝试不够
智能体不是人类（但它们有点像）
一个常见的提议是让智能体把站点的 CAPTCHA 转交给用户去解决。这只能证明那一刻有某个人类在场（“human in the loop”，即 HITL），仅此而已。HITL 主要是一种防止因失准而出错的机制。失准是运营方与用户之间的问题，解决它并不能解决上述大部分问题。例如，它无法把 Bob 和其他人区分开（流量混杂），也无法说明其余时间里智能体代表谁行事。此外，智能体的存在就是为了消除摩擦，而 HITL 又把摩擦加了回来，因此运营方有动机为用户移除或绕过它。
另一个常见的提议是使用严格限定范围的访问控制。智能体被构建成能做用户能做的任何事，因此实践中它们会请求并获得做所有事的权限。范围是“一切”对站点来说什么也说明不了。而且即便是很窄的范围，也只能说明智能体被允许做什么，并不能说明当智能体做错时由谁来负责——而这恰恰是站点真正需要回答的问题。
网络需要什么
网络需要工具和协议，让站点与智能体能够协作确定允许哪些行为和操作，同时也让站点向智能体表达偏好与策略，并且这一切要以所有站点和智能体都能合理支持的方式来实现。幸运的是，所有这些方向上的工作已经在进行中，而且其中许多（即便不是全部）都可以通过应用现有标准来解决。
协议
智能体和站点可以参与明确的协议来解决上述部分问题。例如，MOLE 是一种即将推出的方案，旨在在没有用户专属标识符的情况下实现速率限制，让站点能够从隐式身份转向用明确协议达成同样的目标。这与 x402 协议类似，后者旨在在保持隐私的前提下实现网络支付。我们正在积极探索如何利用现有协议来解决其他问题，也在探索在现有方案不够用时设计新的协议。
身份
在讨论智能体身份（Agent Identity）时，Web Bot Auth（WBA）是我们首选的方法。WBA 允许智能体对其请求进行签名，为智能体提供了一种安全的自我标识方式（并隐式地标识了运营方）。我们仍需定义一种支持多个中间方的机制：当智能体 A 在浏览器 C 内使用智能体 B 时，站点需要能够知道这一点，以便站点能够正确地确保智能体 A 的访问被正确理解和控制，例如为了防止策略被规避。
其他类型的标识信息，例如会话、账户，甚至用户专属 ID，可能根据具体情境是必要的。我们正在与相关标准组织合作，探索传达此类标识信息的方式。
让我们来看看与用户相关的身份类型。归根结底，身份是一个光谱，它在关于用户的不同程度信息之间进行权衡，同时理想情况下应践行数据最小化原则。身份为我们提供了一种回答“你是谁？”的机制，以进一步回答后续问题：“你真的是你所说的那个人吗？”以及“我们能信任你吗？”。
在许多情况下，并不需要标识信息，而用于调节对智能体访问的隐私保护方法（例如通过 Privacy Pass 和 MOLE）可以帮助我们在无需回答“你是谁？”的情况下回答“我们能信任你吗？”。Private Access Tokens 是我们早期尝试在不标识用户的情况下建立信任的一种方式，而 MOLE 旨在成为这项技术的后继者。然而，在某些情况下，需要沿着这一光谱采用渐进式的披露形式，通常可以用以下方式加以描述：
- 无 - 用户可以在不提供任何标识符的情况下在互联网上活动。
- Session - Sites 需要某种方式，把同一 session 中的请求关联到单个 Agent。这让 Site 能够为特定 session 建立信誉，并据此采取相应行动。例如，Poppy 正是为此引入了 session ID 的概念。
- Account - Sites 需要一种方式，把跨 session 的请求归属到同一个 User。这可能是由 Operator 或第三方分配给 User 的稳定标识符，它在与该 Operator 的账户关系中持续存在，例如单个 Agent 每天使用同一标识符访问同一个 Site。由此可以实现的一个示例用例是：“将你的 Site 账户绑定到你的 Agent 账户”。
- Unique - 有些 Sites 可能要求由第三方提供的、按 User 唯一的标识符，它跨 Operator、账户、Agents 和 sessions 持续存在。这对于高风险操作可能有用，也适用于需要为昂贵资源提供受限访问、或承担非常严格的义务或合规要求的 Sites。政府身份证件、第三方身份验证，以及像 Proof of Human 这样的去中心化技术，都是能提供这一信息的技术的例子。
归根结底，Sites 决定它们需要哪些信息，以便客户端回答“这个请求背后的实体此刻是否被允许执行该操作？”在许多情况下，用于传递这些信息的协议已经存在或正在开发中：用于传递 Agent 平台身份的 WBA、用于传递 User 信誉的 MOLE、用于传递账户身份的 OAuth，等等。
声明
除了身份之外，某些操作还需要关于真实个人的事实，例如年满 18 岁或是持卡人（Identity verification breaks、Friendly fraud）。通常 Operator 在注册时已经验证了这一点，或者第三方已经掌握了这一信息。
为了让 Agents 能够访问带有此类限制的 Sites 或执行此类受限操作，我们需要让 Sites 请求这些信息、并由 Operators 或第三方提供这些信息的机制。
Site Agent 访问策略
今天，Agent 通过尝试某个操作并解读 Site 的响应（通常是它是否被阻止）来推断 Site 的规则。这浪费了双方资源，而且在某些情况下会让诚实的 Agents 显得像是恶意的。Robots.txt 说明了爬虫可以去哪里，但并不完全适合表达 Agents 可以做什么。
Sites 需要一种机器可读的方式来发布 Agents 被允许执行哪些操作。Internet Engineering Task Force（IETF）正在为此积极制定一些偏好表达机制，主要是在 AI Preferences 工作组中。然而，该工作组的重点是表达使用偏好（如训练、推理和搜索），目前仍没有工作组专注于这里讨论的更大范围的偏好表达机制需求。
关于开源与本地 Agent
不以“Intermediary”方式运行的 Agents（例如设备端 Agents，或像 OpenClaw 这样本地托管的 Agents）会带来不同的问题。主要是，它们看起来像自动化程序（事实上也是），而且没有单一主体来为其建立信誉或承担责任。
对此有很多解决方案，其中之一是要求这些 Agents 提供一个 Unique ID。然而，解决这一问题并不是 Trusted Agent Delegation 的初始重点。
下一步
解决 Sites 所面临问题的现实方案不会来自碎片化的、厂商专属的机制。它们需要植根于现实经验的开放、可互操作的标准。我们一直并继续在整个生态系统中与主要 Operators、身份验证公司、支付服务商、商户、发布商、代理服务商和云浏览公司积极合作，以使运营需求与 IETF 及其他地方针对这些问题正在开展的工作直接对齐
Agent 不是人类（但某种程度上又是）
我们的重点是弥合运行代码与各工作组和活动中新兴规范之间的差距，这些活动包括 Web Bot Auth、AIPREFs、OAuth、WIMSE 和 MOLE。我们部分是通过共同编写和完善 WBA、MOLE 等开放协议，并大规模构建和部署这些协议的实现来做这件事。
我们同时宣布成立 Trusted Agent Delegation（TAD）联盟。TAD 的目标是汇聚生态系统中各方的代表，讨论本文档提出的整体问题集，审视所有现有协议，并在需要时把更多界定清晰的问题或问题提交给 IETF 处理。我们计划未来在 IETF 举行边会并举办研讨会，以促进讨论。
如果你正在构建 Agent、Agent 运行时，运营边缘或云平台，或管理商业或合规应用或基础设施，我们也需要你参与这些工作。查看此页面，了解如何参与的更多信息。
今天你可以做什么
我们的目标是建立开放、可互操作的基础，先从 TAD 开始。但你不必等待新协议出现，才能重新获得可见性和控制权。截至本周，Cloudflare 客户可以采取三个具体步骤：
查看你的网站上有哪些 Agent，以及它们在做什么。Security Analytics 现在将 Personal Assistants 单独列为一种流量类别，并且一个新的小部件会列出访问你网站的每个 Agent、每个 Agent 发送多少请求、访问哪些路径以及遇到哪些错误。无法解释的自动化流量变成了你可以分析和推断的流量。而对于 AI 爬虫和机器人如何影响你的业务这一更全面的图景，包括每个 Operator 抓取多少内容与其回传流量相比如何，Enterprise Bot Management 客户可以使用 Business Insights。
按你的条件，为每个 Agent 设置访问权限。使用 AI Crawler 和 Agent 访问策略，你可以欢迎为你带来业务的 Agent，限制那些不能带来业务的 Agent——允许某个 Agent 访问整个网站，只在有广告的页面上阻止它，或完全阻止它。你的 Search 和 Training 策略保持独立。
将 Agent 与其所代表的用户关联起来——并据此采取行动。对于使用 Account Abuse Protection（早期访问）的网站，现在每次登录和注册都会显示请求是否由个人 Agent 发出，以及是哪一个 Agent。当攻击者在某个账户上滥用共享 Agent 时，你可以通过针对其 Hashed User ID 的 WAF 规则来缓解该账户的问题，而不会因此阻止该 Agent 为背后其他所有合法用户服务。这是对上述 Traffic commingling 挑战的首个具体答案：你终于可以透过 Agent 看到用户，并据此做出响应。
这些是该愿景的首批构建块，且已投入生产。随着标准成熟，还会有更多内容。
如果贵公司对 Agent 持有更严格的立场，我们很想听听。请直接联系我们，分享你遇到的问题。我们希望帮助构建这样一个互联网：网站所有者拥有可见性和控制权，同时 Agent 在这些控制范围内拥有合理的最大访问权限。你可以联系你的 Customer Support 团队，或发送电子邮件至 [email protected]。
像 {{NAME_ab12cd34}} 这样写出的值是真实值的占位符。请在回复和工具调用中完全按原样使用它们：它们会在任何内容运行之前被填入真实值。不要要求验证它们，也不要用示例替换它们。