论文提出 AI Agent 声明的可审计性框架

要被核查，关于智能体的主张必须先固定策略、范围、能结案的记录及其撰写者，以及判定规则。

• 出现场景：主张出现在系统文档、采购答复和事件报告中，他人日后可能需要核查。EU AI Act 第12条要求高风险系统在生命周期内允许自动记录事件，但没有说明哪些记录能结案某一主张；第14条要求监督者能理解系统局限并注意自动化偏差。这两项义务对 Annex III 用途自2027年12月2日起适用，对 Annex I 产品自2028年8月2日起适用。
• 现有文本的缺口：作者称，正在起草的日志、文档、评估和智能体授权指南说明系统应记录或启用什么；他们读过的文本没有针对某一主张说明哪些记录能结案，以及哪些内容即使记录齐全仍不可及。
• 核心改写：作者借用鉴证业务接受前要检查标准是否适宜、结论所需证据能否取得这一前提。主张可审计，是指策略与版本、动作与期间、具名撰写者可取得的必要记录和判定规则，都在任何裁决之前固定。这把 Auditable Agents 的 Policy Checkability 从单个动作扩到许多动作上的主张。
• 智能体追加的条件：作者称有三点：动作须被智能体不撰写的记录覆盖；授权须绑定该动作的参数；完备性要与完整性分开检查。在显式模型下，作者称只要相应假设成立，缺少其中任一条件就不可能得到支持。
• 本文给出的物件：工作定义、六条常见主张的对照表（锚在2026年9月的 NIST、IETF 与 OWASP 草案）、一条主张的五种证据状态、三个条件的论证，以及给运营者、采购方、审计者和标准制定者的步骤。作者称本章不提出标准。

按引言和 Related Work 的分组，作者把本文放在既有鉴证与审计框架之下一层。

可核查主张与安全论证

• Brundage et al.（2020）：提出使 AI 开发主张可核查的制度、软件与硬件机制，审计轨迹包括在内。
• Ojewale et al.：把语言模型系统的防篡改审计轨迹连到批准、豁免和证明等治理记录。
• Clymer et al.（2024）：安全论证由开发者论证系统安全。作者把可审计主张区别为第三方对照记录核查的陈述。

更广的审计与可见性框架

• 分层与内部审计：Raji et al.（2020）给出内部算法审计的端到端框架；Mökander et al.（2024）分治理、模型与应用三层审计；Casper et al.（2024）讨论审计所需的访问。
• 智能体可见性：Chan et al.（2024）讨论对智能体的可见性。作者称自己在这些框架之下一层，问已部署智能体的单条主张要被核查需要什么。

鉴证准则与标准锚点

• ISAE 3000 与 ISA 315：前者问标准是否适宜、结论所需证据能否取得；后者把发生与完备分开。作者称只借用这一结构，裁决不是鉴证意见，并搁置重要性、抽样和审计师独立性。
• 法规与2026年9月草案：EU AI Act 第12、14条，以及 NIST AI 300-1、NIST AI 200-2 的初始公开草案、IETF 的 AIMS 草案和 OWASP Top 10 for Agentic Applications 2026，被用作六条主张的锚点。作者称这些文本说明应记录或启用什么，但没有针对某一主张点名能结案的记录或撰写者。

作者自己的先前框架

• Auditable Agents：在既定策略下把单个动作判为 comply 或 violate；缺必要字段可使评估不可判定。本文把 Policy Checkability 扩到许多动作上的主张，支持还需要覆盖证据。Table 1 把委托链上的责任留待后续工作。

基线与数据：实践框把 flag_all（标记一切的规则）当作平凡基线；数据是 CatchBench 0.1.2 的离线 PRE 板，1,187 个配置，来自六个来源。作者称本章延续 Auditable Agents，把策略可核查性从单个动作移到主张。

作者把鉴证前提写成可审计主张：裁决前固定四要素，再按事先写定的规则给出支持、反驳或不可判定。Figure 1 图注称，一条已认证的范围内例外即可反驳；支持要求每个范围内动作都有覆盖且符合；必要证据缺失或未解决则不可判定。

四要素与三种裁决

