企业官网建设流程全解析

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

27. State-Bound Judgment｜状态绑定判断

一句话定义

状态绑定判断，是只在明确状态版本、时间和上下文中成立的判断。

严格定义

Policy 判断不应被保存为脱离状态的永久结论。

一个完整的状态绑定判断应关联：

• 请求；

• IntentHash；

• Policy 版本；

• 治理状态；

• 额度状态；

• 当前时间；

• 设备状态；

• 判断来源；

• 有效期；

• 使用次数。

状态变化后，原判断应当：

• 失效；

• 重新计算；

• 缩小作用域；

• 或要求重新审批。

上位概念

• Policy Decision

• 条件信任

下位概念

• 时间绑定判断

• 治理状态绑定判断

• 额度状态绑定判断

• 设备状态绑定判断

• 上下文绑定判断

相关概念

• Policy State

• Policy Freshness

• TOCTOU

• Final Revalidation

• Context Binding

权力边界

判断不能脱离其依赖状态被重复使用。

约束机制

• 状态哈希；

• 版本号；

• 有效期；

• 单次使用；

• 防重放；

• 执行前状态比较；

• 状态变化触发撤销。

结果目标

让 Policy 判断明确回答：

这个结果在什么状态下成立，又在什么条件变化后失效？

在 Havenlon 中

Policy 判断与 Policy Hash、治理状态、IntentHash、计数器和执行步骤绑定，不能作为通用允许令牌。

28. Limited Judgment｜有限判断

一句话定义

有限判断，是一个主体只对其可见信息和职责范围内的问题作出的判断。

严格定义

任何 Policy 都是有限判断，因为它不可能同时完整掌握：

• 用户真实意图；

• 所有业务上下文；

• 全部设备状态；

• 全部组织关系；

• 所有外部风险；

• 未来状态变化；

• 最终执行结果；

• 所有其他 Policy 的内部状态。

有限判断要求系统明确：

• 这个 Policy 能判断什么；

• 它不能判断什么；

• 它依赖哪些输入；

• 它在哪些情况下失效；

• 它的允许需要哪些其他约束共同成立。

上位概念

• Policy

• 有限信任

下位概念

• 身份有限判断

• 风险有限判断

• 审批有限判断

• 本地状态有限判断

• SaaS 有限判断

相关概念

• Limited Trust

• Policy Is Not Truth

• Policy Is Not Safety

• Policy Is Not Final Authority

• Distributed Constraint

权力边界

一个判断来源不能因为在自身范围内正确，就把结论扩张到整个执行系统。

约束机制

• 职责边界；

• 输入范围；

• 输出范围；

• 多源约束；

• 下游重新验证；

• 不允许隐式权力继承。

结果目标

让系统不再寻找一个“知道一切”的 Policy，而是让多个有限判断共同限制结果。

在 Havenlon 中

SaaS、本地设备、治理主体、Arbiter 和 Security Domain 都只掌握部分信息，因此每一层都只能作出有限判断。

Policy 结构关系总图

Policy｜策略 │ ├── Policy Source｜策略来源 │ ├── Local Policy｜本地策略 │ ├── SaaS Policy｜SaaS 策略 │ ├── Approval Policy｜审批策略 │ └── Physical Constraint Policy｜物理约束策略 │ ├── Policy State｜策略状态 ├── Policy Context｜策略上下文 ├── Policy Scope｜策略作用域 ├── Policy Validity｜策略有效性 └── Policy Freshness｜策略新鲜度 ↓ Policy Decision｜策略判断

多个 Policy 共同参与时：

Multi-Source Policy｜多源策略 ↓ Policy Aggregation｜策略聚合 ↓ 发现 Policy Conflict｜策略冲突 ↓ Policy Convergence｜策略收敛 ↓ ├── Stricter-Wins｜更严格者优先 └── Deny Dominance｜拒绝优先 ↓ 形成有限仲裁结果 ↓ 进入最终执行重新验证

Policy 风险扩张路径

Policy Source 权力过大 ↓ Policy Scope 过宽 ↓ Policy 判断脱离状态 ↓ Policy Freshness 不足 ↓ Policy Conflict 被宽松解析 ↓ 攻击者寻找 Most Permissive Source ↓ Policy Override / Bypass / Downgrade ↓ Policy Poisoning ↓ 单一 Policy 成为事实上的最终权威 ↓ 单点灾难性执行

Havenlon 的反向约束路径是：

明确 Policy Source ↓ 限制 Policy Scope ↓ 绑定 Policy State 与 Context ↓ 验证 Validity 与 Freshness ↓ 采用 Multi-Source Policy ↓ 执行 Policy Aggregation ↓ 通过 Stricter-Wins 与 Deny Dominance 收敛 ↓ Policy 只形成有限判断 ↓ 最终执行边界重新验证并保留否决权

