Advanced AI Society Proof-of-Control 为智能体安全开辟新战线

Advanced AI Society 于 9 月 17 日发布 Proof-of-Control 供公众评审，尽管该草案的版本、范围和成熟度仍存在未解疑问。这项拟议标准要求 AI 智能体生成防篡改证据，证明每项受控操作均在其获授权的边界内执行。它也试图让智能体安全不再依赖对供应商私有日志的信任。

这一转变意义重大，因为智能体正在超越文本生成。它们可以调用工具、访问记录、修改软件、与外部服务通信，并发起交易。季度审计无法实时观察每一项决策，而由智能体运营方控制的日志，可能只能提供有限的独立保障。

Advanced AI Society 表示，超过 80 位安全领域负责人参与塑造了其方案。该组织正将这项工作纳入 Linux Foundation Decentralized Trust，为项目提供技术治理的中立场所。然而，中立治理并不意味着草案已经完善，加密证据也不能保证组织选择了正确的控制措施。

美国国会正从另一条路径接近同一问题。一项由两党议员提出的众议院法案将要求 NIST 制定智能体安全实践，涵盖持续验证、安全评估、清单管理和防篡改记录。自愿开放标准与政府支持的要求之间的交汇，构成了真正值得关注的故事。

Advanced AI Society Proof-of-Control 不只是成员身份公告

真正重要的变化，是发布了一项可供审查的智能体验证提案，而非围绕它的成员身份新闻。

Advanced AI Society 将其 9 月公告描述为加入 Linux Foundation 和 LF Decentralized Trust。然而，Linux Foundation 的记录显示，该组织已于 2026 年 4 月 21 日成为 LF Decentralized Trust 的准会员。因此，这则较新的公告将此前的成员身份进展，与 Proof-of-Control 及其相关实验室的公开亮相结合在了一起。

这一差异至关重要。成员身份让一个组织进入协作网络，但并不验证该组织发布的每一项主张或技术设计。真正具有影响力的行动，是将一项拟议验证标准带入基金会环境，让外部贡献者能够审查、质疑并扩展它。

4 月的成员记录将 Advanced AI Society 列为两家新增准会员之一。9 月的发布公告则将 Proof-of-Control 介绍为 LF Decentralized Trust 的一个实验室，并邀请公众提交意见。

Proof-of-Control 围绕一个直接的问题设计：独立方能否验证某个 AI 智能体始终在其被分配的控制范围内运行？控制措施可以阻止智能体未经批准转移资金、限制其可访问的客户记录，或限定其在任务期间可使用的工具。

该提案聚焦于操作边界，即智能体尝试调用工具或产生外部影响的节点。其架构在该边界设置独立的拦截网关。网关评估拟执行的操作，拦截超出既定策略的操作，并生成有关该决策的证据。

这一设计比有关负责任 AI 的常规承诺更具体。它说明了执行发生在何处、应生成哪些证据，以及另一方如何验证这些证据。Advanced AI Society 还确定了六个验证领域：溯源、隐私、可移植性、授权、身份和安全。

该框架的核心理念是：当同一运营方同时控制执行与记录时，智能体的运行时日志仍只是一项声明。受损系统可能遗漏某项操作、改写记录，或绕过日志记录。因此，有价值的验证机制必须能够暴露篡改，并说明其证据所依赖的假设。

该项目提出了多个保障层级。较低层级依赖运营方声明或审计人员的访问权限。较高层级则寻求可独立验证的记录，或在缺少相应证据时阻止受控操作的执行闸门。

这在观察操作与约束操作之间形成了有意义的区别。防篡改记录可帮助调查人员在事件发生后确定已记录的内容。正确实现的执行闸门则可以在授权条件未满足时阻止涵盖范围内的操作。

Proof-of-Control 并不声称能够判断底层模型是否安全、准确或对齐。它也不会判断一家公司是否授予了智能体过多权限。它试图确立的是：在明确的范围内，已声明的控制措施是否约束了相关操作。

这一更狭窄的目标是一项优势，因为它为实施者提供了可测试的内容。它同时也是该项目最大的局限性来源。证明智能体遵循了薄弱策略的证据，只能证明其遵循了这项薄弱策略。

国会正将智能体验证转变为采购问题

