Havenlon｜AI 时代的执行安全语言体系（四六）：执行前与执行后

Working Draft · AI Era Execution Security LanguageThis 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 时代执行安全的共同语言。 本文中的术语与定义代表当前工作草案 将随着理论研究、工程实践和社区讨论持续修订28. Final Revalidation最终重新验证一句话定义最终重新验证是在动作进入不可逆执行前对 Intent、审批、Policy、状态、上下文、载荷和链路进行最后一次独立检查。严格定义Final Revalidation 必须回答Intent 是否仍然有效IntentHash 是否一致Approval 是否仍在有效期Governance State 是否变化Policy 是否仍然新鲜当前额度是否仍然充足Payload 是否与审批内容一致对象和参数是否改变Execution Slot 是否匹配Key Slot 是否匹配Last Step Hash 是否最新Chain Digest 是否有效请求是否重放设备是否处于安全状态。它不能只复用历史Allow状态。上位概念Pre-Execution Control执行边界下位概念Intent 重新验证Policy 重新验证状态重新验证载荷重新验证链路重新验证相关概念TOCTOUConfirmationFinal Signing PayloadIndependent Final VetoFail-Secure权力边界即使所有上游阶段都已通过最终重新验证仍可拒绝执行。约束机制本地状态当前计数器IntentHashPolicy HashGovernance HashFinal Signing Payload断链拒绝异常进入 Safe Mode。结果目标消除从审批、Policy 判断和确认到真实执行之间的最后缝隙。在 Havenlon 中Security Domain 在使用密钥或触发 Executor 前完成最终字段和链路验证。29. Pre-Execution Control执行前控制一句话定义执行前控制是在真实状态变化发生之前对动作进行限制、验证、缩小、延迟或拒绝的控制体系。严格定义执行前控制包括Intent 结构化身份与授权ApprovalPolicyGovernanceArbitration限额限频Context BindingFinal RevalidationIndependent Final VetoSafe Mode。执行前控制与传统监控的区别是它可以阻止动作发生而不仅是在动作发生后报警。上位概念Execution Control Layer执行安全下位概念身份控制Policy 控制治理控制仲裁控制物理控制最终否决相关概念Post-Execution ProofExecution BoundaryFinal RevalidationBlast RadiusFail-Secure权力边界执行前控制不能完全依赖被保护的应用或 SaaS否则失陷后可能被一并绕过。约束机制独立边界多源约束本地状态硬件隔离默认拒绝受控降级。结果目标在不可逆结果发生之前保留真实、不可轻易绕过的拒绝机会。在 Havenlon 中Arbiter、Security Domain、本地 Policy 和物理约束共同形成执行前控制。30. Post-Execution Proof执行后证明一句话定义执行后证明是在动作发生后生成并保存能够验证 Intent、提交、执行结果和证据连续性的证明。严格定义执行后证明至少应回答执行了哪个 Intent使用了哪个 Commit由哪个设备执行使用哪个 Executor使用哪个 Key Slot作用于哪个对象最终参数是什么外部回执是什么执行是否成功失败发生在哪一步证据链是否连续结果是否与原 Intent 一致。Post-Execution Proof 不能阻止已经发生的动作但它可以支持审计发现漂移防止事实被重写支持恢复识别重复执行计算真实灾难半径。上位概念Execution Proof LayerEvidence下位概念成功执行证明失败执行证明拒绝证明中断证明回执证明治理执行证明相关概念ReceiptDevice-Signed CommitExecution EvidenceResult HashEvidence Chain容易混淆的概念执行后证明不能替代执行前控制。记录灾难如何发生不等于阻止灾难发生。真正完整的系统需要Pre-Execution Control Post-Execution Proof约束机制设备签名Result HashReceipt BindingEvidence Store哈希链多副本归档单调计数器失败同样留证。结果目标让每一次执行、拒绝、中断和失败都有可验证事实而不是只留下应用日志。在 Havenlon 中设备提交事实、Executor 结果、外部 Receipt、Result Hash 和 Evidence Store 共同形成执行后证明。执行链总图Intent ↓ Proposal提议 ↓ Authorization资格与范围检查 ↓ Approval治理同意 ↓ Policy Decision策略判断 ↓ Arbitration仲裁收敛 ↓ Confirmation最终确认 ↓ Commitment提交 ↓ Execution真实执行 ↓ Receipt外部回执 ↓ Post-Execution Proof执行后证明对应 Havenlon 协议阶段Propose ↓ 审批、Policy 与治理协同 ↓ Confirm ↓ Final Revalidation ↓ Device-Signed Commit ↓ Execution ↓ Receipt ↓ Evidence执行路径、执行链与执行流程的区别Execution Flow执行流程 回答系统设计上规定应该怎么走 ​ Execution Path执行路径 回答这一次请求实际上经过了哪里 ​ Execution Chain执行链 回答这些实际步骤如何被顺序、因果和密码学关系连接起来一个系统可能流程设计正确实际路径绕过关键边界链路又无法证明路径变化。因此三者必须同时存在。提议、确认、提交与执行的区别Proposal 回答有人希望发生什么 ​ Confirmation 回答现在准备提交的内容是否仍然等于原 Intent ​ Commitment 回答系统是否已经形成确定、可验证的执行提交 ​ Execution 回答真实状态是否已经发生变化 ​ Receipt 回答外部系统返回了什么结果 ​ Proof 回答如何证明整个过程与结果它们不能压缩成一个approvedtrue。Havenlon 双阶提交的信任结构第一阶Propose │ ├── 创建 Intent ├── 生成 IntentHash ├── 发起审批 ├── 获取 Policy └── 形成候选状态 ​ 不同信任路径 ​ 第二阶Confirm Device-Signed Commit │ ├── 重新验证当前状态 ├── 构建 Final Signing Payload ├── 验证 Last Step Hash ├── 验证 Chain Digest ├── 验证 Key Slot / Execution Slot └── 设备签名 Commit核心不是名称中有几个步骤而是初始请求创建权不能自动继承为最终提交权。最终签名载荷关系结构Final Signing Payload │ ├── Intent 关系 │ └── IntentHash │ ├── 执行链关系 │ ├── Last Step Hash │ └── Chain Digest │ ├── 环境关系 │ └── chain_id │ ├── 对象与参数 │ ├── to │ ├── value │ └── currency_id │ ├── 执行能力 │ ├── key_slot_id │ └── exec_slot_id │ └── 权威来源 ├── 治理或仲裁签名 └── 设备签名执行链的常见破坏方式跳过 Approval 使用过期 Authorization 复用旧 Policy Decision 替换 Confirm 中的参数 跳过 Final Revalidation 使用另一条链的 Approval 重放旧 Device-Signed Commit 更换 Key Slot 更换 Execution Slot 使用恢复路径绕过 Arbiter 删除失败步骤 伪造 Receipt 把 SaaS 状态当作设备提交事实对应约束包括IntentHash Step Hash Previous Step Hash Last Step Hash Chain Digest Context Binding Payload Binding Chain Binding Final Revalidation Device-Signed Commit Evidence Store执行链与提交机制评审问题评估一套执行系统时至少应回答一次执行的正式起点是什么Proposal 是否绑定结构化 IntentProposal 能否直接到达 ExecutorAuthorization 与具体 Intent 是否绑定Approval 是否绑定对象、参数和有效期Approval 是否会被直接解释成执行命令Arbitration 是否聚合所有适用 PolicyArbiter 与 Executor 是否属于独立职责Confirmation 与 Approval 有什么区别Confirm 是否通过独立于 Propose 的路径完成关键参数在 Propose 与 Confirm 之间变化时如何处理系统是否存在明确 Commitment 状态谁有权声称 Commit 已经完成SaaS 数据库状态能否代替设备 CommitDevice-Signed Commit 覆盖哪些字段Final Signing Payload 是否覆盖完整语义最终载荷是否包含 IntentHash是否包含链、目标、金额和币种是否绑定 Key Slot 与 Execution Slot每个关键步骤是否拥有 Step Hash当前步骤是否引用 Previous Step Hash最终执行是否验证 Last Step Hash是否存在 Chain Digest另一条执行链的 Approval 能否被拼接进来执行路径变化是否会被发现重试是否会重复执行Commit 是否具有幂等性和防重放Safe Interruption 的提交边界在哪里Receipt 是否绑定具体 CommitReceipt 是否被错误当成完整执行证据外部执行失败是否同样留下证据Executor 能否修改最终载荷Key Slot 能否被跨场景复用Execution Slot 是否限制对象和用途Final Revalidation 是否重新读取当前状态执行前控制是否能够真正拒绝执行后证明是否独立于应用日志证据链是否记录拒绝、中断和恢复是否存在不经过执行链的管理员路径未完成 Device-Signed Commit 的请求是否可能被误认为已执行如果这些问题没有明确答案系统可能拥有一套执行流程却没有一条可验证、不可轻易替换的执行链。本章核心公理执行不是一个 API 调用而是一条从 Intent 到现实结果的连续链。执行流程规定应该怎么走执行路径记录实际怎么走执行链证明这些步骤如何连续发生。Proposal 只证明有人提出了动作不证明动作应当发生。Approval 只证明治理主体表达了同意不证明最终载荷仍然相同。Authorization 只证明主体有资格参与不证明具体动作安全。Arbitration 形成的是执行候选不是最终执行事实。Confirmation 的价值是证明当前准备提交的内容仍然等于之前被批准的 Intent。Commitment 必须拥有明确边界否则系统无法区分“准备执行”和“已经正式提交”。SaaS 可以记录 Commit但不能单方面创造 Device-Signed Commit。回执是外部系统的回答证据是整个执行链对事实的证明。双阶提交的价值不是把同一个按钮点两次而是让初始提议权无法自动继承为最终提交权。最终签名载荷必须绑定语义、链路、对象、参数、密钥和执行能力。Step Hash 证明一个步骤Previous Step Hash 证明它从哪里来Last Step Hash 证明最终执行依据哪个最新状态Chain Digest 证明整条链没有被裁剪和拼接。Key Slot 限制密钥能做什么Execution Slot 限制执行能力能用于什么场景。执行前控制负责阻止错误发生执行后证明负责证明最终发生了什么两者不能互相替代。无法证明执行属于当前完整执行链就不应该让执行发生。Havenlon 对执行链与提交机制的基本回应Havenlon 不允许一次请求从应用或 SaaS 直接变成真实执行。它要求从结构化 Intent 开始形成可验证 Proposal对主体资格进行 Authorization将 Approval 绑定具体 Intent聚合治理、Policy 和本地状态由 Arbiter 形成有限执行候选通过独立 Confirm 路径重新确认在执行前完成 Final Revalidation构建 Final Signing Payload将对象、金额、币种、链和环境明确绑定将 Key Slot 与 Execution Slot 明确绑定使用 Step Hash 记录关键步骤使用 Previous Step Hash 建立前序关系使用 Last Step Hash 锁定最新有效状态使用 Chain Digest 绑定完整执行链由本地设备形成 Device-Signed Commit只有完成设备提交的请求才有资格进入执行Executor 只能实施绑定后的具体动作Receipt 必须与 Commit 和 Intent 关联执行结果、拒绝、中断和失败都进入 Evidence Store重试、恢复和降级路径不得绕过相同控制当链路、状态或载荷无法验证时默认拒绝执行。最终原则是Havenlon 不只保护最终执行器。它保护的是一个 Intent 如何被提出、被批准、被仲裁、被确认、被提交、被执行并被证明的完整过程。只有当整条执行链仍然连续、当前、完整并且绑定同一个 Intent最终执行才应当发生。