Working Draft · AI Era Execution Security Language

This article is part of the Havenlon Execution Security Language project. The terminology and definitions presented here describe the current working draft and may evolve as the discipline matures.

AI 时代执行安全语言体系（工作草案）

本系列旨在建立 AI 时代执行安全的共同语言。 本文中的术语与定义代表当前工作草案， 将随着理论研究、工程实践和社区讨论持续修订

4. Proposal｜提议

一句话定义

提议，是一个主体将结构化 Intent 正式提交给治理和执行控制系统的行为或结果。

严格定义

Proposal 通常包含：

• Intent；

• Intent Origin；

• Proposer 身份；

• 对象；

• 参数；

• 作用域；

• 时间；

• 风险级别；

• 所需执行器；

• IntentHash；

• 发起证据。

Proposal 表示请求已进入系统，但不表示：

• 已审批；

• 已授权；

• 已通过 Policy；

• 已经仲裁；

• 已经提交；

• 已经执行。

上位概念

• 执行阶段

• 提议权

下位概念

• 执行提议

• 治理提议

• Agent 提议

• 自动化提议

相关概念

• Propose

• Intent

• Proposer

• Right to Propose

• Proposal Evidence

权力边界

提议者只能将 Intent 放入治理链，不能决定后续步骤必然通过。

约束机制

• Intent 结构化；

• 来源验证；

• 作用域；

• 防重放；

• IntentHash；

• 提议签名；

• 提议有效期。

结果目标

让每次高风险执行都从一个明确、可追溯的结构化请求开始。

在 Havenlon 中

应用、Pass Key、用户或 AI Agent 提交 Proposal，但 Proposal 不能直达 Security Domain。

5. Approval｜审批

一句话定义

审批，是合格治理主体对具体 Proposal 表达同意、拒绝或附条件同意的行为与结果。

严格定义

Approval 必须绑定：

• Proposal；

• IntentHash；

• 审批者；

• 角色；

• 审批时间；

• 审批有效期；

• 可接受范围；

• 当前治理状态；

• 审批意见；

• 是否允许一次或多次使用。

审批只表示治理主体的判断，不表示系统已经形成最终执行许可。

上位概念

• 治理阶段

• 审批权

下位概念

• 同意

• 拒绝

• 条件审批

• 阈值审批

• 治理审批

相关概念

• Approval Policy

• Approver

• Approval ≠ Execution

• Independent Consent

• Governance Threshold

权力边界

审批者不能：

• 修改 Proposal 后沿用原审批；

• 让审批自动成为执行命令；

• 绕过 Arbiter；

• 直接控制执行密钥。

约束机制

• 内容绑定；

• 独立身份；

• 独立设备；

• 有效期；

• 单次使用；

• 防诱导；

• 审批证据。

结果目标

形成可验证的治理同意，同时保持审批与执行分离。

在 Havenlon 中

Approval 进入 Governance State 与 Arbitration，但不能直接触发 Device-Signed Commit。

6. Authorization｜授权

一句话定义

授权，是系统确认某个主体在明确范围、时间和场景内，有资格参与某项操作的判断。

严格定义

Authorization 通常回答：

• 谁可以提议；

• 谁可以审批；

• 谁可以查看；

• 谁可以调用某类接口；

• 谁可以使用某个角色；

• 谁可以操作某些对象。

授权是主体资格与范围判断，不等于一次具体 Intent 已经安全。

同一主体可能：

• 有权提议，但无权审批；

• 有权审批低风险动作，但无权审批治理变更；

• 有权操作某个钱包，但无权操作其他钱包；

• 有权在某时间窗口操作，但授权已过期。

上位概念

• 权限判断

• 身份治理

下位概念

• 提议授权

• 审批授权

• 观察授权

• 执行器授权

• 治理授权

相关概念

• Authorization ≠ Safe Execution

• Identity Boundary

• Role

• Scope

• Policy Decision

权力边界

授权不能自动成为最终执行许可，也不能脱离具体 Intent 和当前状态长期复用。

约束机制

• 角色；

• 作用域；

• 有效期；

• 对象绑定；

• 状态绑定；

• 撤销；

• 最小权限。

结果目标

确保只有具备明确资格的主体参与相应阶段，同时不把资格误认为安全结果。

在 Havenlon 中

身份和角色系统判断主体是否有资格提议或审批，但最终执行仍需独立仲裁和约束。

7. Arbitration｜仲裁

一句话定义

仲裁，是将 Intent、授权、审批、Policy、治理状态和当前执行约束聚合并收敛为执行候选结果的过程。

严格定义

Arbitration 必须检查：

• Intent 完整性；

• Proposal 有效性；

• 身份与授权；

• Approval 数量和角色；

• Quorum 与 Threshold；

• Policy 有效性与新鲜度；

• 本地额度和频率；

• 当前设备状态；

• 路径和链路完整性；

• 是否存在拒绝条件；

• 是否需要 Safe Mode。

仲裁结果可以是：

• 允许进入确认阶段；

• 要求额外审批；

• 缩小执行范围；

• 延迟；

• 拒绝；

• 中断；

• 进入 Safe Mode。

上位概念

• 执行控制阶段

• 策略收敛

下位概念

• 治理仲裁

• Policy 仲裁

• 风险仲裁

• 本地仲裁

• 最终候选仲裁

相关概念

• Arbiter

• Policy Aggregation

• Policy Convergence

• Stricter-Wins

• Deny Dominance

权力边界

仲裁只形成有限候选结果，不能自行构造任意执行载荷或直接完成执行。

约束机制

• 独立信任域；

• 多源 Policy；

• 本地状态；

• 结构化输出；

• 仲裁签名；

• 与 Executor 分离。

结果目标

