代理链路剥离用户身份后：agent 委派授权要记录哪些可核对字段

当远程托管的 Agent 作为中介替用户访问站点时，站点看到的是 Agent 或 Operator 的基础设施，而不是用户本人。此时只记录一个 agent_id 无法核对授权。要让委派可核对，一条记录至少要能回答：谁委托、谁代表、代表谁、能做什么、何时有效、如何证明、谁负责、如何撤销。

Cloudflare 在 2026-11-05 的文章中把问题拆成身份（Identity）、声誉（Reputation）和可追责性（Accountability）三问，并列出账号共享、友好欺诈、身份冒用、流量混同等挑战（来源）。但本次可获取的正文片段被截断，未提供完整字段清单；摘要提到的协作方法也没有展开到字段级。以下内容是工程建议，不是该文或任何标准的规范。

先划边界：身份剥离发生在哪一层#

材料把“个人 AI Agent”定义为：接受用户指令，通过控制云电脑或浏览器追求目标的自动化，通常由 Operator 托管和维护。远程托管 Agent 是中介，站点看到它而不是用户；一个 Agent 可以代表多个用户，有时用户和站点之间还有多层中介。文章的核心原则是：无论是否经过中介，用户与站点之间的业务关系和各方安全责任都应被维持。

这解释了为什么“登录时带了用户 ID”不够。Agent 可能用同一个运行实例服务多个用户，也可能用住宅 IP 和真实浏览器隐藏自己。攻击者还可以复制知名 Agent 的 User-Agent（UA）。因此，委派记录不能只靠自述字段，而要分成“声明”与“证据”：声明说明意图，证据说明谁签发了什么、对哪次请求有效、能否撤销。

五组建议字段#

字段名只是示例，重点是语义。站点应按自身风险选择最小集合，并明确哪些字段参与授权判定，哪些只进入审计日志。

1. 用户与代理身份：区分“谁”与“什么软件”

• user_ref：稳定的用户引用，建议使用成对匿名标识：同一用户在同一站点可关联，跨站点不可关联；不要默认记录邮箱、手机号明文。
• agent_id、operator_id、agent_instance_id、agent_version：区分代理产品、运营方、运行实例和版本。
• key_id、public_key_fingerprint：用于验证签名和支持密钥轮换。

IP、UA、TLS 指纹可以作辅助风控，但不能单独作为身份。材料指出 Agent 常运行在住宅 IP、使用真实浏览器，UA 也可能被复制；把这些信号当身份，会把“伪装得像人”误当成“就是那个人”。

2. 委派范围与生命周期：把授权写成可判定条件

• delegation_id、parent_delegation_id：支持多层中介和委派链。
• issuer、subject、audience：谁签发、签给哪个 Agent、面向哪个站点或资源。
• scope：允许的动作、资源、金额/次数/速率上限，以及是否允许继续子委派。
• issued_at、not_before、expires_at、单次/会话属性。
• revocation_endpoint、revocation_status、checked_at：撤销入口、当前状态和最近检查时间。

这些字段让站点能判断“这次请求是否落在授权范围内”，而不是只知道“有一个 Agent 来了”。没有范围，账号共享、资源耗尽和流量混同都难以区分正常使用与滥用。

3. 请求绑定与防重放：让记录只对本次请求有效

• method、path、body_sha256、timestamp、nonce 或 jti、audience。
• 签名覆盖上述字段；站点验证签名、时间窗和 nonce 是否重复。

没有请求绑定，日志里的旧授权可以被重放；有了绑定，记录才能作为本次操作的证据。对支付、下单、改配置这类敏感动作，请求绑定应作为单独的证据层，而不是只放在访问日志里。

4. 验证、同意与责任：不要把声明当验证

• user_verification：验证了哪些属性（例如年龄、地域、了解你的客户（KYC）等级）、由谁验证、方法、时间、结果；未验证项要显式标注。
• consent_record：用户对具体交易或操作的确认引用，包含交易 ID、金额、时间、确认方式。
• responsible_party：用户、Operator 或两者；同时记录条款版本和争议联系点。
• 可选的 reputation_assertion：谁对哪个 Agent/Operator、基于什么证据、在什么时间给出声誉断言；它不能替代签名。

