摘要

  • IETF Datatracker 目前把 AUDIT BoF 请求标为 Declined。2026 年 8 月 31 日建立的 non-WG 邮件列表可以讨论下一版 BoF 与拟议章程，却没有成立 AUDIT 工作组。
  • IESG 并未否定审计智能体行动这一问题的价值；它认为当前范围过宽，要求更清楚地说明 OAuth、WIMSE、OpenTelemetry 及相邻工作究竟还留下什么缺口。
  • 个人架构草案提出交互、行动、委托和授权转换四类记录，同时明确承认它不能解决服务拒绝记录、全部角色串谋、模型对齐等问题，详细威胁模型也尚未完成。
  • 一份可持续的“权力状态收据”应分别记录讨论场所、BoF 决定、章程批准、草案采纳、IETF 审议、RFC 发布和实际部署，避免把活跃度洗成机构授权。

8 月 31 日增加的是场所，不是授权

2026 年 8 月 31 日，IETF Secretariat 宣布建立 AUDIT 列表。对于一个横跨用户意图、智能体委托、工具调用和跨域证据的问题，这是一项有建设性的安排：参与者不必再把所有讨论寄生在别的列表上，也能把新章程写得更具体。

但新入口没有改写既有决定。AUDIT BoF 请求第 02 版的类型是“Declined BOF request”，当前状态也是“Declined”，最后更新时间为 7 月 6 日。BoF 请求总表给出相同状态。元数据中的 Responsible leadership 为空；正文虽然把 Security Area Directors 写作拟议负责 AD，并提出 Yaroslav Rosomakho 担任 chair，但这些是申请设计，不是任命结果。

新列表对自己的定位也没有含糊。IETF non-WG 列表目录写明，它用于讨论“潜在的”AUDIT BoF、更新“拟议的”章程，并朝建立新工作组的方向推进。这里每一个关键动作都指向未来。到本文截点，列表公开归档里只有创建通知，没有已经形成的章程共识，更没有一次被隐藏在邮件系统里的 WG 成立决定。

这种路径并不反常。non-WG 邮件列表指引本来就允许建立以形成 WG 为目标的列表，由适当的 Area Director 批准列表请求。这个批准的对象是沟通设施。它不同时批准 BoF、章程、里程碑、chairs 或标准项目。让人们有权进入房间，与让房间有权代表机构作决定，是两个不同动作。

RFC 2418 的 IETF 工作组指引说明了后一种授权需要什么：边界明确的章程、负责的 Area Director、受任命的 chairs、里程碑与过程。工作组必须有邮件列表，但这个命题不能倒推。拥有列表是工作组的一项必要设施，不是成立工作组的充分条件。

“Deferred”是当时用语，“Declined”是当前状态

6 月 3 日的 IESG 反馈使用了“deferred”一词。这段反馈保存在提案方 6 月 5 日的回复中。其内容并不是“智能体行动不值得审计”。相反，反馈认为概念很好，但当前提案太宽；它要求收窄范围，与 OAuth、WIMSE 相关人员磋商，并解释为什么既有工作或一个 OpenTelemetry profile 不能填补缺口。反馈还质疑，一些“意图”和“政策”概念是否更适合由法律框架而非 IETF 协议架构处理。

提案方追问 defer 的程序含义与时点，强调跨管理域拼接证据的困难，并在另一封 范围跟进邮件中继续技术论证。这些材料证明存在真实分歧，也保存了未来修改的线索；它们没有在邮件层面产生一次替代性批准。

准确记录无需强行统一两个词。Deferred 是 6 月沟通中的表述，Declined 是 9 月 1 日可见的 Datatracker 状态。一份好的状态记录应保留二者、日期、发言者与出处。它还应允许未来新请求建立新状态。说“当前请求被拒绝”并不等于断言 AUDIT 永远没有机会。

这里出现了 Heng Lu 在多利益相关方幻象中指出的基本错位：参加讨论不等于代表某个委托人，拥有发言席位也不自动带来授权。放在标准组织里，最常见的压缩就是“在 IETF 讨论”变成“IETF 已批准”。邮件列表的存在证明参与渠道，不能证明机构委托。

提案解决的不是“多记日志”

5 月 18 日发布的个人 AUDIT 架构草案面对的是一个实际难题：用户向智能体提出任务，智能体把一部分工作委托出去，在不同信任域调用服务，中途取得更高权限，最后造成现实结果。每个服务可能都有日志，但这些日志通常只知道自己的边界，无法共同回答原始要求、委托范围、授权变化和实际动作是否连得上。

草案把证据分为四族。Interaction Records记录面向用户的提示、回应、确认和批准，用来保存意图证据。Action Records由执行边界记录发生了什么。Delegation Records说明一个主体把什么权限交给另一个主体，包括范围和约束。Authorization Transition Records记录初次授权、step-up 批准、权限收窄、撤销和过期。

共享 audit context 可以携带关联标识符和前序事件引用。不同参与者从各自视角生成记录，audit store 再规范化并向审计者提供材料；RATS 或 SCITT 一类的证明与透明服务可作为可选增强。这套分类的价值在于拒绝把“用户说过”“系统做过”和“系统有权做”当成同一事实。

草案也诚实列出不解决的问题。它不假设智能体可信，只给 audit store 部分信任。它无法强迫某项服务记录发生在其边界的事件，无法处理所有关键角色共同串谋，也不处理驱动智能体的模型对齐。详细安全和威胁模型仍属未来工作。因此，一组签名有效的记录可以同时是真实的、选择性的和不完整的。