智能体安全正从一项技术偏好，转向与受监管买家及联邦政府开展业务的条件。

拟议中的 Stop Rogue AI Act 将要求美国国家标准与技术研究院发布有关安全部署智能体的标准、指南和最佳实践。根据报道中的法案细节，相关工作将涵盖持续智能体清单、安全评估、防篡改日志和智能体操作验证。

该提案来自新泽西州民主党众议员 Josh Gottheimer 和纽约州共和党众议员 Mike Lawler。大多数组织将自愿采用由此形成的 NIST 实践。但竞逐新联邦合同的承包商将面临更大的合规压力。

这种机制比笼统的监管声明更重要。采购要求能够影响技术市场，同时不必对每家私营组织强加单一的强制架构。供应商往往会将面向政府的控制措施应用到整个产品线，因为维护彼此分离的安全体系会增加成本和复杂性。

在众议院提案出现之前，NIST 已经在这一领域开展工作。今年 2 月，该机构宣布了一项智能体标准计划，涵盖互操作性、身份、授权和安全。它还向部署方、开发者、研究人员和基础设施提供商征求意见。

它与 Proof-of-Control 的重合之处很明显。两项工作都聚焦于持续身份、明确权限、可观察操作，以及能够在智能体自身叙述之外存续的证据。两者也都认识到，智能体通过工具、凭证和服务接口与现有系统交互。

但二者的角色仍然不同。NIST 通过联邦标准流程制定指导，并可影响采购预期。Advanced AI Society 则通过开放社区提出一项面向实施的标准，并希望围绕它发展独立验证工具。

众议院提案会给三类群体带来压力。智能体供应商必须说明其系统如何识别每个智能体并约束其权限。企业部署方必须维护清单，并确定哪些系统能够执行具有重大影响的操作。安全服务提供商则必须生成外部评估人员可以审查的证据。

联邦承包商面临的潜在驱动作用最为明确。一家供应商在普通商业市场销售时，可能将开放验证视为可选项。但当大型买家要求提供机器可读清单、持续记录和可独立测试的控制措施时，这种立场就更难维持。

保险公司和审计机构构成了另一种压力来源。评估一个能够发起付款的智能体时，保险公司需要的不仅是一份策略文件。它需要能够显示哪一身份采取了行动、存在何种权限、哪项控制评估了请求，以及所得记录是否保持完整的证据。

同样的问题也出现在医疗领域。智能体可能检索病历、总结病例或准备医嘱。医院必须区分确认记录完整性与确认临床决策恰当性。Proof-of-Control 解决的是前者，而治理和专业审查仍决定后者。

开发者将在集成节点感受到这种变化。安全不能再止于保护模型端点。团队必须考虑凭证、工具权限、委派链、数据访问，以及智能体可触及的每项服务中的副作用。

这正是智能体安全正成为采购议题而非功能比较的原因。买家需要能够跨供应商保持意义的证据。专有仪表板有助于运营者管理自身系统，但不会自动为审计人员、保险公司、监管机构和客户建立共同的保障语言。

开放验证挑战供应商控制的日志

核心竞争在于可移植的第三方证据，与仍由被评估供应商控制的安全记录之间的较量。

传统企业日志并非毫无用处。它们支持事件响应、监控、调试和合规。问题在于，日志的价值取决于谁生成它、它是否捕获了每一条相关路径，以及是否有人能够在事后修改它。

AI 智能体使这些问题更加复杂。其操作可能取决于不断变化的上下文、检索到的数据、模型输出、工具响应和委派权限。一个系统可以记录最终的工具调用，却没有保留足够上下文来证明为何该调用获得授权。

Proof-of-Control 提议在执行期间生成证据，而不是在事件发生后重建证据。它还寻求可移植的记录，使不同参与方无需获得运营方整个环境的特权访问权限，也能解读这些记录。

该项目发布的标准概览将证据描述为二元的、同时产生的、防篡改的，并且对剩余信任假设保持透明。二元意味着受控操作要么处于已声明的边界内，要么不在其中。它并不意味着更广泛的结果一定正确。

以一个获授权在公司设定限额以下下订单的采购智能体为例。验证层可以记录智能体身份、委派权限、经评估的金额以及策略结果。它也可以拒绝超过该限额的订单。

