Havenlon｜AI 时代的执行安全语言体系（六七）：恢复边界

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. Recovery Boundary｜恢复边界

一句话定义

恢复边界，是限制谁能够在什么条件下修复、替换、重建或解除安全状态的治理与技术边界。

严格定义

Recovery Boundary 必须覆盖：

• Owner Recovery；
• Device Replacement；
• Credential Rotation；
• Evidence Chain Repair；
• Governance State Rebuild；
• Firmware Recovery；
• Counter Migration；
• Safe Mode Exit；
• Lockdown Exit。

恢复边界必须回答：

• 谁可以发起恢复；
• 谁必须参与；
• 是否需要物理存在；
• 恢复影响哪些状态；
• 哪些旧权限被撤销；
• 新权限何时生效；
• 是否存在冷静期；
• 是否保留原证据；
• 恢复后是否进入受限模式；
• 谁能够证明恢复完成。

上位概念

• Governance Boundary
• Physical Trust Boundary

下位概念

• Owner Recovery Boundary
• Device Recovery Boundary
• Evidence Recovery Boundary
• Firmware Recovery Boundary
• Safe Mode Exit Boundary

相关概念

• Physical Recovery Mode
• Governance Recovery
• Recovery Evidence
• Boundary of Boundaries
• No Unilateral Catastrophic Authority

权力边界

恢复权不能自动包含：

• 删除全部历史；
• 重置全部 counter；
• 关闭全部 Policy；
• 立即执行高风险动作；
• 绕过治理；
• 重新获得旧密钥。

约束机制

• 多方治理；
• 物理操作；
• 时间窗口；
• 新旧状态绑定；
• 旧凭证撤销；
• 冷静期；
• 恢复后低权限；
• 完整留证。

结果目标

让系统可以从严重异常中恢复，但不让恢复机制成为比正常执行更强的万能后门。

在 Havenlon 中

Safe Mode、Lockdown、Owner 和设备恢复都必须经过本地物理与治理条件。

失败模式与系统状态关系总图

Failure Detected ↓ Failure Classification │ ├── 可继续且风险有限 │ ↓ │ Degraded Operation │ ↓ │ Restricted Mode │ ├── 关键条件无法验证 │ ↓ │ Safe Mode │ ├── 执行根或边界可信性受损 │ ↓ │ Lockdown │ └── 需要现场修复或重建 ↓ Physical Recovery Mode ↓ Recovery Boundary ↓ Recovery Evidence

安全失败与不安全失败的区别

Safe Failure 异常发生 → 权力收缩 → 高风险动作停止 → 状态显式可见 → 形成证据 → 受控恢复 Unsafe Failure 异常发生 → 检查被跳过 → 权限放宽 → 启用旁路 → 继续不可逆执行 → 证据可能缺失

核心区别不是系统是否继续运行，而是：

失败以后，执行能力是缩小了，还是扩大了。

Safe Mode、Restricted Mode 与 Lockdown 的区别

Restricted Mode｜受限模式 系统仍然可信，但部分能力不可用或风险上升。 允许有限、低风险、白名单动作。 Safe Mode｜安全模式 关键安全条件无法完整验证。 高风险执行停止，只保留最小安全功能。 Lockdown｜锁定状态 执行根、设备身份或边界本身可能失陷。 所有受保护执行停止，只允许诊断和恢复。

失败传播的典型路径

Policy 服务不可用 ↓ 使用过期缓存 ↓ 继续允许执行 ↓ 累计状态不准确 ↓ 额度被突破 ↓ 灾难半径扩大

安全响应应是：

Policy 服务不可用 ↓ 检查本地 Policy Freshness ↓ 收紧本地额度 ↓ 进入 Restricted Mode ↓ 超过离线窗口后进入 Safe Mode

另一个例子：

Evidence Store 背压 ↓ 停止记录拒绝 ↓ 继续处理执行 ↓ 状态无法审计 ↓ 请求重复执行

安全响应应是：

Evidence Backpressure ↓ 降低 Rate Limit ↓ 拒绝低优先级请求 ↓ 达到 Backpressure Threshold ↓ 停止高风险执行

失败状态的能力矩阵

