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

任何复杂系统都会失败。

设备会掉电，网络会中断，Policy 会过期，审批状态会不同步，SaaS 会不可用，存储会耗尽，硬件会损坏，管理员会误操作，AI Agent 会产生错误判断，外部执行系统也可能返回模糊结果。

因此，真正重要的问题不是：

系统会不会失败？

而是：

系统失败时，会变成什么状态？

传统系统经常把“可用性”置于最高优先级。

当某个安全检查不可用时，它们可能选择：

• 跳过检查；
• 使用缓存结果；
• 沿用旧 Policy；
• 自动切换到备用路径；
• 暂时关闭审计；
• 放宽额度；
• 改用管理员直连；
• 默认继续执行。

这些机制短期内看起来提高了可用性，却可能把一个局部故障升级为灾难性执行。

Havenlon 不追求“任何情况下都继续运行”。

它要求系统明确区分：

• 哪些能力可以继续；
• 哪些能力必须缩小；
• 哪些动作必须暂停；
• 哪些状态需要物理恢复；
• 哪些故障可以自动恢复；
• 哪些故障必须进入治理；
• 哪些未知状态必须默认拒绝；
• 哪些恢复路径不能成为绕过安全边界的后门。

Havenlon 对安全失败的核心定义是：

安全失败不是系统停止工作，而是系统在失去完整判断能力时，主动收缩到最小风险状态。

因此，失败模式设计的目标不是“永不失败”，而是：

1. 失败必须可识别；
2. 失败不能静默扩大；
3. 局部失败不能自动传播；
4. 不确定状态不能被解释为允许；
5. 高风险能力必须优先收缩；
6. 低风险、可逆能力可以受控保留；
7. 恢复过程必须受到独立治理；
8. 失败、降级、锁定和恢复都必须留下证据；
9. 安全状态不能由上游普通管理员随意解除；
10. 所有失败状态都必须有明确进入条件、允许能力和退出条件。

1. Failure Mode｜失败模式

一句话定义

失败模式，是系统、组件或执行链在发生故障、失陷、异常或资源不足时表现出的具体状态与行为方式。

严格定义

Failure Mode 不只是“哪里坏了”。

它必须描述：

• 失败发生在哪一层；
• 失败由什么触发；
• 哪些状态仍可信；
• 哪些能力仍可用；
• 哪些动作必须停止；
• 是否可能产生部分结果；
• 是否会传播到其他组件；
• 是否需要人工或物理恢复；
• 是否形成证据；
• 是否允许自动退出。

典型失败模式包括：

• 安全失败；
• 不安全失败；
• 静默失败；
• 部分失败；
• 级联失效；
• 共因失效；
• 模糊执行状态；
• 背压状态；
• 降级运行；
• 锁定状态。

上位概念

• System State
• Failure Behavior
• Resilience

下位概念

• Safe Failure
• Unsafe Failure
• Silent Failure
• Partial Failure
• Cascading Failure
• Common-Mode Failure

相关概念

• Safe Mode
• Fail-Secure
• Controlled Degradation
• Recovery Boundary
• Blast Radius

容易混淆的概念

故障类型回答：

什么东西出了问题？

失败模式回答：

出问题以后，系统如何表现？

同一个网络故障可以导致：

• 安全暂停；
• 使用缓存继续；
• 自动切换旁路；
• 静默丢失证据。

这些是完全不同的失败模式。

约束机制

• 失败分类；
• 状态机；
• 明确触发条件；
• 受限能力表；
• 默认拒绝；
• 故障证据；
• 恢复条件。

结果目标

让系统在异常发生后进入预定义、可审计、风险有限的状态，而不是临时 improvisation。

在 Havenlon 中

每类设备、Policy、证据、治理和通信异常都必须映射到明确系统状态。

2. Safe Failure｜安全失败

一句话定义

安全失败，是系统发生异常后主动限制、暂停或拒绝高风险执行，使故障不能继续扩大真实损失的失败模式。

