企业官网建设流程全解析

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 时代执行安全的共同语言。 本文中的术语与定义代表当前工作草案， 将随着理论研究、工程实践和社区讨论持续修订

12. Propose｜提议阶段

一句话定义

Propose 是将结构化 Intent 通过初始受控通道提交给协同和治理系统的阶段。

严格定义

Propose 阶段主要完成：

• Intent 结构化；

• 来源身份验证；

• IntentHash 生成；

• 初始参数检查；

• 创建唯一请求；

• 获取初始 Policy；

• 启动审批；

• 记录提议证据。

Propose 不意味着本地设备已经同意执行。

上位概念

• Execution Flow

• Proposal

下位概念

• HTTPS Propose

• Agent Propose

• Governance Propose

• Application Propose

相关概念

• Confirm

• Commit

• Intent Origin

• Proposal Evidence

• Two-Phase Commit

权力边界

Propose 通道不能直达执行器，也不能携带能够绕过后续仲裁的万能授权。

约束机制

• 身份认证；

• TLS；

• IntentHash；

• 请求 ID；

• 有效期；

• 防重放；

• 初始状态记录。

结果目标

建立执行链的可追溯起点，而不是立即创建执行事实。

在 Havenlon 中

初始请求可通过 HTTPS 进入 Bletchley 或 Hub 协同流程，但仍需后续 Confirm 与设备提交。

13. Confirm｜确认阶段

一句话定义

Confirm 是通过独立于初始 Propose 的受控路径，对审批、Policy、Intent 和当前状态进行再次确认的阶段。

严格定义

Confirm 的价值在于避免：

同一通道既创建请求，又单方面声明请求可以执行。

Confirm 通常应验证：

• 请求 ID；

• IntentHash；

• Approval；

• Governance State；

• Policy Hash；

• 当前额度；

• 当前时间；

• 当前设备；

• 防重放状态；

• 最终候选参数。

确认通道应具有不同的身份、状态或传输约束。

上位概念

• Execution Flow

• Confirmation

下位概念

• gRPC Confirm

• mTLS Confirm

• Device Confirm

• Local Confirm

相关概念

• Propose

• Commit

• Final Revalidation

• Two-Phase Commit

• Context Binding

权力边界

Confirm 不能静默接受与 Propose 不同的关键参数。

如果关键内容变化，必须触发 Intent Rebinding 或重新提议。

约束机制

• mTLS；

• 双向身份；

• IntentHash 比较；

• 状态版本；

• Policy Hash；

• 一次性挑战；

• 超时；

• 本地重新验证。

结果目标

证明初始提议在当前状态下仍然成立，并为设备提交建立最新候选状态。

在 Havenlon 中

Confirm 通过 gRPC mTLS 等独立协同路径完成，本地设备不会仅凭 HTTPS Proposal 直接执行。

14. Commit｜提交阶段

一句话定义

Commit 是本地设备在最终验证通过后，对具体执行候选作出密码学确认并形成可执行事实的阶段。

严格定义

Commit 阶段应完成：

• Final Revalidation；

• Final Signing Payload 构建；

• 执行槽位与密钥槽位验证；

• Last Step Hash 验证；

• Chain Digest 验证；

• 防重放计数器更新；

• Device-Signed Commit；

• 证据记录；

• 进入实际执行或授权执行。

Commit 是从“允许候选”进入“确定执行”的关键边界。

上位概念

• Execution Flow

• Commitment

下位概念

• Device Commit

• Signed Commit

• Execution Commit

• Governance Commit

相关概念

• Propose

• Confirm

• Device-Signed Commit

• Final Signing Payload

• Pre-Execution Control

权力边界

Commit 不能由 SaaS 数据库状态代替，也不能由应用自行伪造。

约束机制

• 设备签名；

• 独立计数器；

• Final Signing Payload；

• Last Step Hash；

• Chain Digest；

• Evidence 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 与本地双阶提交

• 网络与设备双阶提交

相关概念

• Propose

• Confirm

• Device-Signed Commit

• Communication and Decision Separation

• Final Revalidation

容易混淆的概念

双阶提交不等于：

• 同一个接口调用两次；

• 同一个 SaaS 写两个数据库状态；

• 两个人重复点击确认；

• 数据库协调者询问多个参与者是否准备好；

• 保证业务动作绝对原子。

其安全价值来自两个阶段不完全处于同一控制域。

约束机制

• 不同通信路径；

• 不同身份；

• 状态重新获取；

• 本地验证；

• 一次性挑战；

• 设备签名；

• 提交证据。

结果目标

让控制初始提议通道的攻击者，不能仅凭同一通道直接制造最终提交。

在 Havenlon 中

HTTPS Propose 与 gRPC mTLS Confirm 分离，最终由本地设备形成 Device-Signed Commit。

16. Device-Signed Commit｜设备签名提交

一句话定义

设备签名提交，是本地执行控制设备对最终执行候选及其链路状态进行签名，形成可验证提交事实的机制。

严格定义

Device-Signed Commit 应至少绑定：

• IntentHash；

• 最终载荷摘要；

• Last Step Hash；

• Chain Digest；

• Policy Hash；

• Governance State；

• 执行槽位；

• 密钥槽位；

• 计数器；

• 提交时间；

• 设备身份；

• 提交结果。

设备签名提交证明：

• 某个具体设备；

• 在某个具体状态；

• 对某个具体 Intent；

• 形成了某个具体 Commit。

它不自动证明外部系统已经成功完成最终动作，因此仍需 Receipt 与 Post-Execution Proof。

上位概念

• Commitment

• 设备证据

• 本地事实

下位概念

• 执行提交签名

• 治理提交签名

• 拒绝提交签名

• 中断提交签名

相关概念

• Device-Signed Fact

• Final Signing Payload

• Evidence Store

• Counter

• Post-Execution Proof

权力边界

设备签名提交不能由 SaaS 或应用代签，也不能脱离具体 Intent 和链路状态。

约束机制

• 设备私钥；

• 安全元件；

• 防回滚计数器；

• 域分离；

• Final Signing Payload；

• 不可重放；

• 本地 Evidence Store。

结果目标

把最终提交事实从 SaaS 自我声明转化为设备可验证事实。

在 Havenlon 中

Device-Signed Commit 是 SaaS 无法单方面伪造的执行事实来源之一。