Cloudflare 宣布成立 Trusted Agent Delegation 联盟，并上线个人智能体流量可见性与访问策略

Cloudflare 于 2026 年 11 月 5 日在官方博客宣布成立 Trusted Agent Delegation（TAD）联盟，计划把「远程托管个人智能体作为中介」带来的身份、声誉与问责问题带到 IETF 等标准组织讨论；此前一天的 11 月 4 日，Cloudflare 已上线面向站点侧的个人智能体流量分析与逐智能体访问策略。TAD 是标准化倡议，不是已发布协议；站点侧能力官方称已在生产环境可用，其中账号滥用防护仍处早期访问阶段。

这次发布的是什么

Cloudflare 于 2026 年 11 月 5 日在官方博客发布《Agents aren't humans (but they kinda are)》，宣布成立 Trusted Agent Delegation（TAD）联盟。按公告原话，联盟的目标是把一批生态方聚起来，梳理本文提出的问题集、检视现有协议，再把定义得更清楚的问题带到 IETF 讨论；官方计划未来在 IETF 办边会与研讨会。同一篇公告还提出「中介原则」：用户与站点之间的业务关系、以及各方的安全责任，不应因为中间多了一个智能体而改变。

此前一天，即 2026 年 11 月 4 日，Cloudflare 已发布配套公告《See the agents, set the terms: new visibility and control for personal agents》，上线站点侧的可操作能力：在安全分析里单列个人智能体流量、按单个智能体设访问策略、在账号滥用防护里看到每次登录注册由哪个智能体发起。11-05 的文章把这三项能力称为「already in production」的第一批构件。

两篇是同一套治理设施的两步：一天给可操作的开关，一天给标准化方向。因此本文合成一篇，并分别标明日期。需要写清楚的是：TAD 是刚宣布成立的联盟与倡议，不是已经发布、可以直接实现的协议；站点侧三项能力才是当下可用的部分。

可用性与限制

• 联盟状态：刚宣布成立，官方称将举办 IETF 边会与研讨会；不是已定稿标准，也没有可实现的报文规范
• 站点侧能力：官方称「as of this week」且已在生产环境；账号滥用防护（Account Abuse Protection）仍标注早期访问（early access）
• 计划差异：Business Insights 明确面向 Enterprise Bot Management 客户；其余能力面向 Cloudflare 客户，具体套餐与配额公告未列
• 讨论范围：只覆盖托管在用户设备之外的远程个人智能体；本地智能体与用户自己浏览器内运行的智能体不在主议题
• 尚未定义：多中介链（A 智能体调用 B 智能体、再跑在 C 浏览器里）的识别机制、事实声明的传递机制、站点可机器读取的「智能体允许做什么」策略格式
• 未披露：地区清单、套餐价格、配额与 SLA；官方也未给任何 HTTP 头名、令牌格式、签名算法或报文示例，均以官方文档与后续草案为准

主要功能

• 在 Security Analytics 中把 Personal Assistants 单列为流量类别
• 列出访问站点的智能体、各自请求量、访问路径、返回状态码与来源网络
• 按单个智能体设 Allow、Block on pages with ads、Block 三档策略
• 保持 Search 与 Training 两类既有策略相互独立
• 在账号滥用防护里显示每次登录与注册由哪个个人智能体发起
• 用 Hashed User ID 上的 WAF 规则单独处置被滥用的账号，而不封禁整个智能体

技术原理

官方把问题拆成身份、声誉、问责三层，并给出偏好的技术映射。身份层偏好 Web Bot Auth（WBA）：让智能体对请求签名，从而安全地标识智能体及其运营方。隐私与声誉层点名 Privacy Pass、MOLE 与 Private Access Tokens，官方把 MOLE 描述为 Private Access Tokens 的后续技术方向，主张用「能否信任」而非「你是谁」来回答部分问题。账号身份层点名 OAuth。支付与限速方向点名 x402 协议与 MOLE。

站点策略层是缺口所在：官方指出 robots.txt 说明的是爬虫可以去哪，不足以表达智能体可以做什么；IETF 的 AI Preferences Working Group 目前聚焦训练、推理、搜索这类使用偏好，还没有覆盖这次提出的大范围偏好表达需求。文章也把身份写成一个梯度，从「不带来任何标识」到会话级、账号级、再到跨运营方的个人级标识，由站点按风险自行选择要哪一档。

要强调的是，这些是方向清单而不是已发布的协议细则：公告没有给 HTTP 头名、令牌 schema、签名算法、密钥分发或请求规范化流程。把上述名字当成「已经能接的规范」会读错，具体实现以官方文档与后续草案为准。