严格定义

安全失败通常表现为：

• 不生成签名；
• 不形成 Commit；
• 不触发 Executor；
• 降低额度；
• 限制频率；
• 禁用自动化；
• 只允许只读访问；
• 保留诊断能力；
• 进入 Safe Mode；
• 要求治理或物理恢复。

Safe Failure 不等于所有功能停止。

它的核心是：

在系统无法证明安全条件仍然成立时，不继续授予不可逆执行能力。

上位概念

• Failure Mode
• Fail-Secure

下位概念

• Execution Safe Failure
• Evidence Safe Failure
• Governance Safe Failure
• Communication Safe Failure
• Device Safe Failure

相关概念

• Fail-Closed
• Deny by Default
• Restricted Mode
• Least Harmful Failure
• Safe Interruption

权力边界

安全失败状态不能被上游简单标记为“忽略错误后继续”。

约束机制

• 默认拒绝；
• 本地最终否决；
• 能力收缩；
• 状态持久化；
• 故障证据；
• 受控恢复。

结果目标

将组件故障从潜在灾难转化为可管理的服务中断或有限降级。

在 Havenlon 中

Intent、Policy、证据链或本地状态无法验证时，系统优先拒绝高风险执行。

3. Unsafe Failure｜不安全失败

一句话定义

不安全失败，是系统发生异常后仍继续执行、扩大权限或失去约束，从而增加真实损失可能性的失败模式。

严格定义

典型不安全失败包括：

• Policy 服务不可用时默认允许；
• 审批状态无法获取时沿用旧允许；
• Evidence Store 已满时停止留证但继续执行；
• Arbiter 异常时应用直连 Executor；
• 安全芯片失败时使用软件备用密钥；
• 本地设备离线时改由 SaaS 直接执行；
• 设备状态不明时自动重试；
• 恢复模式关闭全部限制。

不安全失败通常源于：

把业务连续性放在执行边界之上。

上位概念

• Failure Mode
• Execution Risk

下位概念

• Fail-Open
• Bypass-on-Failure
• Unverified Continuation
• Unsafe Degradation

相关概念

• Boundary Bypass
• Catastrophic Execution
• Silent Failure
• Cascading Failure
• Unsafe Recovery

权力边界

任何组件都不能以“保证业务不中断”为由，单方面取消关键执行约束。

约束机制

• 禁止 fail-open；
• 故障路径审计；
• 备用路径同等治理；
• 本地硬限制；
• 恢复路径约束；
• 安全状态测试。

结果目标

识别并消除那些在正常状态安全、故障状态却自动放宽约束的设计。

在 Havenlon 中

SaaS、网络或 Policy 不可用时，系统不会自动切换成无治理执行。

4. Silent Failure｜静默失败

一句话定义

静默失败，是组件已经发生异常或未完成预期行为，但系统没有明确暴露、记录或传播这一状态的失败模式。

严格定义

Silent Failure 可能表现为：

• 证据写入失败但执行仍标记成功；
• Policy 拉取失败却使用空值；
• 审批同步失败但 UI 显示已通过；
• counter 未持久化但系统继续运行；
• Executor 部分失败但返回通用成功；
• 设备进入异常状态但未告警；
• Receipt 丢失却自动标记已完成；
• 备用路径被启用但未记录。

静默失败危险之处在于：

系统的真实状态与对外显示状态开始分离。

上位概念

• Failure Mode
• Observability Failure

下位概念

• Silent Evidence Failure
• Silent Policy Failure
• Silent Execution Failure
• Silent State Divergence
• Silent Recovery Failure

相关概念

• Evidence Gap
• Hidden Degradation
• State Divergence
• Audit Failure
• Ambiguous Execution State

权力边界

组件不能将无法确认的状态静默转换为成功或允许。

约束机制

• 明确错误传播；
• 状态一致性检查；
• 失败强制留证；
• 告警；
• 未知状态类型；
• 禁止自动掩盖。

结果目标