然而，这些证据不能证明该采购确有必要、供应商信誉良好，或价格具有合理价值。这些是独立的商业判断。验证显示的是一项明确控制是否得到遵守，而不是组织是否设计了合理的控制措施。

这种区分至关重要，因为安全语言往往会将几种不同的主张混为一谈。供应商可能会因为某个 agent 具备权限、审计日志和人工审批选项，就将其描述为安全。这些功能并不能证明不存在绕过路径，也不能证明每一项具有重要影响的操作都会经过控制点。

Proof-of-Control 提出的操作拦截网关试图解决这一问题。它位于 agent 进程之外，并对受控工具调用进行中介。要使该架构生效，agent 不得拥有任何能够绕过网关的替代凭证或网络路径。

这种无绕过条件很难实现。现代软件环境中存在服务账号、缓存凭证、后台进程、插件和直连网络路径。验证者必须测试周边系统，而不能仅检查网关的输出。

该提案也带来了隐私方面的取舍。验证证据必须提供足够信息以支持有意义的结论，同时又不能暴露提示词、个人记录、模型权重或专有业务数据。密码学主张可以减少信息披露，但其效用取决于底层测量和实现的质量。

可移植性带来了另一项挑战。两家供应商可能采用不同的策略语言、身份系统、运行时和日志格式。共享证据模式可以对其中一部分差异进行标准化，但无法消除原始控制措施在定义或执行方式上的所有差异。

开放治理为应对这种碎片化提供了可信的路径。公开规范、测试向量、参考代码和已记录的威胁模型，为买方和研究人员提供了可供审查的材料。由供应商控制的保障计划可能披露得更少，也可能在未经外部共识的情况下发生变化。

Linux Foundation 为这项工作提供了制度基础设施。它可以支持社区治理、知识产权规则、贡献流程和长期托管。但这并不意味着该设计已经解决了 agent 约束或企业采用的问题。

这一界限应当保持清晰。由基金会托管，证明的是项目拥有协作场所；它并不能证明每项部署都符合规范、每份证明都完整，或客户会接受由此产生的记录。

草案本身已说明独立审查为何重要

Proof-of-Control 的早期不一致之处，揭示了发布一项标准与确立一项标准之间的差别。

Advanced AI Society 在 9 月的公告中称此次发布为“v1.0 工作草案”，并表示公开征求意见将持续至 2026 年 10 月 30 日。其更详细的标准页面则将该文件标识为“工作草案 v0.1”，并列出 10 月 7 日为意见截止日期。

Linux Foundation 的活动说明同样将其称为 Proof-of-Control v0.1。这些差异可能反映了发布内容未同步、发布计划调整，或相关工件采用了不同标签。无论原因为何，版本和截止日期的模糊性都会实质影响决定审查内容的贡献者。

一项标准依赖稳定的标识符。实施者需要知道适用的是哪些规范性要求、测试向量是否匹配当前文本，以及破坏性变更何时发生。审计人员无法依据不断变化的标签评估符合性。

这并不否定项目目标。它恰恰说明了中立代码库、发布标签、变更记录和公开问题跟踪为何重要。开放标准必须先让自身的来源可验证，才能要求 agent 供应商做到同样的事。

计划中的公开说明会定于 9 月 23 日举行。届时将汇集 Linux Foundation 领导者、Advanced AI Society 代表、安全领域投资者、身份服务提供商、保险机构以及 Agentic AI Foundation。

该活动可以澄清治理问题，但仅靠公开讨论无法消除技术不确定性。贡献者需要规范性规范、明确的威胁模型、符合性测试和可复现的实现。他们还需要一套流程，用于决定哪些机制满足每项要求。

该项目称其代码库包含参考实现、机器可读的主张定义、攻击场景和签名测试向量。它将该实现描述为参考实现，而非生产级产品。这一提醒很重要，因为早期代码可以证明可行性，却未必满足运营安全要求。

参考网关可以展示如何评估策略并生成签名证据。生产级网关还必须经受凭证盗窃、竞态条件、重放尝试、不完整遥测、密钥泄露、基础设施故障和恶意操作人员的考验。