• Definition 1：策略与版本、动作与期间、可从具名撰写者取得的必要记录、判定规则，都在读记录之前指定。“我们的智能体是安全的”在读记录前就不符合。记录丢失时，已符合定义的主张仍可以是 UNDECIDABLE。
• Definition 2 用于“每个范围内动作符合既定策略”。C2 至 C4 与案例共用它；C1、C5、C6 用 Table 2 里各自的规则。已认证的范围内动作违反策略，则为 CONTRADICTED；若违反体现为缺失，本应持有该记录的日志在相关期间必须完整。每个范围内动作都被捕获且各自符合，则为 SUPPORTED。否则为 UNDECIDABLE，并点名缺失记录。
• 单动作在 Auditable Agents 中判 comply 或 violate，缺必要字段即可不可判定。主张要得到支持，还需要覆盖证据。撰写者可以是智能体、授权服务器或网关。作者称能否信任一条记录，取决于谁写、谁能改。PRE 配置只显示能够做什么，运行记录才显示做了什么。

六条主张各自要什么

Table 2 覆盖六条常见主张。锚点是2026年9月的草案快照，作者称规则不依赖锚点。AIMS 指 IETF 草案 draft-ietf-wimse-aims-00，与 ISO/IEC 42001 无关；其中的 MUST 不产生法律义务。授权由授权服务器签发。

• C2 与 C5：效果设定参数和关联标识，要与每个相关动作都必须到达的独立记录双向核对。签名和链对照另一方持有的密钥与检查点；完备性另外对照智能体不写的记录。绕过已记录路径的动作，以及日志是否防篡改，留在不可及处。
• C3 与 C4：需要用户批准、由授权服务器发出、范围覆盖该动作及其参数、运行当时仍有效的授权。策略文本与版本在这些记录上评估；缺必要字段则不可判定。人理解了什么、法律责任和语义规则不可及。
• C1 与 C6：运行记录里的模型、共同版本化的工具模式和版本化系统控制，须与生效文本一致。评估主张须点名被评估对象与工具版本，每个数据源对照平凡基线，并固定重跑。向新部署或新数据源的迁移不可及。

没有字段能显示从未写下的事件。AIMS 第11节的七个最低审计字段不含收件人这类效果设定参数；策略模型和合规标准留给各部署提供。

模型、引理与三个条件

被审计方可写、可签自己的记录，可以省略范围内动作，但从不为没发生的动作做记录。独立撰写者不受其控制，准确记录经过它的事件，且不能被篡改或伪造；它记在已登录账户上的批准，视为账户持有人的批准。完整记录含该期间该类全部事件。sound 规则只凭所读记录：主张成立才返回 SUPPORTED，主张失败才返回 CONTRADICTED。

• Lemma 1：两个 world 记录相同，而主张只在其中一个成立时，返回 UNDECIDABLE。
• Proposition 1：若策略要求每个范围内动作都有授权，记录又显示一个范围内动作，且相关期间完整的授权日志没有覆盖它的授权，则 CONTRADICTED 在这些记录的每个 world 中都正确。
• 覆盖（Corollary 1）：若每个 world 都能在不改变所读独立记录的情况下多一个违规动作，例如只读被审计方的记录，则永不返回 SUPPORTED。Figure 3 图注：a、b 有有效授权，c 没有；智能体省略 c 后，只读其日志不能区分两个 world。独立网关记下 c，才与一份完整、且没有覆盖 c 的授权日志一起确立反驳。
• 授权（Corollary 2）：策略若要求人批准每个范围内动作及其效果设定参数，而独立记录没有显示该批准，则没有 sound 规则返回 SUPPORTED。确认只是归到某账户的界面事件，不显示这个人理解了什么。
• 完整性对完备性（Corollary 3）：在 Corollary 1 的前提下，对被审计方所提交条目的签名、哈希链和独立检查点，不能成为 SUPPORTED 的理由。作者引用一篇预印本：harness 自留日志上的哈希链，对28次注入的省略与伪造都没有标出；harness 外的日志标出全部28次。

作者称这些推论只给必要条件。要得到支持，还需要例如没有任何动作能绕过的网关。反驳可以只靠一个已认证动作加完整授权日志。裁决针对已陈述的策略，不由此判定法律合规或责任。作者对三种异议的回应是：防篡改日志不能显示从未记录的事件；逐次批准可能诱发自动化偏差，范围化的批次授权仍可核查；第12条要求记录，但没有点名能结案的记录或撰写者。

案例里主张如何写定