让失败变得可见、可定位和可约束，防止风险在“看起来正常”的状态下继续积累。

在 Havenlon 中

证据、Policy、治理或 Executor 状态无法确认时，必须显式进入异常状态。

5. Partial Failure｜部分失败

一句话定义

部分失败，是执行链、系统或复合动作中的一部分成功，而另一部分失败或状态未知的失败模式。

严格定义

部分失败可能出现在：

• Commit 已形成，但 Executor 调用失败；
• 多个子动作中部分成功；
• 交易已签名但未广播；
• 请求已广播但 Receipt 未返回；
• 治理变更部分同步；
• 多设备中部分完成状态更新；
• Evidence 已写入本地但未完成归档；
• 恢复流程完成身份替换但未完成旧状态撤销。

部分失败必须明确：

• 哪些步骤已不可逆；
• 哪些步骤可以重试；
• 哪些动作需要补偿；
• 是否可能产生重复结果；
• 是否需要冻结后续动作；
• 当前灾难半径是多少。

上位概念

• Failure Mode
• Distributed Execution Failure

下位概念

• Partial Commit Failure
• Partial Execution Failure
• Partial Governance Failure
• Partial Evidence Failure
• Partial Recovery Failure

相关概念

• Ambiguous Execution State
• Compensation
• Idempotency
• Safe Interruption
• Result Reconciliation

权力边界

系统不能将复合动作中的部分成功简单回写成整体成功，也不能无条件重放全部动作。

约束机制

• 子步骤标识；
• 幂等键；
• 分阶段证据；
• 补偿策略；
• 状态冻结；
• 人工治理；
• 精确重试。

结果目标

把部分成功造成的风险控制在已发生步骤内，避免重试扩大结果。

在 Havenlon 中

每个 Commit、Executor 调用和 Receipt 都有独立状态，复合执行不能只保留一个总状态。

6. Cascading Failure｜级联失效

一句话定义

级联失效，是一个组件或状态的失败沿依赖关系传播，导致多个系统、边界或执行能力连续失效的现象。

严格定义

级联失效可能表现为：

SaaS 不可用 → Policy 无法同步 → 应用使用缓存 → 缓存已过期 → Arbiter 接受旧状态 → Executor 继续执行

或者：

Evidence Store 堵塞 → 证据无法写入 → 重试队列持续增长 → 设备资源耗尽 → Safe Mode 失效 → 系统状态不一致

级联失效的关键问题是：

• 故障是否跨域传播；
• 下游是否拥有独立拒绝；
• 每一层是否把上游结果当成绝对事实；
• 是否存在断路机制；
• 是否限制传播速率和范围。

上位概念

• Failure Propagation
• Systemic Failure

下位概念

• Policy Cascade
• Evidence Cascade
• Network Cascade
• Governance Cascade
• Retry Cascade

相关概念

• Failure Containment
• Circuit Breaker
• Backpressure
• Common-Mode Failure
• Blast Radius

权力边界

下游组件不能因为上游异常而自动取消自己的本地约束。

约束机制

• 分层不信任；
• 独立状态；
• 断路；
• 限频；
• 超时；
• Safe Mode；
• 传播边界。

结果目标

让单一组件故障停留在本层，而不是沿执行链放大为系统性失控。

在 Havenlon 中

SaaS、Application、Arbiter 和 Security Domain 分别维护独立判断，阻止单层异常无条件传播。

7. Common-Mode Failure｜共因失效

一句话定义

共因失效，是多个看似独立的组件因共享同一漏洞、权限、依赖、环境或控制路径而同时失效的现象。

严格定义

共因来源可能包括：

• 相同固件；
• 相同代码库；
• 相同管理员；
• 相同更新密钥；
• 相同云账户；
• 相同 Policy 来源；
• 相同数据库；
• 相同时间源；
• 相同网络；
• 相同 AI 模型；
• 相同供应链；
• 相同恢复入口。

例如，三个审批账户如果都由同一个管理员控制，并不构成三个独立治理主体。

