Cloudflare 谈智能体代理访问：站点如何识别、管控并追溯背后的用户

Cloudflare 在博客中把远程托管的个人 AI 智能体定义为一种新的“中介”：它介于用户与站点之间，站点看到的是智能体而非用户本人。文章以助理 Ezra 代四位客户办事为例，说明由此产生的流量混同、退款纠纷、凭据尝试和封禁误伤等问题，并指出在几乎所有场景中，成本主要由站点承担。 文章提出“中介原则”，即用户与站点之间的业务关系及各方安全责任不应因中介介入而失效。站点需要继续回答三个问题：行为者是否如实表明身份、是否可信、由谁为行为负责。作者认为，把 CAPTCHA 转交给用户解决只能证明当下有人在场，无法区分同一智能体背后的不同用户；而“全范围”授权也只说明智能体被允许做什么，不说明出错时谁负责。 在技术路径上，文章主张复用并完善现有标准：Web Bot Auth 用于智能体对请求签名以表明自身及运营方身份，MOLE 用于在不暴露用户标识的前提下做限流与信誉判断，OAuth 用于传递账户身份，此外还需要机制让站点请求“已满 18 岁”“是持卡人”等事实性声明。文章还指出，目前智能体只能靠试探站点响应来推断规则，robots.txt 不足以表达智能体可执行的动作，IETF 的 AI Preferences 工作组主要覆盖训练、推理和搜索偏好，尚缺更广的偏好表达机制。 Cloudflare 同时宣布成立 Trusted Agent Delegation（TAD）联盟，计划联合运营方、身份验证公司、支付方、商户、发布商、代理服务商和云浏览公司，把现实需求带入 IETF 的 Web Bot Auth、AIPREFs、OAuth、WIMSE、MOLE 等工作。 已落地的能力方面，Cloudflare 客户本周起可在 Security Analytics 中把个人助理作为独立流量类别查看，新组件会列出每个访问智能体、请求量、命中路径和错误；可按智能体配置 AI Crawler and Agent 访问策略，例如全站放行、仅在广告页拦截或完全拦截，且搜索与训练策略保持独立；使用 Account Abuse Protection（早期访问）的站点，每次登录和注册都会显示是否由个人智能体发起以及是哪一个，并可针对单个账户用 Hashed User ID 的 WAF 规则处置，而不封禁该智能体背后的其他正常用户。文章说明，设备端或本地托管的智能体（如 OpenClaw）不在本次讨论的主要范围内。