Normal Mode ├── 正常提议 ├── 正常审批 ├── 自动化 ├── 高风险执行 └── 治理变更 Restricted Mode ├── 查询与证据导出 ├── 低风险执行 ├── 白名单对象 ├── 人工确认 └── 禁止高风险治理 Safe Mode ├── 查询 ├── 诊断 ├── 证据导出 ├── 受控恢复准备 └── 拒绝不可逆执行 Lockdown ├── 最小诊断 ├── 原始证据导出 ├── 设备状态证明 └── 物理恢复入口 Physical Recovery Mode ├── 设备或身份重建 ├── 证据核验 ├── 凭证轮换 ├── 治理恢复 └── 禁止普通业务执行

限额、限频与限域的关系

Amount Limit 限制： 一次或累计最多损失多少。 Rate Limit 限制： 损失发生得有多快。 Scope Limit 限制： 损失能够影响哪些对象和场景。 TimeGuard 限制： 执行可以在什么时候发生。 DistanceGuard 限制： 执行必须在什么位置或接近关系下发生。

共同构成：

Value Bound + Speed Bound + Scope Bound + Time Bound + Location Bound = Bounded Execution Risk

失败模式评审问题

评估一套执行系统时，至少应回答：

1. 系统定义了哪些 Failure Mode？
2. 每种失败由什么条件触发？
3. 失败后哪些状态仍然可信？
4. 失败后哪些执行能力仍然可用？
5. 未知异常默认进入什么状态？
6. Policy 不可用时系统继续还是拒绝？
7. Approval 状态无法确认时如何处理？
8. SaaS 不可用时是否启用更宽松路径？
9. Arbiter 不可用时是否允许应用直达 Executor？
10. Security Domain 不可用时是否存在软件备用密钥？
11. Evidence Store 满时是否继续执行？
12. counter 异常时是否进入 Safe Mode？
13. 失败是否能够静默发生？
14. UI 状态是否可能与真实设备状态不一致？
15. 部分失败是否被建模？
16. Commit 成功但 Executor 失败时如何处理？
17. Executor 调用后 Receipt 丢失时如何处理？
18. 模糊状态是否允许自动重试？
19. 多步骤动作部分完成时是否存在补偿机制？
20. 重试是否具有幂等性？
21. 一个组件失败是否会沿链路传播？
22. 下游是否保留独立拒绝权？
23. 多个组件是否存在共因失效？
24. 多个审批账户是否真正独立？
25. 多个硬件域是否共享同一更新密钥？
26. 系统有哪些可用性单点？
27. 系统有哪些灾难性执行单点？
28. 一个 Owner 失陷后最多能做什么？
29. 一个 SaaS 管理员失陷后最多能做什么？
30. 一个 Key Slot 失陷后的最大范围是什么？
31. Safe Mode 的进入条件是什么？
32. Safe Mode 中允许哪些动作？
33. 谁可以退出 Safe Mode？
34. SaaS 能否远程退出 Safe Mode？
35. Restricted Mode 与 Safe Mode 有何区别？
36. Lockdown 在什么情况下触发？
37. Lockdown 是否停止所有受保护执行？
38. Lockdown 是否仍允许证据导出？
39. Physical Recovery Mode 是否禁用正常业务执行？
40. 恢复模式是否比正常模式权限更大？
41. 恢复是否需要多方和物理条件？
42. 恢复后是否立即恢复全部权限？
43. 是否设置恢复冷静期？
44. Backpressure 有哪些来源？
45. Backpressure Threshold 如何分级？
46. 达到阈值后是限流还是丢弃证据？
47. TimeGuard 依赖什么时间源？
48. 时间回退时如何处理？
49. DistanceGuard 是否被当成唯一安全条件？
50. Rate Limit 是否按身份、对象和槽位分别实施？
51. Amount Limit 是否考虑拆单和累计？
52. Scope Limit 是否阻止跨对象和跨场景使用？
53. 未知对象是否默认拒绝？
54. 未知消息类型是否默认拒绝？
55. Refuse to Execute 是否真实阻止密钥调用？
56. 拒绝是否形成 Denial Evidence？
57. Fail-Secure 是否是系统默认，还是个别模块行为？
58. 备用路径是否遵守相同约束？
59. 失败、降级、锁定和恢复是否全部留证？
60. 系统失败时，执行权最终是收缩还是扩张？

如果这些问题没有明确答案，系统可能只定义了正常流程，却没有定义真正决定灾难半径的失败行为。

本章核心公理

所有复杂系统都会失败，安全的区别在于失败后权力如何变化。

安全失败不是系统永远停止，而是在判断能力下降时优先收缩高风险执行能力。

