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 时代执行安全的共同语言。 本文中的术语与定义代表当前工作草案 将随着理论研究、工程实践和社区讨论持续修订12. Propose提议阶段一句话定义Propose 是将结构化 Intent 通过初始受控通道提交给协同和治理系统的阶段。严格定义Propose 阶段主要完成Intent 结构化来源身份验证IntentHash 生成初始参数检查创建唯一请求获取初始 Policy启动审批记录提议证据。Propose 不意味着本地设备已经同意执行。上位概念Execution FlowProposal下位概念HTTPS ProposeAgent ProposeGovernance ProposeApplication Propose相关概念ConfirmCommitIntent OriginProposal EvidenceTwo-Phase Commit权力边界Propose 通道不能直达执行器也不能携带能够绕过后续仲裁的万能授权。约束机制身份认证TLSIntentHash请求 ID有效期防重放初始状态记录。结果目标建立执行链的可追溯起点而不是立即创建执行事实。在 Havenlon 中初始请求可通过 HTTPS 进入 Bletchley 或 Hub 协同流程但仍需后续 Confirm 与设备提交。13. Confirm确认阶段一句话定义Confirm 是通过独立于初始 Propose 的受控路径对审批、Policy、Intent 和当前状态进行再次确认的阶段。严格定义Confirm 的价值在于避免同一通道既创建请求又单方面声明请求可以执行。Confirm 通常应验证请求 IDIntentHashApprovalGovernance StatePolicy Hash当前额度当前时间当前设备防重放状态最终候选参数。确认通道应具有不同的身份、状态或传输约束。上位概念Execution FlowConfirmation下位概念gRPC ConfirmmTLS ConfirmDevice ConfirmLocal Confirm相关概念ProposeCommitFinal RevalidationTwo-Phase CommitContext Binding权力边界Confirm 不能静默接受与 Propose 不同的关键参数。如果关键内容变化必须触发 Intent Rebinding 或重新提议。约束机制mTLS双向身份IntentHash 比较状态版本Policy Hash一次性挑战超时本地重新验证。结果目标证明初始提议在当前状态下仍然成立并为设备提交建立最新候选状态。在 Havenlon 中Confirm 通过 gRPC mTLS 等独立协同路径完成本地设备不会仅凭 HTTPS Proposal 直接执行。14. Commit提交阶段一句话定义Commit 是本地设备在最终验证通过后对具体执行候选作出密码学确认并形成可执行事实的阶段。严格定义Commit 阶段应完成Final RevalidationFinal Signing Payload 构建执行槽位与密钥槽位验证Last Step Hash 验证Chain Digest 验证防重放计数器更新Device-Signed Commit证据记录进入实际执行或授权执行。Commit 是从“允许候选”进入“确定执行”的关键边界。上位概念Execution FlowCommitment下位概念Device CommitSigned CommitExecution CommitGovernance Commit相关概念ProposeConfirmDevice-Signed CommitFinal Signing PayloadPre-Execution Control权力边界Commit 不能由 SaaS 数据库状态代替也不能由应用自行伪造。约束机制设备签名独立计数器Final Signing PayloadLast Step HashChain DigestEvidence Store原子状态转换。结果目标为最终执行建立本地、可验证、不可轻易伪造的提交事实。在 Havenlon 中Commit 由设备侧形成SaaS 只能接收和归档结果不能单方面创造 Commit。15. Two-Phase Commit双阶提交术语说明Havenlon 中的 Two-Phase Commit 不是传统数据库事务协议中的“两阶段提交”。更准确的含义是一个执行请求必须通过两个相互区分的信任阶段完成确认才能进入设备签名提交。一句话定义双阶提交是将初始提议与最终确认提交分离并通过不同通道、状态和信任条件阻止单一路径独立造成执行的机制。严格定义Havenlon 的双阶提交可以概括为第一阶Propose创建 Intent形成 IntentHash发起协同完成审批和策略准备生成执行候选。第二阶Confirm → Device-Signed Commit通过独立受控路径重新确认验证当前状态构建最终载荷由本地设备签名 Commit进入真实执行。虽然协议中可以出现 Propose、Confirm、Commit 三个名称但安全结构上存在两个核心权力阶段提议和协同阶段 ≠ 最终确认与设备提交阶段上位概念提交机制执行权分离下位概念双路径确认双状态提交SaaS 与本地双阶提交网络与设备双阶提交相关概念ProposeConfirmDevice-Signed CommitCommunication and Decision SeparationFinal Revalidation容易混淆的概念双阶提交不等于同一个接口调用两次同一个 SaaS 写两个数据库状态两个人重复点击确认数据库协调者询问多个参与者是否准备好保证业务动作绝对原子。其安全价值来自两个阶段不完全处于同一控制域。约束机制不同通信路径不同身份状态重新获取本地验证一次性挑战设备签名提交证据。结果目标让控制初始提议通道的攻击者不能仅凭同一通道直接制造最终提交。在 Havenlon 中HTTPS Propose 与 gRPC mTLS Confirm 分离最终由本地设备形成 Device-Signed Commit。16. Device-Signed Commit设备签名提交一句话定义设备签名提交是本地执行控制设备对最终执行候选及其链路状态进行签名形成可验证提交事实的机制。严格定义Device-Signed Commit 应至少绑定IntentHash最终载荷摘要Last Step HashChain DigestPolicy HashGovernance State执行槽位密钥槽位计数器提交时间设备身份提交结果。设备签名提交证明某个具体设备在某个具体状态对某个具体 Intent形成了某个具体 Commit。它不自动证明外部系统已经成功完成最终动作因此仍需 Receipt 与 Post-Execution Proof。上位概念Commitment设备证据本地事实下位概念执行提交签名治理提交签名拒绝提交签名中断提交签名相关概念Device-Signed FactFinal Signing PayloadEvidence StoreCounterPost-Execution Proof权力边界设备签名提交不能由 SaaS 或应用代签也不能脱离具体 Intent 和链路状态。约束机制设备私钥安全元件防回滚计数器域分离Final Signing Payload不可重放本地 Evidence Store。结果目标把最终提交事实从 SaaS 自我声明转化为设备可验证事实。在 Havenlon 中Device-Signed Commit 是 SaaS 无法单方面伪造的执行事实来源之一。
