提案：用硬件「终局机制」约束 AI 助手设备操作权限

一份提交至 PCT（专利合作条约）的架构文件提出名为「Hardware Finality」的设计方案，主张把 AI 助手对设备的任何操作都纳入一道硬件级闸门，使 Apple Siri、Google Android AI 这类系统级助手与第三方 AI 智能体在执行不可逆动作时受到完全一致的验证。该文件假定监管机构已要求平台向第三方 AI 助手开放与第一方同等的执行权限，并据此讨论如何用硬件手段防止权限被滥用。

当前方案的结构性缺陷

文件指出，现有的权限控制——弹窗授权、entitlement 系统、OAuth scope、开发者政策以及类似「App Tracking Transparency」的提示——都建立在一个共同前提上：授予权限的软件层同时也负责描述、审计和撤销该权限。这意味着平台既是规则的制定者，又是规则的执行者。当涉及竞争性 AI 助手时，平台无法独立证明它真正给予了竞品同等权限，因为只有它自己能改规则。

• 缺陷一：权限授予与权限审计共用同一软件层，闭环不可信。
• 缺陷二：不可逆动作（支付、消息、文件导出、凭证释放、传感器采集、设备执行）一旦完成即无法回滚。
• 缺陷三：缺乏对第一方与第三方助手的统一硬件级裁判。

「候选动作 + 终局汇」架构

提案的核心是把「请求」与「执行」在硬件层彻底分开。

候选动作（Candidate Act）

无论请求来自哪个 App、Siri 扩展还是 AI 智能体，设备侧的任何动作都被视为处于「非生效态」的候选动作。要让其真正执行，必须由一个硬件隔离域——例如 Apple 的 Secure Enclave、ARM 的 TrustZone、Google Titan M 或 StrongBox——独立校验一组固定谓词：

• 应用身份与声明目的
• 资源范围与目标位置
• 运行时行为
• 凭证新鲜度（freshness）

只有在所有谓词通过后，硬件域才会发放一份作用域明确、单次有效、不可转让的能力凭证（capability），与该动作绑定。

终局汇（Finality Sink）

在动作即将生效的最后一刻，独立的「终局汇」再次核验该能力凭证。若身份、范围、目标或新鲜度任何一项发生漂移，动作即被拒绝，没有部分执行、没有静默回退，遵循「失败即关闭」（fail closed）原则。

• 操作系统只负责路由请求和传递能力对象，不能签发、扩展、重新解释或强制接受它。
• 最终权威位于操作系统之外，由硬件域持有。

对监管方与平台的意义

按该方案，第一方与第三方 AI 助手（Siri、Android AI 及其他智能体）将在完全相同的硬件谓词下被评估，监管方可获得可验证的「平等性」，不必再依赖平台自证。平台方则获得一份保证：包括自家助手在内的任何 AI 智能体，都无法获得不受控制的执行权限，因为「请求」永远不等于「生效」。

文件称这一架构可以同时满足「监管互通」与「真实安全」两个目标。值得注意的是，该方案目前仅为提交至 PCT 的提案文档，并未披露明确的专利申请人或背后机构，也尚未有公开的标准化进展或厂商表态，距离落地仍有相当距离。