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 时代执行安全的共同语言。 本文中的术语与定义代表当前工作草案 将随着理论研究、工程实践和社区讨论持续修订25. Owner Recovery所有者恢复一句话定义所有者恢复是在 Owner 凭证遗失、身份失陷、设备损坏或长期不可用时重新建立有效 Owner 治理关系的过程。严格定义Owner Recovery 必须区分恢复身份恢复治理资格恢复设备恢复执行能力。恢复 Owner 身份不应立即恢复全部高风险执行权。安全的 Owner 恢复通常需要本地物理操作多方治理参与恢复原因旧 Owner 状态撤销新凭证建立冷静期初始低权限恢复证据高风险操作延迟。上位概念Governance Recovery下位概念Owner 凭证恢复Owner 设备恢复Owner 身份替换Owner 权力重新建立相关概念Physical RecoveryOwner ≠ GodGovernance CaptureRecovery WindowGovernance Mutation Control权力边界Owner 恢复不能由 SaaS 单方面完成清除原治理证据绕过所有成员恢复后立即转移全部资产自动关闭旧状态审查。约束机制物理恢复多方确认动态码有效期冷静期分阶段恢复旧状态撤销恢复留证。结果目标既避免 Owner 遗失导致系统永久锁死也防止恢复机制成为接管系统的万能入口。在 Havenlon 中Owner 证书激活后关键恢复应依赖本地物理流程成员换证等治理动作还需要 Owner 动态码或其他独立约束。26. Physical Recovery物理恢复一句话定义物理恢复是必须通过本地设备、物理接触、指定硬件或不可远程完成的操作重新建立治理或执行状态的恢复方式。严格定义物理恢复的价值不是保证操作者一定诚实而是增加一个与远程身份、SaaS 和普通管理员不同的恢复条件。物理恢复可能要求本地按键设备接触指定硬件参与安全元件挑战现场设备替换恢复窗口多设备组合物理存在证明。上位概念Governance RecoveryPhysical Trust Boundary下位概念本地按键恢复设备替换恢复安全元件恢复多设备恢复现场治理恢复相关概念Owner RecoveryRecovery BoundaryIndependent Final VetoPhysical Constraint PolicyOffline Recoverability容易混淆的概念物理恢复不等于单人拿到设备即可重置一切设备上有一个隐藏重置按钮本地操作天然可信清除全部治理状态恢复出厂。物理恢复仍然需要治理、作用域和证据约束。约束机制多步骤指定设备时间窗口挑战响应多方参与恢复后低权限过程签名防静默恢复。结果目标阻止纯远程攻击者仅凭控制云端、管理员或凭证完成系统接管。在 Havenlon 中关键治理恢复和设备恢复不能完全由 SaaS 发起而需要本地设备和物理条件参与。27. Governance Mutation Control治理变更控制一句话定义治理变更控制是对成员、角色、阈值、Policy、设备和恢复关系的任何变化进行识别、限制、延迟、验证和留证的机制。严格定义治理变更控制要求每次变化都有 Governance Intent明确变更前后状态评估是否扩大灾难半径识别谁从变更中获得新权力重要放宽需要更高治理要求变更不能静默发生变更不能立即用于绕过原约束变更后需要重新绑定执行状态变更全过程可审计。治理变更控制尤其关注谁能够修改限制自己的规则上位概念Governance变更控制下位概念成员变更控制阈值变更控制Policy 变更控制设备变更控制恢复关系变更控制相关概念Governance ChangeGovernance CaptureGovernance StatePolicy OverrideBoundary 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 恢复需要本地和物理条件让物理恢复同样受到治理与证据约束让治理状态同时存在本地约束与协同状态让治理变更、拒绝和恢复都留下可验证证据让任何治理主体失陷后的灾难半径保持有限在广泛共谋无法完全阻止时仍通过限额、延迟、硬边界和证据限制结果。最终原则是共同治理不是把最终执行权交给一群人。它是让多个权力有限、信任独立的角色共同证明一个动作已经满足治理要求同时仍然不能绕过执行边界。任何单方都不能独自决定、独自执行并独自解释一场灾难。