将多个有限判断收敛为一个仍需最终确认和验证的执行候选。

在 Havenlon 中

Arbiter Domain 负责仲裁，但 Security Domain 仍保留最终载荷校验和拒绝能力。

8. Confirmation｜确认

一句话定义

确认，是在最终提交前，对具体 Intent、载荷、状态和执行条件再次作出明确确认的阶段或结果。

严格定义

Confirmation 不是 Approval 的同义词。

Approval 主要表示治理同意。

Confirmation 主要表示：

当前准备提交的具体内容，仍然与之前的 Intent、审批和仲裁结果一致。

确认可能验证：

• IntentHash；

• 最终对象；

• 最终参数；

• 执行槽位；

• 密钥槽位；

• 当前治理状态；

• 当前 Policy 状态；

• 有效期；

• 防重放状态；

• 设备状态。

上位概念

• 提交前阶段

• 最终重新验证

下位概念

• 人工确认

• 设备确认

• 仲裁确认

• 本地确认

• 协议确认

相关概念

• Confirm

• Final Revalidation

• Intent Confirmation

• Two-Phase Commit

• Final Signing Payload

权力边界

确认不能自动修改 Intent，也不能在内容变化后继续沿用原审批。

约束机制

• 最终摘要；

• IntentHash；

• 状态版本；

• 有效期；

• 一次性挑战；

• mTLS；

• 设备签名。

结果目标

在进入不可逆提交前，消除审批到执行之间的最后状态差异。

在 Havenlon 中

Confirm 通过不同于初始 Proposal 的受控通信与本地状态完成，防止只依赖一次上游提交。

9. Commitment｜提交

一句话定义

提交，是系统将已确认的执行候选转化为不可随意撤回、可进入真实执行的确定状态。

严格定义

Commitment 表示：

• Intent 已明确；

• 必要审批已完成；

• Policy 已仲裁；

• 最终载荷已绑定；

• 当前状态已重新验证；

• 请求被赋予唯一提交身份；

• 后续执行必须围绕该提交进行。

提交点必须清楚定义，因为它决定：

• 哪些状态仍可修改；

• 是否允许撤销；

• 是否允许重试；

• 如何防止重复执行；

• 哪些证据必须生成；

• 后续失败如何恢复。

上位概念

• 执行阶段

• 状态提交

下位概念

• 逻辑提交

• 设备提交

• 密码学提交

• 不可逆提交

• 条件提交

相关概念

• Commit

• Device-Signed Commit

• Two-Phase Commit

• Safe Interruption

• Atomic Commit

权力边界

提交不能由应用或 SaaS 单方面声称完成。

只有满足最终设备与链路条件的提交，才具有真实执行资格。

约束机制

• 唯一提交 ID；

• 设备签名；

• 单调计数器；

• Last Step Hash；

• Chain Digest；

• 防重放；

• 明确提交状态机。

结果目标

为“执行是否已经正式成立”提供明确、不可含糊的边界。

在 Havenlon 中

真正的提交以设备签名的 Commit 为事实来源，不以 SaaS 数据库中的committed=true为最终依据。

10. Execution｜执行

一句话定义

执行，是将已经提交并验证的动作转化为真实状态变化的阶段。

严格定义

执行可能包括：

• 使用密钥签名；

• 广播交易；

• 调用生产 API；

• 写入关键状态；

• 控制设备；

• 发布配置；

• 删除或导出数据；

• 修改治理状态。

执行必须严格使用已经绑定的：

• Intent；

• 对象；

• 参数；

• 执行槽位；

• 密钥槽位；

• 路径；

• 有效期；

• 仲裁结果。

上位概念

• 现实执行

• 执行阶段

下位概念

• 资产执行

• 运维执行

• 数据执行

• 治理执行

• 设备执行

相关概念

• Executor

• Execution Root

• Final Signing Payload

• Commitment

• Receipt

权力边界

执行器不能自行：

• 修改 Payload；

• 选择更宽松 Policy；

• 生成新 Intent；

• 改变执行对象；

• 重复执行已完成请求。

约束机制

• 固定协议；

• 执行槽位；

• 密钥槽位；

• 幂等性；

• 防重放；

• 结果绑定；

• 执行证据。

结果目标

保证执行阶段只实施已经被明确允许和提交的具体动作。

在 Havenlon 中

Security Domain 或具体 Executor 只接受符合 Final Signing Payload 和链路验证要求的动作。

11. Receipt｜回执

一句话定义

回执，是外部执行系统、网络或业务接口对提交动作返回的处理结果。

严格定义

Receipt 可能包含：

• 交易哈希；

• 外部请求 ID；

• 执行状态；

• 区块确认；

• API 状态码；

• 设备响应；

• 业务系统结果；

• 错误码；

• 完成时间。

回执回答：

外部系统声称发生了什么。

它不一定证明：

• 结果已经最终确认；

• 外部系统没有说谎；

• 执行符合原始 Intent；

• 回执属于当前执行链；

• 回执没有被替换。

上位概念

• 执行结果

• 外部响应

下位概念

• 网络回执

• 链上回执

• API 回执

• 设备回执

• 业务回执

相关概念

• Post-Execution Proof

• Execution Evidence

• Result Hash

• Chain Digest

• Finality

容易混淆的概念

Receipt 不等于 Evidence。

回执是外部系统的返回，证据是整个执行链对发生过程的可验证记录。

约束机制

• 回执与提交 ID 绑定；

• 结果哈希；

• 外部状态重新查询；

• 多次确认；

• 回执签名；

• 执行链关联。

结果目标

让外部执行结果能够被正确关联到具体 Intent 和 Commit。

在 Havenlon 中

广播结果、交易哈希或 Executor 返回值进入 Evidence Store，但不能单独替代设备签名提交事实。