隐私风险也不是日后再加的一节。交互记录可能包含提示词、个人意图和商业信息；行动记录可能暴露工具调用与交易对象；全局关联标识符能把一个人在多家机构中的活动拼接起来。即使透明服务只登记哈希，也会泄露某个交互在某个时刻发生过。审计链越完整，对审计者越有价值，对监控者、诉讼对手或攻击者也越有价值。

另一份个人草案讨论可验证的智能体对话记录，可成为面向用户的 Interaction Record 候选。它并不是 AUDIT WG 文件，因为 AUDIT WG 不存在。签名过的对话也仍需回答内容最小化、删节、选择性披露、保存期限，以及如何在不制造永久身份标识的前提下绑定后续行动。

相邻标准提供部件，不提供总判决

IESG 要求说明与现有工作之间的缺口，不只是程序性刁难。一个跨域项目如果不明确产权边界，很容易把成熟协议重新包装，又把真正困难的缝隙推给“集成者”。

RFC 8693 OAuth 2.0 Token Exchange能表达委托语义和 token exchange 中的 actor chain。它可以证明权限如何在部分主体之间传递，却不能独立重建用户原始指令、后续每次授权转换、执行结果与审计者的政策判断。RFC 的基础协议也明确把详细 token 语义、安全属性和信任模型留在范围外。

W3C Trace Context传播分布式请求的关联标识符，帮助观察者知道哪些片段属于同一次流程。关联并不陈述权限。一个 trace ID 无法证明委托已经收窄、用户批准了高风险步骤，或结果符合授权。能把两件事串起来，不等于其中任何一件事有正当性。

RFC 9334 的 RATS 架构定义 Evidence、Verifier、Attestation Result 和 Relying Party 的政策判断。这有助于评价部件或执行环境，却不证明法律权限，也不证明机器忠实理解了人的意思。一台状态完全健康的设备，仍可能无误地执行一项未经授权的动作。

RFC 9943 的 SCITT 架构提供签名声明、append-only 透明服务，以及登记或包含收据。它能让删除和事后改写更容易被发现。它不会把被签名的说法变成事实，不会证明所有事件都被提交，也不会把完整性变成许可。收据证明某条声明进入了某个系统，不替声明承担真伪与权限判断。

所以 overlap analysis 应是一张职责与缺口表：OAuth 管具体委托机制，WIMSE 管工作负载身份，Trace Context 管关联，RATS 管环境证明，SCITT 管选定声明的透明性；AUDIT 必须指出仍无人负责的跨边界连接是什么、由谁定义、如何避免侵入现有章程。列出越多缩写，并不会自动形成更强的范围。

为制定审计标准的机构保留一份授权收据

这个案例有两条平行的审计链。技术提案试图说明谁授权智能体执行一项动作；IETF 的公共记录应说明谁授权参与者开展一项标准化工作。二者最危险的错误相同：把“有一条记录”误当成“记录中的主体有权这样做”。

一份轻量的权力状态收据可以从稳定的问题标识和精确提案版本开始。当前状态应枚举为 proposal、declined/deferred BoF、non-WG discussion、approved BoF、chartering、active WG 或 concluded。每次转换都写明有权产生该状态的主体、日期、原始决定链接和未经放大的处置词。

新版本还要写范围差异：删掉了什么，哪些任务交给相邻工作组，哪些跨域缺口仍被保留。AD 和 chair 在正式任命前始终标“proposed”。Venue 单独成栏，不能借用 authority。章程必须有获批版本与日期，否则为 null。文件必须区分个人草案与 WG 采纳草案，并附采纳记录。

WG Last Call、IETF Last Call、IESG evaluation 与未决异议都是独立状态。发布一栏应说明 Internet-Draft、RFC stream 和类别，不使用含混的“标准”统称。实现情况和政策拥有者属于部署一栏。某个产品实现个人草案，既不改变草案身份，也不替 IETF 形成共识。

最重要的是旧决定不可被后来的成功覆盖。如果新版 BoF 获批，它应链接本次 Declined 请求，并解释哪个范围差异赢得新结果。若未来 WG 采纳架构草案，也不能倒写早期个人版本。授权是沿时间形成的，历史不是一张只保留最后状态的白板。

按这个格式，当前 AUDIT 收据很简洁：个人架构草案存在；BoF 请求第 02 版收到认为范围过宽的反馈；Datatracker 当前记为 Declined；non-WG 列表为重写潜在 BoF 与拟议章程提供了场所；没有正式 responsible leadership、获批章程、工作组采纳或 IETF 共识。

不能以“问责”为由默认建立监控网络

未来范围若要可信，必须按记录类型规定数据最小化。无需跨域传输的内容可保留在本地，用 detached payload、哈希或选择性披露承诺代替全文。不同信任域之间若不需要全局拼接，应采用 pairwise 或不透明标识符。技术上能关联，不等于政策上已获准关联。

审计者的访问需要另行授权。运行调试、合同证据、安全调查和法定记录应有不同保留规则。系统必须公开缺口、拒绝记录和不可获得的材料，而不是悄悄补出连续叙事。一张收据只能声称覆盖它实际绑定的记录，不能暗示不存在其它相关事件。

这正是新邮件列表应完成的工作：把“意图”“委托”“透明”这些大词拆成可负责的协议问题、部署问题与法律问题；把隐私和威胁模型放入明确交付项；让下一次机构决定有足够窄、足够可检验的对象。准确称它为“列表”，没有贬低参与者，反而保护其成果不被过早的 IETF 品牌透支。