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 时代执行安全的共同语言。 本文中的术语与定义代表当前工作草案， 将随着理论研究、工程实践和社区讨论持续修订
25. Owner Recovery｜所有者恢复
一句话定义
所有者恢复，是在 Owner 凭证遗失、身份失陷、设备损坏或长期不可用时，重新建立有效 Owner 治理关系的过程。
严格定义
Owner Recovery 必须区分：
恢复身份；
恢复治理资格；
恢复设备；
恢复执行能力。
恢复 Owner 身份不应立即恢复全部高风险执行权。
安全的 Owner 恢复通常需要：
本地物理操作；
多方治理参与；
恢复原因；
旧 Owner 状态撤销；
新凭证建立；
冷静期；
初始低权限；
恢复证据；
高风险操作延迟。
上位概念
Governance Recovery
下位概念
Owner 凭证恢复
Owner 设备恢复
Owner 身份替换
Owner 权力重新建立
相关概念
Physical Recovery
Owner ≠ God
Governance Capture
Recovery Window
Governance Mutation Control
权力边界
Owner 恢复不能：
由 SaaS 单方面完成；
清除原治理证据；
绕过所有成员；
恢复后立即转移全部资产；
自动关闭旧状态审查。
约束机制
物理恢复；
多方确认；
动态码；
有效期；
冷静期；
分阶段恢复；
旧状态撤销；
恢复留证。
结果目标
既避免 Owner 遗失导致系统永久锁死，也防止恢复机制成为接管系统的万能入口。
在 Havenlon 中
Owner 证书激活后，关键恢复应依赖本地物理流程；成员换证等治理动作还需要 Owner 动态码或其他独立约束。
26. Physical Recovery｜物理恢复
一句话定义
物理恢复，是必须通过本地设备、物理接触、指定硬件或不可远程完成的操作，重新建立治理或执行状态的恢复方式。
严格定义
物理恢复的价值不是保证操作者一定诚实，而是增加一个与远程身份、SaaS 和普通管理员不同的恢复条件。
物理恢复可能要求：
本地按键；
设备接触；
指定硬件参与；
安全元件挑战；
现场设备替换；
恢复窗口；
多设备组合；
物理存在证明。
上位概念
Governance Recovery
Physical Trust Boundary
下位概念
本地按键恢复
设备替换恢复
安全元件恢复
多设备恢复
现场治理恢复
相关概念
Owner Recovery
Recovery Boundary
Independent Final Veto
Physical Constraint Policy
Offline Recoverability
容易混淆的概念
物理恢复不等于：
单人拿到设备即可重置一切；
设备上有一个隐藏重置按钮；
本地操作天然可信；
清除全部治理状态恢复出厂。
物理恢复仍然需要治理、作用域和证据约束。
约束机制
多步骤；
指定设备；
时间窗口；
挑战响应；
多方参与；
恢复后低权限；
过程签名；
防静默恢复。
结果目标
阻止纯远程攻击者仅凭控制云端、管理员或凭证完成系统接管。
在 Havenlon 中
关键治理恢复和设备恢复不能完全由 SaaS 发起，而需要本地设备和物理条件参与。
27. Governance Mutation Control｜治理变更控制
一句话定义
治理变更控制，是对成员、角色、阈值、Policy、设备和恢复关系的任何变化进行识别、限制、延迟、验证和留证的机制。
严格定义
治理变更控制要求：
每次变化都有 Governance Intent；
明确变更前后状态；
评估是否扩大灾难半径；
识别谁从变更中获得新权力；
重要放宽需要更高治理要求；
变更不能静默发生；
变更不能立即用于绕过原约束；
变更后需要重新绑定执行状态；
变更全过程可审计。
治理变更控制尤其关注：
谁能够修改限制自己的规则？
上位概念
Governance
变更控制
下位概念
成员变更控制
阈值变更控制
Policy 变更控制
设备变更控制
恢复关系变更控制
相关概念
Governance Change
Governance Capture
Governance State
Policy Override
Boundary of Boundaries
约束机制
变更分类；
风险级别；
多方审批；
延迟生效；
物理确认；
版本；
防回滚；
新旧状态证据；
变更后限制期。
结果目标
防止攻击者通过修改治理结构，间接获得原本不具备的执行权。
在 Havenlon 中
成员、Owner、阈值、Policy 上限、执行器和设备变更必须进入独立治理流程，并在本地状态中版本化保存。
治理结构关系总图
Governance｜治理 │ ├── Governance State｜治理状态 │ ├── Owner │ ├── Member │ ├── 角色 │ ├── 阈值 │ ├── 法定数量 │ ├── Policy 上限 │ ├── 设备 │ └── 恢复关系 │ ├── Governance Authority｜治理权 │ └── 谁能提出、批准和恢复治理变化 │ ├── Governance Intent｜治理意图 │ └── 希望如何改变治理状态 │ ├── Governance Constraint｜治理约束 │ ├── Governance Quorum｜治理法定数量 │ └── Governance Threshold｜治理阈值 │ ├── Governance Change｜治理变更 │ └── Governance Mutation Control｜治理变更控制 │ └── Governance Recovery｜治理恢复 ├── Owner Recovery｜所有者恢复 └── Physical Recovery｜物理恢复
共同治理的角色结构
Proposer｜提议者 负责表达希望发生什么 ↓ Approver｜审批者 负责表达独立同意或拒绝 ↓ Arbiter｜仲裁者 负责聚合治理、Policy 和当前状态 ↓ Executor｜执行者 负责实施已通过约束的具体动作 ↓ Evidence Witness｜证据见证者 负责独立验证和保存执行事实
辅助监督角色：
Observer｜观察者 负责查看、监督和发现异常
共同治理要求：
Separation of Roles｜角色分离 ↓ Independent Consent｜独立同意 ↓ Governance Quorum｜满足有效参与范围 ↓ Governance Threshold｜满足同意要求 ↓ Multi-Party Constraint｜多方约束 ↓ Arbiter 独立收敛 ↓ Executor 受限执行 ↓ No Unilateral Catastrophic Authority
共同治理与多人审批的区别
普通多人审批可能是：
同一个 SaaS 后台 ↓ 多个审批账户 ↓ 全部由同一个管理员管理 ↓ approved = true ↓ 直接执行
这种结构的问题是：
多个身份可能处于同一信任域；
同一个管理员可以控制所有账户；
审批内容可能与执行载荷分离；
审批结果直接成为执行命令；
执行和证据可能仍由同一系统控制。
真正的共同治理应当是：
不同身份 + 不同角色 + 有限作用域 + 独立凭证 + 独立同意 + Intent 绑定 + 明确 Quorum + 明确 Threshold + 独立仲裁 + 受限执行 + 独立证据
因此：
多人点击同意，只能证明有多个点击事件。
只有当这些同意来自权力有限、控制独立并且绑定同一 Intent 的治理主体时，它们才构成共同治理。
共同治理与多数投票的区别
多数投票回答：
哪一个选项获得了更多票？
共同治理还必须回答：
这些票是否来自独立主体；
是否满足必要角色组合；
是否达到法定参与数量；
是否存在硬性拒绝；
是否绑定同一个具体 Intent；
是否仍在有效期；
是否允许多数人取消物理边界；
是否存在不能由投票放宽的硬限制；
投票结果是否仍需独立执行验证。
因此，共同治理不一定采用简单多数。
某些高风险动作可能要求：
Owner 同意 + 至少两名独立 Member 同意 + 本地设备参与 + Arbiter 验证 + Security Domain 最终通过
这不是单一票数能够完整表达的。
治理劫持的典型路径
控制一个高权限身份 ↓ 增加恶意成员 ↓ 删除独立成员 ↓ 降低 Governance Threshold ↓ 修改 Policy 上限 ↓ 替换设备或执行器 ↓ 使用新治理状态完成高风险执行
Havenlon 的反向约束路径是：
Owner ≠ God ↓ Separation of Roles ↓ Independent Consent ↓ Quorum 与 Threshold 分离 ↓ 治理变更延迟生效 ↓ 新成员和新权力具有冷静期 ↓ 治理与执行分离 ↓ Physical Recovery 受多方约束 ↓ 治理变更完整留证
治理恢复的原则
治理恢复必须同时避免两个极端。
第一个极端是无法恢复：
Owner 丢失凭证 ↓ 无人可以改变治理状态 ↓ 系统永久锁死
第二个极端是恢复权过大：
攻击者获得恢复凭证 ↓ 清除全部成员与规则 ↓ 建立新 Owner ↓ 立即执行全部高风险动作
安全恢复应当是：
识别恢复事件 ↓ 本地物理条件 ↓ 多方参与或替代治理条件 ↓ 撤销旧状态 ↓ 建立新治理状态 ↓ 冷静期与低权限阶段 ↓ 逐步恢复高风险能力 ↓ 完整恢复证据
治理评审问题
评估一套治理系统时，至少应回答：
谁拥有治理权？
Owner 可以独立做什么？
Member 是否拥有不同角色和作用域？
提议者能否审批自己的提议？
审批者能否直接控制执行？
Arbiter 是否与 Executor 分离？
观察者是否真正只读？
证据见证者是否独立于执行者？
治理法定数量和治理阈值是否被区分？
多个同意是否来自独立身份和设备？
同一个管理员能否控制多个治理成员？
治理同意是否绑定具体 Intent？
治理结果是否具有有效期？
成员变化能否立即生效？
降低阈值需要什么条件？
新成员能否加入后立即执行高风险动作？
Owner 能否单独删除所有其他成员？
治理者能否修改限制自己的规则？
Governance State 由谁保存和证明？
SaaS 与本地治理状态冲突时如何处理？
治理变更是否经过本地验证？
恢复流程是否比正常治理更宽松？
Owner 恢复后是否立即拥有全部能力？
物理恢复是否仍需治理约束？
治理变更是否留下不可重写证据？
一个治理身份失陷后的灾难半径是多少？
多个治理主体共谋时，剩余哪些硬限制？
是否存在任何单方灾难性权力？
治理结果是否仍需经过执行边界？
整套治理是否只是同一信任域中的多人点击？
如果这些问题无法清楚回答，所谓共同治理可能只是集中式执行权的多人界面。
本章核心公理
治理不是谁拥有最高权限，而是谁能够在什么条件下改变权力结构。
共同治理不是多个主体共享无限权力，而是多个权力有限的主体共同限制执行。
共享治理描述治理责任由谁共同持有，共同治理描述这些主体如何形成有效约束。
多个凭证不等于多个独立治理意志。
治理法定数量决定治理过程是否具备有效参与范围，治理阈值决定需要多少有效同意。
同意只有在身份独立、设备独立、内容绑定和作用域明确时，才是独立同意。
提议权、审批权、仲裁权、执行权和证明权必须分离。
治理者不能因为能够修改规则，就自动获得绕过规则的权力。
Owner 承担最高治理责任，但不是不受系统约束的上帝。
治理恢复必须存在，但恢复权不能成为比正常治理更强的超级后门。
任何扩大权力、降低阈值或放宽限制的治理变更，都应比普通治理要求更高，而不是更低。
治理结果仍然只是执行约束的一部分，不能替代最终执行边界。
真正的共同治理，最终必须实现无单方灾难性权力。
Havenlon 对治理与共同治理的基本回应
Havenlon 不把共同治理简化为多人审批或多签。
它要求：
明确治理状态；
明确治理权的范围；
区分 Governance Intent 与普通 Execution Intent；
将 Owner、Member、Proposer、Approver、Arbiter、Executor、Observer 和 Evidence Witness 分开；
阻止角色权力自动继承；
将 Governance Quorum 与 Governance Threshold 分开；
要求同意来自独立身份、独立设备和明确作用域；
禁止提议者对高风险提议自我审批；
让审批结果不能直接驱动执行；
让 Arbiter 与 Executor 分离；
让治理与执行分离；
让治理变化形成独立 Intent；
对成员、阈值、Policy、设备和恢复变化实施 Governance Mutation Control；
对扩大权力的变化采用更高治理要求；
对关键治理变化设置延迟和冷静期；
让新治理状态不能立即用于灾难性执行；
让 Owner 恢复需要本地和物理条件；
让物理恢复同样受到治理与证据约束；
让治理状态同时存在本地约束与协同状态；
让治理变更、拒绝和恢复都留下可验证证据；
让任何治理主体失陷后的灾难半径保持有限；
在广泛共谋无法完全阻止时，仍通过限额、延迟、硬边界和证据限制结果。
最终原则是：
共同治理不是把最终执行权交给一群人。
它是让多个权力有限、信任独立的角色，共同证明一个动作已经满足治理要求，同时仍然不能绕过执行边界。
任何单方都不能独自决定、独自执行并独自解释一场灾难。