完整性带来了另一项棘手问题。防篡改记录可以表明已记录条目未被修改，但它们本身无法证明所有相关操作都已进入记录。拥有未受监控路径的 agent 可能在记录之外采取行动，而可见的证据链仍保持内部一致。

Advanced AI Society 提出的更高等级通过执行门控来应对这一问题。在该模型下，受覆盖的操作必须经过控制并生成证据后才能发生。剩下的问题是，是否每一项具有重要影响的操作都确实被覆盖。

外部影响也让情况更加复杂。网关或许能够验证 agent 已发出获授权的付款请求，但无法自动证明银行完全按预期完成了该笔付款结算。保障机制必须将 agent 侧的证据与外部系统的回执关联起来。

身份链带来类似风险。一个 agent 可能将工作委派给另一个 agent，后者随后调用第三方服务。每次交接都可能改变权限、上下文或数据暴露范围。可信标准必须保留归属关系，而不能假定单一身份令牌足以解释整条链路。

控制质量仍是最大的概念性局限。Proof-of-Control 明确避免评判所选规则是否明智。这种区分让技术符合性更易于管理，但组织可能会将符合性宣传为更广泛的安全证据。

买方应当避免这种捷径。经过验证的 agent 可以忠实遵循不安全的策略，也可能基于错误的模型推理产生获授权的操作。运行时验证是对测试、人工监督、风险分析和事件响应的补充，而不是替代。

因此，该项目最负责任的主张是狭义的：它寻求改善有关已声明控制措施是否约束了受覆盖操作的证据。关于完整 agent 安全性、监管合规性或责任已被消除的主张，都超出了这些证据能够证明的范围。

该标准必须证明其能在真实 Agent 技术栈中发挥作用

Proof-of-Control 能否在不制造又一个孤立合规层的前提下，跨托管模型、本地系统和多供应商工作流运行，将决定其能否被采用。

企业 agent 技术栈很少来自单一供应商。一家公司可能使用托管模型、内部编排框架、第三方身份服务提供商、云数据库以及多家供应商提供的专业工具。每一层提供的控制措施和遥测数据各不相同。

Proof-of-Control 宣称，其操作边界模型可适用于开放和封闭配置。模型提供商不一定需要披露其权重或训练数据。验证层则观察编排系统调用外部能力时的受控操作。

这种方法更适合能够控制自身 agent 循环的组织。它们可以插入网关、限制凭证，并将工具调用路由至定义明确的边界。托管 agent 服务则更具挑战，因为供应商控制编排环境，并决定披露哪些证据。

这种差异使架构成为采购标准。评估托管 agent 的客户必须询问：它是否输出可独立验证的证据，证据是否覆盖每一次相关工具调用，以及操作人员能否绕过已声明的路径。

财务团队提供了一个具体测试。假设某个 agent 负责准备发票、更新会计记录并发起银行转账。验证系统必须区分读取总账、提议付款、获得批准和提交最终指令。

每项操作都需要身份、授权来源、适用策略、时间参考和结果。系统必须跨工具保留这一链条，同时不能将账户数据泄露到公开验证记录中。它还必须处理执行期间审批被撤销或策略发生变化的情况。

软件工程 agent 则带来不同的测试。它可以检查私有代码、修改文件、执行测试并请求部署。Proof-of-Control 或许能够验证 agent 访问了哪个代码库，以及部署是否需要指定审批。

该标准仍需考虑间接影响。通过授权闸门的代码，之后仍可能暴露数据或改变生产环境行为。运行时证据显示 agent 如何跨越边界，而软件审查和安全测试则评估它生成的工件。

医疗保健场景考验隐私和专业授权。某个 agent 可能在临床医生授权下调取患者记录，并发送医嘱草稿供审批。证据必须证明访问始终处于授权范围内，同时不能披露底层医疗信息。

这些场景需要的不只是通用签名日志。它们需要针对身份、权限、策略评估、证据保留和故障行为建立共同语义。一份被不同验证者以不同方式解读的记录，无法实现互操作性。

因此，符合性测试将决定该项目的可信度。独立团队应能够针对不同实现运行同一套测试，并得到一致结果。负向测试应展示：当记录遭到篡改、操作绕过网关或授权到期时，系统会如何失败。

