AI agent 代授权身份断层：服务器如何知道请求背后是用户还是中间层

默认情况下，服务器不知道。它看到的是 agent 所在的基础设施、运营方（Operator）的出口 IP、可能被统一或伪装的 User-Agent，而不是坐在后面的那个用户。Cloudflare 在 2026 年 11 月的两篇文章里把这个问题拆成两层：一层是“看得见”——站点能否把个人 agent 与其他流量区分开；另一层是“说得清”——站点能否保留与用户之间的关系，回答谁授权、谁负责。《Agents aren’t humans (but they kinda are)》（2026-11-05）定义问题空间并提出需要生态协作；《See the agents, set the terms》（2026-11-04）发布了可见性与访问策略的一部分能力。

需要先说明材料的边界。第一篇的抓取内容被截断，结论部分未提供，因此本文不总结它最终提出的协作机制是什么，只使用其中明确给出的问题定义与原则。第二篇把“保留用户上下文、评估信誉、建立问责”列为下一步目标，这意味着到文章发布时这些能力尚未交付。所以准确的说法是：可见性已有产品落地，代授权身份的通用机制仍在早期。价格、正式可用时间与其他厂商的等价能力，本次材料未提供，待核实。

断层不是“认不出机器人”，而是“认不出谁在授权”#

材料给出的定义是：Personal AI Agents 指接受人类（User）指令、通过控制云电脑或浏览器来追求目标的自动化程序，通常由 Operator 以托管服务或消费级产品形式提供。跑在用户自己设备或自己浏览器里的本地 agent 不在该文的主要讨论范围内。这个界定很重要——它把问题限定在“远程托管的中间层”上。

文章据此提出一条原则：

The Intermediation Principle: The business relationship between Users and Sites, and each participant’s security responsibilities, must be upheld regardless of intermediation.

这是规范性主张，不是已经实现的技术保证。它说明目标：无论中间隔了几层，用户与站点之间的业务关系、各方的安全责任都要能维持。要落地，材料说要能回答三个问题——操作者对自己身份（Identity）的陈述是否属实、这个人是否可信（Reputation）、出了事谁负责（Accountability）。

文章用了一个虚构人物 Ezra 来做类比：她替四位客户跑腿，店主只认识她，不知道谁喜欢什么；一位客户事后否认授权过某笔购买，店主却只能证明 Ezra 来过；另一位客户把一串密码交给她去银行逐个尝试，银行看得见攻击，但能封的只有 Ezra，一封就把四个人一起封了。换成 agent 和网站，就是今天的情况。这个例子是文章中的演示性类比，不是真实案例记录。

站点真正失去的，是几类原本可用的判断#

原文列了十几条挑战，可以归并成下表。这些是问题描述，不是已测得的比例或损失数字。

还有两类不涉及安全、但同样影响业务：agent 读取或抽取内容在别处回答用户，站点付了服务成本却没有访问、广告曝光或成交；agent 持续轮询库存与价格、反复打搜索和客服这类昂贵接口，把免费额度用尽。原文把前者称为“无补偿消费”。

现有可见性走到了哪一步#

第二篇文章给出的是单厂商实现，可以作为“现在能拿到什么信号”的参照，不构成行业标准。按原文，其能力包括：

• Security Analytics 的 Bot Analysis 图新增 Personal Assistants 类别，与 Verified Bot、Likely Human、Likely Automated、Automated 并列，可单独筛选个人 agent 流量。
• Top statistics 新增 Personal Assistants 组件，列出有哪些 agent 在访问、各发多少请求；按单个 agent 过滤后，可看它请求的路径、收到的状态码与来源网络。
• 处于 early access 的 Account Abuse Protection，可以看到每个 agent 代表哪个用户；登录与注册事件会标注是否由个人 agent 发起、是哪一个；账户概览会显示该账户关联的 agent。
• 怀疑某个账户被攻击者借 agent 利用时，可按该账户的 Hashed User ID 下 WAF 规则，而不必对该 agent 做全局封禁。
• 访问策略上，可先设一个整体 Agents 策略，再对受支持的个人 agent 单独选择 Allow、Block on pages with ads 或 Block；原 AI Crawler 设置更名为 AI Crawler and Agent access policies。