不安全失败最常见的表现，是某个安全组件不可用后，系统为了保持业务连续而自动放宽限制。

静默失败比显式失败更危险，因为系统会在错误状态下继续表现得像一切正常。

部分失败必须明确哪些结果已经不可逆，不能简单回滚状态或整体重试。

级联失效发生在一层错误被下游无条件继承时，分层不信任的价值就是阻止这种传播。

多个组件不等于多个独立边界，共享管理员、更新密钥或恢复入口可能造成共因失效。

单点故障是可用性问题，单点灾难性执行是权力问题。

系统可以接受某个组件故障导致停机，但不能接受某个组件失陷后独自完成灾难。

Restricted Mode 保留有限能力，Safe Mode 停止高风险能力，Lockdown 停止全部受保护执行能力。

恢复模式不是超级管理员模式，恢复过程必须比普通执行受到更严格约束。

降级运行应当减少功能，而不是降低安全标准。

背压必须向上游传播为限流和拒绝，不能向下游传播为证据丢失和约束绕过。

TimeGuard 限制执行何时发生，DistanceGuard 限制执行在什么位置条件下发生。

Amount Limit 限制损失规模，Rate Limit 限制损失速度，Scope Limit 限制损失范围。

默认拒绝不是保守偏好，而是未知状态不能自动获得现实执行资格。

拒绝执行必须真实阻止签名、提交或 Executor 调用，而不是只返回一个软件错误。

恢复边界决定谁能够重新赋予系统执行能力，因此恢复权本身就是高风险治理权。

失败模式最终决定的，不只是系统是否可用，而是单点错误最多能走多远。

Havenlon 对失败模式与系统状态的基本回应

Havenlon 不假设身份、网络、SaaS、Policy、硬件、证据或外部执行系统永远可用。

它要求：

1. 为关键异常定义明确 Failure Mode；
2. 区分 Safe Failure 与 Unsafe Failure；
3. 禁止关键安全依赖失效后自动 fail-open；
4. 让所有失败显式可见；
5. 防止 Silent Failure；
6. 将 Partial Failure 建模为独立状态；
7. 区分明确未执行、部分执行和状态未知；
8. 禁止模糊状态无条件重试；
9. 使用幂等键和 Commit ID 约束重试；
10. 识别并阻断 Cascading Failure；
11. 检查跨组件 Common-Mode Failure；
12. 区分 Single Point of Failure 与 Single Point of Catastrophic Execution；
13. 优先消除单点灾难性权力；
14. 为异常定义 Restricted Mode；
15. 为关键状态无法验证定义 Safe Mode；
16. 为执行根或设备身份失陷定义 Lockdown；
17. 为现场修复定义 Physical Recovery Mode；
18. 让降级运行收缩功能而不放宽边界；
19. 为 Evidence、Executor、网络和审批队列定义 Backpressure；
20. 设置多级 Backpressure Threshold；
21. 背压超限时先限流，再拒绝，再进入 Safe Mode；
22. 使用 TimeGuard 约束时效、顺序和冷静期；
23. 使用 DistanceGuard 约束本地存在、区域和设备接近关系；
24. 使用 Rate Limit 限制自动化和攻击传播速度；
25. 使用 Amount Limit 限制最大资产或业务损失；
26. 使用 Scope Limit 限制可影响对象和场景；
27. 让本地硬上限不能被 SaaS 放宽；
28. 对未知对象、未知状态和未知消息默认拒绝；
29. 让 Refuse to Execute 真实阻断签名和 Executor；
30. 将 Fail-Secure Default 作为系统级默认；
31. 让故障、拒绝、降级、锁定和恢复全部形成证据；
32. 让 Safe Mode 和 Lockdown 不能由普通远程管理员解除；
33. 让 Physical Recovery Mode 禁止普通业务执行；
34. 让 Recovery Boundary 受到多方治理、物理条件和时间约束；
35. 让恢复后先进入受限状态，而不是立即恢复全部权力；
36. 让恢复过程保留旧状态与完整 Recovery Evidence；
37. 让所有备用、维护和恢复路径遵守相同或更严格的执行边界；
38. 让任何组件失败后，执行能力默认缩小而不是扩大。

最终原则是：

Havenlon 不承诺系统永远不会失败。

它要求系统在失败时仍然知道自己还能做什么、不能做什么，以及谁有资格让它恢复。

真正安全的系统，不是永远在线的系统，而是在失去确定性时仍然拒绝把不确定性转化为灾难性执行的系统。