Cloudflare于2026年11月5日宣布发起Trusted Agent Delegation（TAD）协作，旨在推动网站、智能体运营方与生态参与者共同解决代理代替用户上网时的身份、授权与责任划分问题。TAD目前为治理与技术讨论平台，将评估现有协议（如Web Bot Auth、OAuth等）、梳理需求并在必要时推动IETF讨论，但尚未形成可直接部署的统一标准或责任机制。
Cloudflare于2026年11月5日宣布成立Trusted Agent Delegation（TAD）协作联盟，希望推动网站、AI智能体运营方及其他生态参与者共同解决一个问题：当智能体代替用户上网时，网站如何知道它代表谁、可以做什么，以及出错后由谁负责。
这不是一套已经完成的授权标准，也不是新一轮访问控制产品上线。按照Cloudflare的公告，TAD将讨论实际需求、审视现有协议，并在必要时把更明确的问题带到互联网工程任务组（IETF）讨论。公司计划未来举行IETF边会和研讨会，尚未宣布这些活动已经完成。
网站看见了助手，却可能看不见客户
公告主要讨论远程托管的个人智能体：用户下达指令，由运营方提供的云端计算机或浏览器代为完成任务。网站直接接触的是中介，同一个智能体服务背后可能有大量不同用户。
Cloudflare用一组假想场景解释其中的风险：用户让助手购物，之后否认授权付款；另一个用户让同一助手反复尝试密码，网站发现攻击，却只能封锁整个助手服务。前者涉及交易授权和举证，后者涉及如何处理单个用户的滥用，而不影响其他正常客户。这些是公司用于说明问题的例子，不是公告披露的真实事故。
网站以往依靠设备、会话、IP地址和历史行为判断风险。云端助手改变了这些信号与用户之间的关系：客户可能没有变，发出请求的设备和网络却变了；反过来，来自同一服务的请求也不一定属于同一个人。
公司的核心主张是，即使中间多了一个代理，网站与用户原有的商业关系及各方安全责任仍应得到维持。它将需要解决的问题概括为身份、信誉和责任。不过，这是一套待推进的治理与技术目标，并不表示现有争议处理规则已经改变。
验证代理身份，不等于证明用户授权
TAD涉及的并非单一身份凭证。网站可能只需要知道几次请求属于同一会话，也可能需要把访问关联到已有账户；在受监管或高风险操作中，还可能需要年龄、持卡人身份等额外信息。
Cloudflare倾向于使用Web Bot Auth识别智能体及其运营方。其开发文档说明，这种机制通过HTTP消息中的密码学签名验证自动化请求的来源，并依赖相关IETF草案；文档描述的是Cloudflare自身的集成方式。
签名解决的是请求来源的认证问题，不能自动证明背后用户授权了某一笔购买，也不能决定错误订单或欺诈交易的赔偿责任。公告还指出，当一个智能体调用另一个智能体，再通过第三方浏览器访问网站时，如何表达和识别这条中介链，仍需进一步定义。
因此，不能把“代理已验证”理解为“行为已获授权”或“交易必然安全”。身份、权限和责任需要相互衔接，但并不是同一件事。
更多上下文，是否意味着更少隐私？
网站希望获得更多信息以控制风险，用户却未必愿意为了使用助手而暴露更多个人资料。TAD试图在这两种需求之间寻找边界。
协作官网将其标为“即将开展的协作”，并显示白皮书尚待发布。网站提出的目标，是只分享当前交互所需的信息，避免形成跨站追踪。它展示的预期用例是一名老客户更换购物助手：新助手提供委托访问证明并标识运营方，商家仍能延续与客户的关系，同时检查新助手的权限。这是设计目标，而非已经验证可用的完整流程。
Cloudflare的公告还把MOLE列为正在发展的隐私保护路径，举例说明限流不一定需要用户专属标识，并将OAuth列为传递账户身份的相关机制。这些协议各自解决不同层面的问题，不能据此推断它们已经组合成一套可直接部署的TAD系统。
公司也没有主张每次操作都必须有人在场。其观点是，把验证码转交用户完成，只能说明当时有人参与，无法完整回答代理长期代表谁、具体获准做什么以及发生争议时由谁承担责任。人工确认可以减少部分误操作，但不是所有身份和责任问题的替代答案。
与现有标准工作的关系，仍需划清
Cloudflare希望连接现有实现与正在形成的规范，而不是仅依靠厂商各自定义的机制。公告提到了Web Bot Auth、OAuth、WIMSE、MOLE及AI偏好表达等工作，但没有宣布IETF已经采纳TAD为统一标准。
这一差别在AI Preferences（AIPREF）工作组的范围上尤其明显。IETF公布的工作组章程聚焦于表达内容在AI模型开发、部署和使用中的收集与处理偏好，并明确将偏好的技术强制执行，以及客户端或爬虫认证、授权的应用层协议排除在当前章程范围之外。
换言之，让网站表达内容使用偏好，与让智能体证明某项操作的授权，是相邻但不同的工作。TAD拟把实际需求梳理清楚后再推动讨论，不能被写成已有工作组已经承诺交付整套方案。
适用范围同样有限。公告指出，在用户设备或个人浏览器中运行的本地智能体面临不同问题，并非TAD初期工作的重点。这不等于所有本地工具都被禁止访问网站，而是本次协作尚未把它们作为首要解决对象。
已有控制工具，与尚未完成的责任机制
TAD紧接着Cloudflare此前的产品更新出现。公司在11月4日宣布个人助手流量分析和对受支持代理的细粒度访问策略；账户关联能力则涉及仍处于早期访问阶段的Account Abuse Protection。此前关于这轮更新的报道已说明，看见哪个代理访问网站，与确认用户授予了什么权限之间仍有距离。
11月5日公告中的新增进展，是正式宣布跨生态协作，而不是再次发布这些流量分析和访问开关。现有工具可以帮助网站观察请求、设置访问规则，并在特定账户保护场景下处理滥用；它们没有因此成为覆盖所有网站、运营方和用户的通用委托授权基础设施。
TAD能否推进，最终取决于协议如何传递可验证且必要的信息、网站和运营方是否愿意采用，以及争议发生时各方能否形成可执行的责任安排。截至本次核验，公开材料呈现的仍是协作目标和技术方向，而不是已经解决这些问题的结果。