实际体验

不做主观实测，只记录两篇公告可核对的观察。

一是官方自己拆掉了两个常见方案。其一，把站点验证码透传给人类用户只证明此刻有人在场，不解决「同一智能体后面是哪个用户」的流量混合问题，还把智能体本来要消除的摩擦加了回来；其二，给智能体发窄范围授权在实践中往往变成「什么都能做」，因为智能体的用途就是替用户做任何用户能做的事，而「允许做什么」并不回答「出错了谁负责」。

二是有一处能自行验证的语义差异：传统 robots.txt 回答「能去哪」，官方要的是「能做什么」，两者不在同一层级。已有站点配置不能原样照搬，也不能因为写了抓取偏好就以为智能体动作边界已经声明清楚。

三是三项站点能力共用同一套检测设施：安全分析里的智能体识别、访问策略里的逐智能体开关、账号侧的智能体标记，官方把它们并列为「第一批构件」。这也正是把两天的公告合成一篇的判据——不是同一天凑两条，而是同一套准入与治理设施的两个动作。

四是官方承认护栏会两头出错：既可能漏掉有害活动，也可能打断合法工作，因此留了反馈邮箱与客服渠道。对企业站点来说，这意味着上线后仍需观察误伤，而不是设完策略就结束。

项目地址与获取方式

• 11-05 官方公告：https://blog.cloudflare.com/trusted-agent-delegation/
• 11-04 配套公告：https://blog.cloudflare.com/personal-agents-visibility-control/
• 联盟站点：https://trustedagentdelegation.org/
• Web Bot Auth 文档：https://developers.cloudflare.com/bots/reference/bot-verification/web-bot-auth/
• 账号滥用防护文档：https://developers.cloudflare.com/bots/account-abuse-protection/
• IETF 工作组：https://datatracker.ietf.org/wg/aipref/about/
• 获取方式：Cloudflare 客户在控制台的 Security Analytics 与 Security Settings 中使用；想参与标准化讨论按联盟站点说明加入。请通过官方渠道获取，避免安装被篡改的版本

适合谁用

• 运营内容站、电商或订阅服务，需要判断智能体流量是带来客户还是带来风险的站点方
• 反欺诈与账号安全团队，需要在不误伤同一智能体其他用户的前提下处置异常账号
• 智能体运营方与云浏览器、代理服务提供方，需要提前了解站点侧会要求哪些身份信息
• 跟进身份、隐私与偏好表达标准的工程与合规人员
• 不必用：只运行本地智能体、没有对外站点的个人开发者，以及正在找可直接接入的成品协议规范的团队——TAD 目前不是这类交付物

常见问题

TAD 是已经发布的标准吗？

不是。公告写的是成立联盟、组织讨论与检视现有协议，未来把定义清楚的问题带到 IETF；官方也明确说多中介链、事实声明传递与站点策略格式都还需要机制设计。它没有给出可直接实现的报文、头字段或签名规范，不能按「协议已发布」来写或来接。

不等新协议，现在能做什么？

按 11-04 的配套公告，站点侧已有三件事可做：在安全分析里看个人智能体流量与请求路径；用已改名的 AI Crawler and Agent access policies 按单个智能体设允许、仅在带广告页面拦截、或整体拦截；在处于早期访问的账号滥用防护里看登录注册由哪个智能体发起，并针对具体账号处置。Search 与 Training 策略保持独立。

为什么不让智能体把验证码转给用户？

官方的理由是：这只证明此刻有人在场，增加不了关于「请求代表谁」的信息，也回答不了出错时的问责归属；而且智能体的价值本就是减少摩擦，把人拉回流程会让运营方有动机绕过它。公告把这个方案归为主要用于防止误操作的机制，认为它解决不了前述大部分问题。

这和 robots.txt 的 AI 抓取偏好是同一件事吗？

不是同一层。官方写的是，robots.txt 表达爬虫能去哪，而需要的新机制要表达智能体能做什么；IETF 的 AI Preferences Working Group 目前聚焦训练、推理、搜索这类使用偏好，尚未覆盖后者。两篇公告都把它列为待补的标准缺口，不是现有配置能直接满足的需求。

相关工具与内容

站内 AI智能体分类 与 AI搜索分类 汇总了相关产品与入口；延伸阅读可看 Cloudflare 已验证机器人的问责机制、WebMCP 与智能体商务、robots.txt 的训练偏好信号，以及 GitHub 智能体工作流的护栏。