“Policy 不是神谕”的正式含义

“Policy 不是神谕”不是说 Policy 不重要，也不是说所有规则都不可信。

它真正表达的是：

Policy 只能看到有限输入 Policy 只能使用有限状态 Policy 只能在有限时间内成立 Policy 只能影响有限作用域 Policy 只能代表某个来源的判断 Policy 无法证明自己没有遗漏关键上下文 Policy 无法单独证明最终执行结果安全

因此：

Policy 的允许，只能表示某一层没有发现拒绝理由。

它不能表示：

所有层都已经证明这件事可以安全发生。

Policy 与事实、治理、执行和证据的区别

Fact｜事实 回答：真实发生了什么？ ​ Policy｜策略 回答：按照某套规则，这件事是否满足条件？ ​ Governance｜治理 回答：谁有权参与制定和改变规则？ ​ Arbitration｜仲裁 回答：多个有限判断如何组合成当前约束？ ​ Execution｜执行 回答：什么动作最终真实发生？ ​ Evidence｜证据 回答：如何证明判断和执行过程确实发生过？

这些职责不能相互替代。

Policy 不能创造事实。

治理同意不能替代 Policy。

Policy 允许不能替代执行前校验。

执行结果不能由 Policy 自行证明。

Policy 评审问题

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

1. Policy 来自哪些来源？

2. 这些来源是否属于不同信任域？

3. 每个 Policy 的作用域是什么？

4. Policy 可以影响哪些执行能力？

5. Policy 的有效期和新鲜度如何定义？

6. 判断使用了哪些状态和上下文？

7. 状态由谁提供，是否可以被污染？

8. Policy 结果能否被重放？

9. Policy 是否绑定具体 Intent 和最终载荷？

10. 多个 Policy 冲突时如何处理？

11. 是否采用更严格者优先？

12. 哪些拒绝具有不可覆盖性？

13. 请求方能否选择最宽松 Policy 来源？

14. SaaS Policy 能否覆盖本地硬限制？

15. 管理员能否修改 Policy 后立即执行？

16. Policy 异常时系统是收紧还是放宽？

17. 恢复和降级模式是否使用更宽松 Policy？

18. Policy 变更是否需要治理和留证？

19. Policy 来源失陷后，剩余哪些独立约束？

20. Policy 是否被错误地当成最终执行权威？

如果这些问题没有明确答案，Policy 系统很可能只是在集中化地管理执行权，而不是真正约束执行权。

本章核心公理

Policy 是有限判断，不是客观事实。

Policy 判断正确，只能证明规则正确处理了输入，不能证明输入本身正确。

Policy 有效不代表 Policy 新鲜，Policy 新鲜也不代表上下文完整。

多个 Policy 的价值不是增加更多允许来源，而是增加更多独立约束。

策略聚合负责收集约束，策略收敛负责形成不比任何关键约束更宽松的结果。

更严格者优先解决可比较约束，拒绝优先解决不可被覆盖的硬性条件。

攻击者不会主动挑战最严格的 Policy，而会寻找系统仍然接受的最宽松来源。

安全降级必须减少能力；任何在异常状态下放宽执行权的模式，都是潜在攻击路径。

本地 Policy 不是天然正确，SaaS Policy 也不是天然不可信。真正重要的是，两者都不能单独拥有最终执行权。

Policy 的允许不是终点，而是最终执行重新验证的一个输入。

Havenlon 对 Policy 的基本回应

Havenlon 不取消 Policy，也不降低 Policy 的重要性。

相反，它要求 Policy 被更准确地放回自己的位置：

1. Policy 必须具有明确来源；

2. Policy 必须绑定具体状态；

3. Policy 必须绑定判断上下文；

4. Policy 必须限制作用域；

5. Policy 必须具有有效期和新鲜度；

6. Policy 结果必须绑定具体 Intent；

7. 多个适用 Policy 必须全部进入聚合；

8. Policy 冲突必须采用明确收敛规则；

9. 可比较约束采用更严格者优先；

10. 有效硬拒绝采用拒绝优先；

11. SaaS Policy 不能覆盖本地硬限制；

12. 本地 Policy 也不能成为唯一裁判；

13. 审批 Policy 不能直接替代执行；

14. 物理约束 Policy 只能限制执行，不能自行生成意图；

15. Policy 异常时必须收紧能力，而不是放宽；

16. Policy 的判断必须在最终执行前重新验证；

17. Policy 的变更、冲突和拒绝都必须留下证据；

18. Policy 永远不能单独成为灾难性执行的充分条件。

最终原则是：

Policy 不是神谕。

它只是一个有限来源，在一个有限状态、有限时间和有限上下文下作出的有限判断。

真正的执行安全，不是让某个 Policy 永远正确，而是让任何 Policy 即使错误，也不能独自把错误判断变成灾难性现实。