借鉴 HTTPS 思路，研究者提出 AI「执行时治理」概念框架
一篇概念性论文提出 AI 执行时治理框架，借鉴 HTTPS 协议思路，把计算、授权与生效三者分离，要求 AI 操作在产生…
核心主张：计算不等于生效
一篇标注为 Version v1 的概念性论文提出「执行时 AI 治理（execution-time AI governance）」框架，主张 AI 系统的计算行为不应自动获得产生外部后果的权限。该论文于 Hacker News AI 板块发布，核心类比来自 HTTPS：HTTPS 并不让网络、服务器或用户天然可信，而是通过协议层机制，要求受保护通信在进行前满足机器可验证的属性（身份、完整性、密码学状态等）。作者认为，AI 治理也应引入类似的协议级约束，把「是否被信任」与「此次具体行为是否可生效」区分开。
三层分离：计算、授权、生效
框架引入了关键架构区分：COMPUTATION ≠ AUTHORITY ≠ EFFECTUATION。AI 系统可以被允许推理、计算、生成、排序、推荐或提出某个操作，但并不自动拥有让该操作生效的授权。一个待生效的操作应首先作为「Candidate Act（候选行为）」存在，承载此次后果的关键属性，包括动作类型、目的地、资源、目的、用户或系统授权、模型或运行时身份、适用策略、时间有效性、安全 epoch、撤销状态、司法管辖区、操作范围等。该候选行为随后进入「Non-Effective State（非生效态）」，等待相关治理条件被评估。
这一分离的意义在于：把「AI 产生了一个动作」与「系统授权该动作生效」显式区分开来。当所需条件满足时，受保护的验证可生成一个与该具体行为和上下文严格绑定的「Scoped Execution Authority（限定范围的执行授权）」。
Finality Sink：在外部效应发生前再校验一次
框架中提出「Execution-Finality Boundary（执行终局边界）」或「Finality Sink」概念。它是一类独立的校验点，出现在提议的操作首次变得对外有效的瞬间。可参考的边界示例包括：
- 网络出站边界：数据传输前
- 支付生效边界：资金划转前
- 文件导出边界：受保护信息离开所属域前
- API 或工具调用边界：外部服务被调用前
- 软件更新边界：代码变为可操作前
- 设备控制边界：物理行为发生前
- 射频发射边界：辐射发生前
在这些边界上，系统需独立校验此前签发的限定执行授权是否仍然有效。
与既有治理层的关系
论文并未否定既有的治理机制，包括部署前评估、模型测试与红队、组织策略、访问控制、人工监督、日志与监控、风险管理、审计、事件报告和事后问责等。论文认为这些机制仍然必要，但它们主要回答的是「系统是否应被信任」「组织是否遵循了程序」「事后发生了什么」，并未精确控制「AI 生成计算」过渡到「外部生效后果」这一技术转换点。执行时模型引入的是在转换点之上、可机器强制的前置条件层。
现状与局限
目前该论文以概念框架形式呈现，文中提供了从「人类/AI/智能体生成候选行为」到「受保护验证」再到「限定执行授权」的流程示意图，并给出了典型失败路径（deny / defer / constrain / escalate 等处理方向）。论文未提供基准测试、实现代码或实证数据，也未给出具体的协议规范或参考实现，定位更接近治理架构层面的提案，而非可立即部署的工程方案。对于关注 AI agent 安全、工具调用治理与外部效应控制的研究者和政策制定者而言，可作为思路参考。