Deny-Overrides Policy Composition

当多个治理信号共同决定 Agent 行为时,让 hard deny 或 blocking condition 优先于 soft allow、置信度和语义评分,避免高风险规则被平均或投票覆盖。

#type / concept #status / growing #tech / ai #tech / security #tech / architecture #resource / agent

[!info] related notes

Deny-Overrides Policy Composition

一句话定义

Deny-Overrides Policy Composition 是一种策略组合原则:只要命中被定义为 hard blocking 的拒绝条件,最终决策就不能被其他 soft signal、平均分、模型 confidence 或 LLM Judge 的正面判断覆盖。

为什么需要明确组合语义

生产 Agent 经常同时拥有多种信号:

model confidence
LLM Judge score
risk classifier
critical evidence gap
permission policy
safety rule
business invariant

如果只把这些信号简单加权或投票,就可能出现:

4 个 soft allow
+ 1 个 critical deny
→ 多数票允许

对 hard safety rule 来说,这种组合方式是错误的。

Hard 与 Soft 的区别

Hard blocker
→ 命中即禁止当前动作
→ 需要先关闭 blocker 或换受控路径

Soft signal
→ 影响排序、偏好、置信度或人工复核优先级
→ 不能推翻 hard blocker

典型 hard blocker 可以包括:

  • critical evidence gap 仍为 OPEN;
  • 明确权限不足;
  • REQUIRED contract 未满足;
  • safety-critical invariant 失败;
  • 当前 case 超出批准的 Safety Envelope。

简化组合逻辑

if any(hard_blockers):
    return BLOCK

return soft_policy_decision(signals)

更复杂的系统可以有多个优先级层,但关键点不是代码形式,而是优先级必须在 policy 中显式、版本化、可测试

LLM Judge 的位置

LLM Judge 适合判断难以 deterministic 编码的语义质量,例如是否过度确定、推理是否合理处理矛盾。

它不适合承担:

"如果 Judge 很有信心,就撤销 deterministic safety block"

因为这会把原本稳定的 hard contract 降级成概率判断。

与 Eval 的关系

Hard blockers 本身应有 deterministic tests 和 protected eval slices。若要修改某个 blocker 的规则,应作为 policy/configuration change 重新评测,而不是在单次运行中临时绕过。

常见误解

  • deny-overrides = 所有规则都保守拒绝:只有被明确标记为 hard blocker 的规则拥有这种优先权。
  • Judge 更聪明,所以应该拥有最终权力:模型能力强弱和策略授权层级是两件不同的事。
  • confidence 很高可以例外:confidence 不是对缺失证据或权限边界的替代证明。
创建于 2026/8/19 更新于 2026/8/19