材料指出，Agent 不提供能满足站点合规要求的保证；身份验证原本假设“在场的人就是被验证的人”，而 Agent 不是那个人。因此记录必须说明“谁做了验证、验证了什么”，而不是只写“已验证”。同理，责任主体字段只是记录责任声明，不解决法律或合同上的责任分配。

5. 审计与撤销：让事后核对有路可走

• audit_event_id、日志保留策略、完整性哈希链、访问控制。
• 撤销传播窗口和缓存 TTL；撤销后多快生效要可核对。
• 最小化个人数据；对用户标识做哈希、加密或成对匿名处理。

站点还需要定义信任根：哪些 Operator 或密钥被允许签发委派记录，密钥如何轮换，撤销列表由谁维护。没有信任根，签名只能证明“某个密钥签过”，不能证明“这个 Agent 被允许代表用户”。

与材料中挑战的对应#

下表是工程推断：用字段回应材料列出的问题，不是来源给出的字段方案。

一个演示记录（未执行）#

下面只是字段形状演示，不是实际协议；example.com、operator.example 和签名值均为占位，未运行验证。

{
  "delegation_id": "dlg_demo_001",
  "parent_delegation_id": null,
  "issuer": "user:pairwise:demo",
  "subject": "agent:operator-demo:instance-42",
  "operator": "operator:demo",
  "audience": "https://api.example.com",
  "scope": {
    "actions": ["read:orders", "create:order"],
    "limits": {"max_orders_per_day": 3, "max_amount": 10000, "currency": "CNY"}
  },
  "issued_at": "2026-11-06T00:00:00Z",
  "expires_at": "2026-11-07T00:00:00Z",
  "user_verification": [
    {"claim": "age_over_18", "verified_by": "issuer", "method": "demo"}
  ],
  "consent_record": {"transaction_id": "tx_demo_001", "confirmed_at": "2026-11-06T00:01:00Z"},
  "responsible_party": ["user:pairwise:demo", "operator:demo"],
  "request_binding": {
    "method": "POST",
    "path": "/orders",
    "body_sha256": "DEMO_HASH",
    "nonce": "demo-nonce"
  },
  "signature": {"key_id": "demo-key-01", "value": "DEMO_SIGNATURE"},
  "revocation": {"endpoint": "https://operator.example/revoke", "status": "active"}
}

生产环境不要使用示例中的 DEMO 签名算法；签名算法、密钥信任根和撤销列表的维护方式需要单独设计并待核实。记录字段本身也不等于完成验证：站点还要实际执行签名检查、时间窗检查、nonce 去重和撤销查询。

核对清单#

1. 能否从一条记录中回答身份、权限、责任三问？
2. user_ref 是否稳定、是否避免跨站点关联、是否不暴露明文个人数据？
3. agent_id、operator_id、key_id 是否由可验证签名绑定？
4. scope 是否具体到动作、资源、金额/次数/速率上限和有效期？
5. 是否记录授权签发时间、过期时间、单次或会话属性？
6. 是否记录验证了哪些属性、由谁验证、何时验证、哪些未验证？
7. 请求签名是否覆盖方法、路径、请求体哈希、时间戳和 nonce？
8. 是否有撤销端点、撤销状态和可核对的传播窗口？
9. 是否记录责任主体、条款版本和争议联系点？
10. 日志是否最小化、可做完整性校验，并有明确保留期限？

边界#

字段是否足够，取决于站点风险、Operator 配合程度和所在辖区的合规要求；具体监管要求待核实。本文讨论的是远程托管 Agent 作为中介的链路；材料明确把本地 Agent 和用户自己浏览器中的 Agent 排除在主要讨论范围之外，那类链路的字段需求可能不同。Cloudflare 本次可获取材料被截断，不能把本文当成其完整提议。对 API.PLUS 这类 API 接入与代理场景，更稳妥的做法是先把委派记录定义成独立于具体接口的请求前对象，再让网关做签名、撤销和日志校验，而不是等日志里只剩 IP 和 UA 才补身份。