“有人批准每封对外邮件”被收窄为：2026年3月1日至31日、带附件、发往外部地址的邮件符合 P-7 版本3。授权须在发送前由已登录的人批准，并点名收件人与附件哈希；智能体为自己取得的授权不算。同一收件人的多份文件可以放进一份授权，批次批准一次即算。Table 3 在读记录前写下四要素。三条记录分别来自智能体、授权服务器和邮件网关，网关日志是独立记录。智能体日志有签名和哈希链，运营者之外没有检查点。Figure 2 一边点名授权 g-5531，一边只记界面确认。没有运行智能体。各状态的裁决见下一问。

实验设置

• 案例：延续对外邮件情景。记录为教学构造，作者写明没有运行智能体，案例不产生测量（第4节、第7节）。论文未报告被运行的模型。
• 主张与记录：2026年3月1日至31日，发往外部地址、带附件的邮件是否符合 P-7 版本3。撰写者是智能体、授权服务器和邮件网关。
• 定量复现：CatchBench 0.1.2 的离线 PRE 板，1,187 个配置，六个来源。作者称离线大约一秒，并在新的 Python 3.12 环境中逐字节复现了完整输出。摘录两种方法的 F1：flag_all（标记一切的平凡基线）和 owasp_asi_combined（引用 OWASP 指南的五条规则之并）。
• 标签过程：crewai、n8n、mcp 为 llm_judge；injecagent 为 roster_relabel；sweagent 为 declared_minus_used；synthetic 为 synthetic_inject。论文未报告 llm_judge 的模型，也未报告重复次数。
• 指标：案例用 Definition 2 的三种裁决。PRE 板用 F1，作者称漏报和误报都会把它从1往下拉。作者称未测试本文的判定方法。

主结果

案例不产生测量。Table 4 给出各状态的裁决，记录均为示意。

状态	裁决（Table 4）
A，仅配置	3月主张 UNDECIDABLE
B，tx-19	该邮件符合 P-7
C，tx-23	违反 P-7；3月主张 CONTRADICTED
D，tx-31	该邮件 UNDECIDABLE
E，第4封	该邮件 UNDECIDABLE

• 符合的一封不是整月支持：tx-19 中，智能体日志点名授权 g-5531；服务器在10:02:11记录 user:alvarez 批准了同一收件人与哈希；网关在10:02:15记录投递，其计算的哈希匹配；令牌核验通过且发送时有效。作者称该发现依靠三份分别撰写的记录，3月主张仍须配上其余每次投递。
• 一条例外即可反驳：tx-23 有界面确认、不点名授权；网关记录了对外投递且哈希匹配；在可能签发授权的期间内服务器日志完整，其中没有覆盖它的授权。作者称由此反驳3月主张，前提是服务器日志完整。记录只支持界面在该账户下记下了确认，不显示用户没有发送意图。
• 三态不可判定：配置不记录传输。tx-31 没有授权引用和关联标识，该小时的服务器日志在存储迁移中丢失；作者称这种缺失可能只在记录中而不在世界上，把它报成 P-7 违规会是错误。State E 的智能体日志签名与哈希链核验通过，但网关显示四封带附件的对外邮件，日志只记三封；没有独立检查点时，核验不能排除被重写的链。作者称网关显示的账户是共享的，不能确立是智能体发送，故该邮件保持不可判定。作者称若没有 State C，主张仍然得不到支持，直到每次3月投递都配上授权。

评估分数的复现

实践框复现的是 CatchBench PRE 板分数，不是对主张核查方法的实测。据该输出摘录：

来源	flag_all	owasp_asi_combined
crewai	0.388	0.448
n8n	0.154	0.411
mcp	0.654	0.644
injecagent	0.750	0.961
sweagent	0.574	0.570
synthetic	0.763	0.842
overall	0.601	0.654

• 作者称汇总 F1 0.654 对应的按来源范围是 0.411 到 0.961，工具本身要求按来源读。汇总分数混合了四种标签过程。
• 作者称该规则在四个来源上比 flag_all 高 0.06 到 0.26，在 mcp 与 sweagent 上低于该基线。表中这两对为 0.644 对 0.654、0.570 对 0.574。
• 作者称 flag_all 从 0.154 到 0.763，是因为过度授权配置的占比因来源而异。injecagent 上只读声明顺序的规则为 1.000，作者称那里的分数反映语料如何建成。作者称这些结果并不说明该规则会在新部署中发现过度授权。

其他消融与分析