两个硬件模块如果共享同一更新密钥和相同固件漏洞，也可能同时失效。

上位概念

• Failure Mode
• Systemic Risk

下位概念

• Software Common-Mode Failure
• Administrative Common-Mode Failure
• Credential Common-Mode Failure
• Supply Chain Common-Mode Failure
• Policy Common-Mode Failure

相关概念

• Boundary Collapse
• Coordinated Compromise
• Layered Distrust
• Diversity
• Multi-Layer Collusion

约束机制

• 不同职责；
• 独立凭证；
• 独立更新；
• 技术多样性；
• 不同控制域；
• 共因分析；
• 灾难半径约束。

结果目标

避免架构图上的多个组件在真实失陷时仍然作为同一个单点失败。

在 Havenlon 中

Arbiter、Security Domain、SaaS 和治理成员需要评估共享密钥、共享管理员和共享更新链风险。

8. Single Point of Failure｜单点故障

一句话定义

单点故障，是某一个组件失效后，导致系统无法继续提供必要功能的设计点。

严格定义

Single Point of Failure 主要描述可用性问题。

例如：

• 唯一网络连接；
• 唯一设备；
• 唯一数据库；
• 唯一 Owner；
• 唯一 Policy 服务；
• 唯一证据存储。

单点故障并不必然等于安全问题。

一个组件失效后系统安全停止，可能是可接受的。

真正需要进一步评估的是：

• 失效后系统是否停机；
• 失效后系统是否放宽限制；
• 是否存在安全恢复；
• 是否导致永久锁死；
• 是否产生不可逆状态。

上位概念

• Availability Risk
• Failure Architecture

下位概念

• Device SPOF
• Network SPOF
• Governance SPOF
• Storage SPOF
• Identity SPOF

相关概念

• Single Point of Catastrophic Execution
• Redundancy
• Recovery
• Safe Failure
• High Availability

容易混淆的概念

单点故障回答：

一个点坏了，系统还能不能运行？

单点灾难性执行回答：

一个点失陷，能不能独自造成灾难？

两者必须分开评估。

约束机制

• 冗余；
• 故障转移；
• 离线恢复；
• 共享治理；
• 证据复制；
• 备用设备。

结果目标

减少不必要的永久不可用，同时确保冗余机制不引入执行旁路。

在 Havenlon 中

关键设备可能存在可用性单点，但备用和恢复路径必须继续遵守相同执行约束。

9. Single Point of Catastrophic Execution｜单点灾难性执行

一句话定义

单点灾难性执行，是任一单一身份、组件、凭证、管理员或硬件失陷后，可以独立完成系统级不可逆动作的状态。

严格定义

单点灾难性执行可能来自：

• Owner 可以删除所有成员并执行；
• SaaS 可以直接调用执行器；
• 单一管理员可关闭 Policy；
• 单一密钥可以控制全部资产；
• 单一 HSM 客户端可以要求任意签名；
• 单一恢复凭证可以重置全部状态；
• 单一固件签名密钥可以改写执行边界；
• 单一 Security Domain 拥有无限对象和额度。

它与普通单点故障不同。

一个组件可能不是可用性单点，却仍然拥有灾难性权力。

上位概念

• Catastrophic Authority
• Execution Risk

下位概念

• Credential Catastrophic Point
• Administrative Catastrophic Point
• SaaS Catastrophic Point
• Hardware Catastrophic Point
• Recovery Catastrophic Point

相关概念

• No Unilateral Catastrophic Authority
• Blast Radius
• Owner ≠ God
• Boundary Collapse
• Distributed Constraint

约束机制

• 权力分离；
• 多方约束；
• 物理边界；
• 限额；
• 限频；
• 作用域；
• 最终否决；
• 独立证据。

结果目标

让任何单点失陷最多造成局部、有限和可恢复影响。

在 Havenlon 中

设计评审优先识别“谁可以单独造成最大不可逆损失”，而不只识别系统可用性单点。