这些解决的是“哪个 agent 在访问、代表哪个账户”。它们不直接回答“这个用户是否授权了这一次具体操作”。

三个尚未闭合的缺口#

第二篇原文把后续目标写成三件事：以隐私友好的方式 (1) 把用户上下文穿过 agent 带过来，(2) 帮助站点评估信誉，(3) 在出问题时建立清晰的问责。原文同时说明站点可能认出了发起请求的 agent，却缺少本来会有的用户信息——是不是老客户、授权 agent 做了什么、有没有订阅、该适用哪种保护。这段是路线图表述，不是既有能力。

第一篇材料给出的方向是生态需要新机制来维持站点与用户之间的关系，但具体机制在截断部分，本次材料无法核实。围绕“用户委托凭证由谁签发、如何验证、如何防止转借”这类问题，目前没有可引用的公开标准结论，待核实。

给接入方的实践建议#

以下是建议，不是从材料中直接得出的事实结论：

1. 不要把 agent 身份当作身份认证。“来自某个已知 agent”只能说明流量来源，不能说明谁授权。策略应尽量绑到账户或用户标识上，而不是 UA 字符串或 IP 段。
2. 先把 agent 流量单独打标，再决定放行或限制。没有分类就没有策略依据；原文的发布顺序也是先给分析视图，再给按 agent 的策略。
3. 封禁要按账户收敛，避免按 agent 全局封。一个 agent 背后是许多用户，全局封禁的误伤面与它的用户规模成正比。
4. 在日志里显式记录“授权信息是否存在”。如果业务涉及支付或敏感操作，至少要能区分“有可核验的授权记录”和“只有 agent 自报身份”两种情况，不要用后者冒充前者。
5. 不要靠人机验证补身份。它回答的是另一个问题，通过与否都不提供用户归因。

一个示意：日志里该能回答哪几个问题

下面是为说明结构而写的占位示例，未在任何环境执行，字段名是演示用的，不代表现有标准或任何厂商的协议。

{
  "request_id": "req_demo_0001",
  "client": {
    "claimed_agent_id": "agent-example",
    "operator": "example.com",
    "user_agent": "YOUR_UA"
  },
  "account": { "hashed_user_id": "u_demo_hash" },
  "delegation": {
    "present": false,
    "issuer": null,
    "scope": null,
    "issued_at": null
  }
}

它的用途不是给出实现，而是明确一件事：当 delegation.present 为 false 时，服务端能确认的只有“某个 agent 代表某个账户发起了请求”，不能确认该账户授权了这次操作。后续是否补上委托凭证，取决于生态标准与 operator 的配合，目前待核实。

边界条件#

• 本文讨论的是远程托管的个人 agent。本地 agent 或运行在用户自有浏览器中的 agent 被第一篇明确排除在主要话题之外，其识别难度与远程 agent 不同。
• 把用户上下文穿过中间层，必然涉及隐私取舍；原文强调要“隐私友好”，但具体做法未公开。
• Cloudflare 的这套能力是其自身产品范围内的实现。其他 CDN、API 网关或身份提供商是否提供等价信号，本次材料未涉及，待核实。
• Account Abuse Protection 处于 early access，功能范围与正式可用时间以其官方说明为准。

结论#

回到标题的问题：服务器现在能知道“是哪个 agent、哪个运营方在访问”，在部分早期功能覆盖的场景里也能知道“它代表哪个账户”；但它还不能普遍知道“这个用户是否授权了这次具体操作”。前两者已有产品落地，后者需要凭证、信誉与问责三套机制配合，材料显示仍处于提案与早期实现阶段。对做接入的一方来说，这个断层的落点不在多解析一个请求头，而在日志与策略里有没有可归因的授权记录——没有的话，应当如实标注为缺失，而不是用 agent 身份替代。