性能同样重要。agent 往往会在一项任务中进行多次工具调用。持续生成证据会增加签名、存储、验证和策略评估工作。企业需要来自代表性部署的延迟和运营数据。

Proof-of-Control 的公开材料强调机器速度验证，因为人工审查无法匹配 agent 的执行速度。这一前提是合理的，但自动化同样能够以机器速度重复执行有缺陷的规则。因此，对控制措施的变更必须像代码变更一样受到严格治理。

运营所有权是另一个悬而未决的问题。安全团队可能定义基线策略，应用团队可能集成网关，身份团队可能管理委派，而合规团队可能保留证据。假定存在统一责任人的标准，将难以在大型组织内部落地。

该项目即使不成为唯一的 agent 安全标准，仍可能取得成功。其证据模型可以为 NIST 指导意见、供应商 API、保险问卷或采购模板提供参考。即使实现方式不同，共享概念也能影响市场。

更大的风险是仪式化采用。供应商可能声称符合标准，但仅覆盖部分选定操作；或者使用开放验证的话语，却不提供独立测试。清晰的符合性等级和可供机器检查的要求可以减少这种行为。

三个信号将决定开放验证能否成为基础设施

接下来的三项测试是规范一致性、独立实现和监管采用。

第一个信号是 Advanced AI Society 是否会解决草案在版本与评论截止日期上的冲突。公开发布标签应将规范性文本、模式、测试向量、参考实现和变更历史关联起来。

这一步将强化该项目的核心论点：可验证的溯源应从标准本身开始。如果这些工件仍存在不一致的标注，企业将犹豫是否围绕它们建立控制措施或合同条款。

第二个信号是独立实现。创始组织的参考代码可以证明其作者实现了他们所描述的内容。但还需要独立团队证明，该规范传达了足够的细节，能够产生兼容的证据和验证结果。

有价值的实现报告应记录失败与成功。报告应说明延迟、集成负担、不受支持的智能体框架、隐私限制，以及测试中发现的任何绕过路径。有关生产环境的主张需要来自作者无法直接控制的环境的证据。

第三个信号是 NIST 和国会如何界定智能体验证要求。如果联邦指导意见要求持续盘点、防篡改记录、可归属的身份以及可独立测试的控制措施，Proof-of-Control 将满足一项明确的采购需求。

如果联邦承包商或受监管买方要求提供可移植的证据，而非供应商截图，该项目将获得进一步动力。这一要求将奖励互操作性，并为多个验证服务提供商创造空间。

相反的结果将削弱共享生态系统的理由。各机构可能接受传统日志和定期审计，或者国会可能无法推进相关立法。届时，企业可能将开放验证视为一项可选的安全实验。

华盛顿围绕 AI 的更广泛辩论仍未尘埃落定。国会领导人一方面讨论设置护栏，另一方面也强调轻度监管方式以及与中国的竞争。这种张力使有针对性的技术标准比一部全面的 AI 法律更具实现可能。

必须明确区分立法与生效。众议院的智能体安全提案并非既定的联邦政策。NIST 现有的倡议正在推进，但其最终指导意见及市场影响仍在发展中。

因此，Advanced AI Society 拥有一个影响新兴术语体系的短暂窗口。如果它能在采购规则固化前证明这些控制措施具备可实施性，其定义可能会影响买方如何描述运行时保障。

开发者应关注常见智能体框架是否会新增对可移植证据的原生支持。企业买方应要求供应商识别每一项受控操作，以及任何可绕过执行机制的路径。安全团队应比较证据完整性与证据完备性。

知识工作者同样与此息息相关。代表个人操作其电子邮件、文档、日历或金融账户的智能体，可能在用户审阅之前就造成后果。用户需要一份易于理解的记录，说明他们授予了哪些权限，以及智能体如何使用这些权限。

Advanced AI Society 的 Proof-of-Control 倡议为这一需求提供了严肃的回应，但它仍处于早期草案阶段。它的价值将来自经过测试的互操作性、精确的范围界定，以及能够经受创建者以外各方审查的证据。

正确的下一步不是假设该标准已经解决了智能体安全问题。买方和构建者应审阅草案、测试“不可绕过”要求，并在公开评审期间提交具体的实现失败案例。只有当独立参与者能够复现其主张并识别其局限时，开放验证才能成为基础设施。