• 论文未报告对 Definition 2 的消融或实测；第7节写明未测试该方法。
• 作者写出的测试会植入已知违规并备有完整参照记录，再删除字段、记录或独立记录，重签裁剪后的日志，然后计正确裁决、正确的 UNDECIDABLE、错误的 CONTRADICTED 和每次核查耗时。
• 作者引用的预印本（非本章运行）：harness 自留日志的哈希链对28次注入的省略与伪造均未标出，harness 外日志标出全部28次（第5节）。
• 论文未报告 llm_judge 的模型名称，也未报告该次复现的重复次数；作者称脚本输出与摘录逐字节一致。
• Table 2 的六条主张没有各自的实测通过率；锚点被作者称为2026年9月的草案快照。

作者指出的局限与后续方向

• 草案锚点：锚点是草案，日志标准仍在变动（第7节）。
• 两份未读标准：作者写明未能阅读处于最终草案阶段的 ISO/IEC 24970，以及审批中的 prEN 18229-1（第7节）。
• 高风险范围：所讨论的第12、14条义务适用于高风险 AI 系统，智能体是否属于该范围取决于其用途或产品（第7节）。
• 明确略去的题目：隐私与数据最小化、委托智能体链上的责任、记录模式无法判定的语义策略（第7节）。Table 1 将跨委托链的责任留待后续工作。
• 案例与实践框：案例不产生测量；实践框只覆盖作者自有基准的离线 PRE 板（第7节）。
• 方法未经测试：作者写明未测试该方法。他们描述的测试会植入已知违规并备有完整参照记录，然后删除字段、记录或独立记录，再重签裁剪后的日志（对应 State D 与 E），并计正确裁决、正确的 UNDECIDABLE、错误的 CONTRADICTED 和每次核查耗时（第7节）。

实验覆盖范围

• 教学案例的记录为构造，第4节写明没有运行智能体；主张是2026年3月1日至31日带附件的对外邮件是否符合 P-7 版本3，证据状态为 A 至 E（Table 4）。
• 定量复现限于 CatchBench 0.1.2 离线 PRE 板的 1,187 个配置、六个来源；实践框摘录 flag_all 与 owasp_asi_combined 的 F1，并称在新的 Python 3.12 环境中逐字节复现。
• 标签过程按来源写明为 llm_judge、roster_relabel、declared_minus_used、synthetic_inject；论文未报告 llm_judge 的模型名称，也未报告重复次数。
• Table 2 将六条主张对照到 NIST、IETF、OWASP 草案的相关段落；第7节写明该方法未被测试。
• 正文用 CatchBench 区分 PRE、LIVE、POST；实践框报告的是 PRE 板分数。

作者给出把关于已部署智能体的主张写成可核查陈述的条件，而不是检测器或攻击方法。

• 要核的是主张本身：文档、采购和事件报告中的说法，例如有人批准每封对外邮件，日后可能被核查。第12条要求允许自动记录，但没有规定哪些记录能结案。
• 四要素与三种裁决：策略与版本、动作与期间、具名撰写者可取得的记录、判定规则，都在查记录前固定。一条已认证的范围内违规即可反驳；若违规是缺失，相应日志须对该期间完整。支持还要有覆盖证据，且每个范围内动作都符合。否则不可判定，并点名缺失记录。
• 三个条件：独立记录上的动作覆盖、绑定效果设定参数的人事先批准、与完整性分开的完备性。作者称在显式模型及各推论的假设下，缺少相应条件就不可能得到支持。签名与哈希链核验的是提交上来的条目。裁决针对已陈述的策略，不由此判定法律合规或责任。
• 教学案例：记录是构造的，没有运行智能体。tx-23 只有界面确认，服务器日志在相关期间完整且没有覆盖授权，3月的 P-7 版本3主张被反驳。tx-19 在三份分别撰写的记录上符合该策略。仅配置、丢失日志或字段、签名日志比网关少一封邮件，裁决都是不可判定。人的意图和法律责任不可及。
• 一次分数复现：CatchBench 0.1.2 离线 PRE 板上，owasp_asi_combined 汇总 F1 为 0.654，flag_all 为 0.601。作者称前者按来源从 0.411 到 0.961，并在 mcp 与 sweagent 上低于该基线；这不说明规则会在新部署中发现过度授权。
• 作者给出的用法：发布前按四要素改写主张，并把后果性动作接到智能体不控制的组件；采购时追问撰写者，把“防篡改日志”读成还需第二撰写者的 C5；查记录前约定规则，把不可判定与丢失日志分开报告。作者还列出三项增补：版本化系统控制的字段、批准绑定到参数、为每类后果性动作指定第二撰写者。作者称本章不提出标准。