12 治理：审计、最小权限、human-in-the-loop

第 11 章把安全边界压到「不可信数据不得获得执行权」。边界回答的是「什么不允许发生」；治理回答的是另一半问题：如果某件事必须发生，谁在什么条件下批准它，留下什么证据，事后谁来复原。一个系统可以没有漏洞，却仍然不可治理：权限是永久的管理员，审批是聊天窗口里的一句「可以」，日志只存在应用 stdout 里，出了事只能靠当事人回忆。这种系统在演示里很安全，在事故里很脆弱。

治理常被写成一叠制度文档：安全委员会、AI 伦理准则、责任声明。文档不是没有价值，但它不改变任何一次工具调用的结果。本章只讨论可执行的部分：一个请求如何被策略判定，一个批准如何被身份约束，一个权限如何到期，一条证据如何被验证。制度只有落到这四件事上，才在系统里存在。

这一章在全书路径的末端：第 9 章给了评估，第 10 章给了 trace，第 11 章给了安全边界。治理把三者接起来——评估告诉我们风险在哪，trace 提供事实，安全边界提供拒绝能力，治理决定「例外由谁授权、证据留多久」。第 13、14 章的两个项目会把这里的策略引擎、审批流与审计日志接进真实执行器。

12.1 治理对象：谁批准、谁负责、留什么证

先看一次具体动作。退款 agent 在凌晨 02:17 发起一笔 1,250,000 分的退款，收款方是三天前刚更换的账户，订单来自生产租户 acme。系统有四个问题必须能回答，而且答案不能依赖任何人的记忆：

1. 谁批准：这笔退款经过了谁？是自动规则、单个值班人，还是两个不同的人？
2. 谁负责：如果这笔退款是错的，责任落在模型提供方、agent 产品方、审批人，还是平台运维？
3. 留什么证：事后能否拿出请求参数、策略版本、审批记录、执行回执，证明「当时确实批准过」？
4. 多久：这些证据保留多久？权限多久回收？审批多久超时？

四个问题对应治理的四个对象。它们不是四份文档，而是四组必须能相互校验的系统状态。

这张表说明什么：四者缺一不可。只有决策权没有证据，批准无法被证明；只有证据没有时效，日志会无限膨胀，临时权限会永久留存；只有责任没有决策权，复盘只能找人背锅，改不了系统。

这个定义故意把「责任」放在「决策权」旁边。很多系统只实现了一半：策略引擎能拒绝，审批流能放行，但没有人对「为什么这条规则是这样」负责。规则漂移、阈值被临时调高、审批人长期离线，这些问题不会让引擎报错，却会让治理慢慢失效。责任分配的作用，是给每个自动决定配一个能改它、也能为它解释的人。

  请求                        策略                        审批
  ┌──────────────────┐      ┌──────────────────┐      ┌──────────────────┐
  │ request_id        │      │ policy_version    │      │ approval_id       │
  │ actor / tenant    │─────▶│ rule_id           │─────▶│ approver(s)       │
  │ action / resource │      │ allow / approve / │      │ four_eyes?        │
  │ amount / env      │      │ deny + obligations│      │ deadline          │
  └──────────────────┘      └──────────────────┘      └──────────────────┘
           │                         │                         │
           │                         │  require_approval        │ approved
           │                         ▼                         ▼
           │                  ┌──────────────────────────────────────┐
           │                  │ 执行：scoped credential + 幂等键      │
           │                  │ execution_id / receipt / result       │
           │                  └──────────────────────────────────────┘
           │                                      │
           ▼                                      ▼
  ┌─────────────────────────────────────────────────────────────────────┐
  │ 审计：request → policy_decision → approval → execution → review     │
  │ 每条记录带 prev_hash/hash；链头定期锚定到 WORM 或外部时间戳          │
  └─────────────────────────────────────────────────────────────────────┘
                                      │
                                      ▼
                          证据链：可重建 / 可验证 / 可保留

读图：一条高风险动作至少产生五条独立记录——请求、策略决策、审批、执行回执、事后复核。它们由不同组件写入，通过 request_id / approval_id / execution_id 关联。五条记录齐全时，审计员可以在不知道当事人记忆的情况下回答「谁在什么时候、依据哪版策略、批准了什么参数、执行结果是什么」。缺任何一条，结论就会降级：缺审批记录，无法区分「自动放行」与「人工批准」；缺策略版本，无法复现当时的判定；缺执行回执，无法证明批准的动作真的执行了，或执行的是不是同一个动作。

12.1.1 决策权：不是「谁能用」，而是「谁能批」

决策权经常被写成角色权限：admin 可以退款，support 只能查询。这不够。退款动作至少有三个不同的权力：发起、批准、执行。把它们混在一个角色里，等于让同一个人写申请、批申请、再执行，四眼原则从一开始就不存在。

一个可执行的决策权表至少要有五列：

这张表说明什么：批准者与发起者必须是不同主体；执行凭证必须是这次动作专用的，不能是发起者手里长期持有的密钥。很多越权事故不是因为策略写错，而是因为批准之后，执行器仍然用 agent 的长期凭证去调用下游——批准只改了工单状态，没有改凭证。

12.1.2 责任：模型是组件，不是责任主体

出事后最常见的归因是「模型自己决定这么做」。这句话在工程上不成立。模型输出的是 token；把它变成工具调用、给它凭证、让它访问生产数据、允许它在没有人复核的情况下执行的，都是宿主系统。模型没有法律人格，不理解组织政策，也不能持有或归还权限。能绕过审批的从来不是模型，而是宿主给模型留的那条路径。

模型行为是系统行为的一个输入，不是并列的责任主体。责任要按「谁能改变这个决定」来分，而不是按「谁离故障最近」来分：

这张表说明什么：模型只占第一行。后面五行的每一个「是」，都是组织里某个人可以改的。把责任推给模型，实际效果是让真正能修复的环节免于被检查。模型提供方仍有责任：能力声明、已知局限、版本变更与安全公告；但授权、执行与证据属于宿主和组织，不能由提供方代为决定。

12.1.3 时效：治理有四个时钟

治理失败经常不是「没有规则」，而是「规则过期了」。四个时钟要分别设计，不能用一个「定期 review」糊过去：

这张表说明什么：四个时钟的默认方向不同。审批和权限要短，短到能限制暴露窗口；证据要长，长到能覆盖调查与追责周期；复核要紧，紧到当事人还记得上下文。把它们都设成「一年」或都设成「一天」，都会在某一边出问题。

12.1.4 最小可运行治理清单

治理不需要一次建完。一个团队可以先落地八件事，覆盖「决策、证据、时效」的最小闭环：

这张表说明什么：八件事里，第 1、3、5 件是系统能力，其余五件是流程与责任。很多团队先买日志平台，却没有人定义 schema 与保留策略，结果只是把不可用的日志存得更久。顺序应该反过来：先定事件与决策，再选存储。

12.1.5 先做哪三件

如果只能先做三件，按这个顺序：

1. 给高风险动作加审批与审计：选一个不可逆、金额大的动作，写清谁批、批什么、留什么。它立刻降低最坏损失。
2. 给临时权限加 TTL：所有非长期授权必须有到期时间；没有 TTL 的授权视为缺陷。它降低暴露窗口。
3. 建立每周一次的漂移对账：授予与使用的差集，先手工跑，再自动化。它让前两件不会慢慢失效。

三件都做完，再考虑策略语言、WORM、合规映射。反过来，先上策略引擎却没有审批人与证据，只会把「没有控制」变成「有代码但没有控制」。

12.2 审计：事件、不可篡改、保留期与证据链

审计的第一性原理不是「多记」，而是事后能否在不知道当事人记忆的情况下重建一次动作。这要求每条记录回答六个问题：谁（who）、做了什么（what）、何时（when）、为什么（why）、依据哪版策略（policy_version）、结论是什么（decision），并留下能指向原始证据的引用（evidence）。少一个问题，重建就会断。

字段不能凭感觉定。下面这张表给出一组最小字段与缺失后的直接后果：

这张表说明什么：policy_version 与 params_digest 是最容易被忽略、却最影响复现的两列。没有版本，你只能知道「当时被批准了」，不知道「当时的规则是否允许」；没有参数摘要，你无法证明执行的回款账户与批准时看到的是同一个。

一条真实形态的事件如下（来自本章实验的 JSONL，字段略有删节）：

{
  "seq": 2,
  "event_id": "evt-000002",
  "recorded_at": "2026-10-19T09:00:01Z",
  "event_type": "policy_decision",
  "actor": "support-3",
  "action": "refund",
  "resource": "invoice:INV-2091",
  "resource_tenant": "acme",
  "policy_version": "2026.10.1",
  "decision": "require_approval",
  "obligations": ["four_eyes", "finance_ticket"],
  "evidence": {
    "request_id": "req-002",
    "reason": "退款金额超过 500000 分，需要人工审批",
    "matched_rule": "require-approval-high-value-refund",
    "context": {"amount_cents": 1250000, "environment": "prod", "reversible": false}
  },
  "prev_hash": "6a1f...",
  "hash": "b73c..."
}

这条事件能回答「谁、做了什么、为什么需要审批、按哪版策略」，但它不能单独证明「谁批准了」。批准是另一条事件，带自己的 actor、approval_id 与 wait_s。把两者混在一条记录里，四眼原则就无法被机械校验。

12.2.1 append-only、WORM 与哈希链：三层不是一回事

「不可篡改」经常被当成一个开关：买个 WORM 桶，或者加个哈希链，就宣称审计不可篡改。实际上这是三层不同的保证，成本与威胁模型都不同：

这张表说明什么：三层要叠加。只有追加写，内部人可以直接改文件；只有 WORM，写进去的错误内容仍然错误；只有哈希链，能重写整条链的人可以重算所有哈希。外部锚定是关键：把链头哈希定期写到另一个信任域（独立账号、时间戳服务、纸质归档），攻击者要同时攻破两个域才能自洽。

定理的边界比结论更重要。它假设：哈希函数抗第二原像；验证方拿到的链头确实可信；链没有在尾部被截断。截断是哈希链的常见盲点：攻击者删掉最后几条记录，剩下的链仍然自洽。对策是记录「预期条数/最后序号」并一起锚定，或者用外部系统记录每个时间窗口的链头。另一个盲点是密钥与写权限：如果签名密钥和执行器在同一台机器上，攻击者可以签一条新的历史。

12.2.2 保留期与 PII 最小化：记多久与记多细

审计日志本身也是数据，也会包含个人数据。保留期太长，违反最小化；太短，事故发生时已经过期。可行的做法是按证据价值分层，而不是按「全部保留七年」一刀切：

这张表说明什么：审计事件里不要放自由文本和完整参数。需要原文时，存引用而不是副本：evidence_ref 指向一个访问受控、保留期更短的 trace 存储。这样审计日志可以长期保留而不成为 PII 仓库；调查时再按权限取原文，并记录「谁在何时看了哪条证据」。

PII 最小化的三个具体动作：

1. 字段白名单：审计写入器只接受预定义字段，拒绝任意 dict。实验里的 sanitize_context() 只保留金额、环境、是否可逆等策略字段，就是这一条的最小实现。
2. 令牌化：主体 id 用内部 pseudonym，资源 id 用不可逆哈希或代理 id；需要映射时走独立权限。
3. 访问审计：读取审计日志本身也要记事件。否则「谁看过这笔退款的证据」永远无法回答。

12.2.3 不可抵赖：哈希链不证明「是他签的」

审计的最后一个要求是不可抵赖（non-repudiation）：当事人事后不能否认自己做过这个决定。哈希链只证明「这条记录没有被改」，不证明「这条记录确实由声称的人写下」。两者之间隔着身份、签名与意图。

这张表说明什么：actor 字段只是声称，不是证据。没有强认证与签名时，最坏情况是「有人用共享账号点了同意，事后所有人都否认」。高风险动作的审批记录应该由审批服务签名，签名覆盖 approval_id、参数摘要、审批人、时间与决定；验证方用公钥独立验证，而不是相信数据库里的 approved_by 列。

不可抵赖不是所有动作都需要的成本。低风险自动批准只需可追溯；高风险、对外、涉钱的审批才值得上签名与强认证。判断标准与 12.4 的审批点一致：越不可逆、越跨边界，越需要「无法否认」而不是「大概记得」。

12.2.4 证据链：重建一次高风险动作

req-8842    request      support-3  refund invoice:INV-2091  amount=1250000  env=prod
dec-8842    policy       policy-engine  require_approval  rule=high-value-refund  v=2026.10.1
apr-8842    approval     finance-2 -> finance-4  two distinct approvers  wait=150s
exe-8842    execution    payments.refund  idempotency=refund-INV-2091-v1  receipt=pay_7f31
rev-8842    review       risk-1  sampled=true  conclusion=valid  evidence=trace:8f3a

12.3 最小权限：工具级、数据级、时间级与 JIT

第 4 章讲的是内核机制：uid、capability、seccomp、landlock。它们回答「进程能做什么」。这一节讲的是授权生命周期：一个 agent 在什么条件下、对哪部分数据、在多长时间内、在哪个环境里，能调用哪个工具。内核边界再严，如果执行器给 agent 一个永久的生产管理员 token，最小权限仍然是空话。

最小权限要同时收四层。只收一层，另外三层会把它抵消：

这张表说明什么：四层是乘法关系，不是加法。工具级收了，但数据级没过滤，agent 仍可读全量；数据级过滤了，但凭证永久有效，攻击者可以慢慢利用；环境级分离了，但 staging 用生产数据副本，风险又回来了。

12.3.1 权限租约：把「授予」变成「有期限的借用」

角色（role）适合描述长期职责，不适合描述一次动作。agent 的一次退款、一次导出、一次排障，需要的是参数化、短时、可审计的授权。这就是权限租约（lease）。

租约与角色的区别，用一张表最清楚：

这张表说明什么：角色不是没用，它是租约的上限。租约不能超过角色允许的 scope；角色决定「你能申请什么」，租约决定「这次你能做什么」。两层都要有，缺一层就会出现「角色很大但没人用」或「租约很细但可以无限续」。

一个租约的 JSON 形态如下：

{
  "lease_id": "lease-7f3a91",
  "subject": "agent-refund-3",
  "tool": "payments.refund",
  "data": {"tenant": "acme", "invoice_prefix": "INV-2"},
  "environment": "prod",
  "not_before": 1792376100,
  "expires_at": 1792377000,
  "issued_by": "policy-engine@2026.10.1",
  "obligations": {"max_amount_cents": 500000, "idempotency_key_required": true}
}

租约里的时间统一用 Unix 秒，避免时区与字符串比较。执行器侧的检查必须是 fail-closed 的。下面这段是示意，不是本章实验的一部分；重点是检查顺序与默认值：

def lease_allows(lease: dict, request: dict, now: int, revoked: set[str]) -> bool:
    if lease["lease_id"] in revoked:
        return False
    if not (lease["not_before"] <= now < lease["expires_at"]):
        return False
    if lease["tool"] != request["tool"] or lease["environment"] != request["environment"]:
        return False
    if lease["data"]["tenant"] != request["tenant"]:
        return False
    if request["amount_cents"] > int(lease["obligations"].get("max_amount_cents", 0)):
        return False
    return True

四个细节：时间用同一时钟源；revoked 集合要能被策略引擎写入；义务检查失败必须拒绝而不是降级；每次检查都要把 lease_id 写进审计事件。少了最后一条，事后无法证明「这次调用用的是哪条租约」。

12.3.2 JIT：权限在需要时出现，在不需要时消失

JIT（just-in-time）不是「申请更快」，而是「默认没有，用时才发，到期就收」。一个可执行的 JIT 流程有六步：

1. 请求：agent 提交动作、资源、理由、预计时长；不接受「给我 admin」这种无参数请求。
2. 求值：策略引擎按主体、动作、资源、上下文给出 allow / require_approval / deny。
3. 批准：高风险动作走 12.4 的审批；低风险可按规则自动。
4. 签发：凭证服务签发短时租约；TTL 由风险等级决定，不由申请人决定。
5. 使用：执行器每次调用检查租约与义务，并写使用记录。
6. 回收：到期自动失效；提前完成则主动撤销；异常使用触发撤销与复核。

JIT 的关键指标不是「签发速度」，而是暴露窗口：

$$\text{暴露窗口} = \sum_{\ell \in L} (t_1(\ell) - t_0(\ell)) \cdot \mathbf{1}[\ell \text{ 被使用}].$$

窗口越短，凭证泄露后可利用的时间越短。但窗口不能短到正常任务无法完成，否则会诱导用户申请更长的 TTL，反而扩大风险。合理的做法是按任务类型设定上限，并在任务完成时主动撤销，而不是让租约自然到期。

这个定理看起来近乎同义反复，但它的三个前提正是事故现场最常见的缺口：执行器缓存了「已授权」的布尔值；续期接口只要一个 refresh token；容器时钟漂移导致过期判断晚了几分钟。定理的价值不在证明，而在把这三个前提变成检查项。

12.3.3 break-glass：把例外变成可复核的流程

break-glass 是治理里最危险、也最容易被滥用的机制。它的目的不是「绕过审批」，而是在事故中把审批挪到事后，同时提高证据等级。一个可执行的 break-glass 至少要满足六条：

这张表说明什么：break-glass 的成本要高于正常审批，而不是低于。如果 break-glass 比走审批更快、更省事，它就会成为默认路径；那时它不再是例外，而是绕过的后门。

12.3.4 权限漂移：实际使用与授予的差集

权限不会一次性配错，它会慢慢漂移：临时授权忘了收、转岗后角色没换、工具升级后 scope 变宽、共享账号被多人使用。检测漂移不需要等审计，只要定期对比两个集合：

• $G$：当前授予的权限集合（按主体、scope、资源）；
• $U$：窗口期内实际使用的权限集合。

两个差集分别对应两类问题：

$$\text{未使用授予} = G \setminus U,\qquad \text{未授予使用} = U \setminus G.$$

前者是回收候选：授予了但从未使用，说明权限过宽或主体已不需要。后者是事故候选：使用了但从未授予，说明越权、旁路、共享凭证或日志缺口。两类都要查，但优先级不同：未授予使用优先，因为它可能正在发生。

这张表说明什么：漂移检测的输出不是一张报表，而是工单。每条 unused 要有回收期限与责任人；每条 ungranted 要有调查结论。没有处置的检测，只是让报表变长。

实验里的 detect_permission_drift() 就是这两个差集的最小实现：

python3 - <<'PY'
import sys
sys.path.insert(0, "experiments/ch12")
from policy_engine import detect_permission_drift
report = detect_permission_drift(
    {"agent-1": {"repo:read", "prod:deploy"}},
    {"agent-1": {"repo:read"}, "agent-2": {"secret:read"}},
)
print(report.to_dict())
PY

{'clean': False, 'unused': {'agent-1': ['prod:deploy']}, 'ungranted': {'agent-2': ['secret:read']}}

真实系统里，G 来自 IAM/租约库，U 来自执行器的使用日志；两边都要有稳定的主体 id 与 scope 命名，否则差集会充满假阳性。漂移检测的第一项工程任务不是写查询，而是统一命名。

12.3.5 权限评审：从定期 review 到持续对账

季度权限 review 的典型失败是「看表格点确认」：表格列的是角色与授予，不列实际使用；评审人没有上下文，只能全部保留。把 review 改成持续对账，能同时降低风险和评审成本：

这张表说明什么：review 的对象要从「权限清单」变成「差异与事件」。前者只会得到「都还需要」；后者会得到具体的回收、调查与策略变更。评审人不需要看几百行授予，只需要看几十条有差异的记录。

12.4 Human-in-the-loop：审批点、四眼原则与超时

Human-in-the-loop 最常见的失败不是「没有人」，而是「人出现在错误的位置」。如果审批发生在动作已经执行之后，人只能事后追认；如果审批请求里只有一句「是否同意」，人只能凭感觉点；如果每个低风险动作都要审批，人会在第 200 次点击时失去注意力。审批点的选择，比审批界面的设计重要一个数量级。

12.4.1 在哪里放审批点

审批点应该放在不可逆、影响面大、信息不对称的地方。四个判据最常用：动作是否可逆、金额/影响是否超过阈值、是否跨租户或跨边界、是否首次执行。任一为真，就值得一个人看一眼；多个为真，就需要两个人。

这张表说明什么：审批强度要和可逆性成反比。可逆动作可以自动，因为错了能回滚；不可逆动作必须审批，因为错了只能赔偿。把审批均匀撒在所有动作上，等于把最需要注意力的人耗在不需要看的事情上。

12.4.2 审批请求：给证据，不给一大段日志

审批人不是调试者。他在 30 秒内要判断的是「这个动作是否应该发生」，而不是「这个 agent 的内部状态是什么」。因此审批请求必须是一张证据卡，而不是日志导出。

九项里最容易被删掉的是 $\Delta$ 与 $\rho$。只写「申请退款 1.25 万」，审批人无法判断收款账户是否变更；只写「回滚服务」，审批人无法判断回滚到哪个版本、是否会丢数据。一个实用的审批卡长这样：

动作      refund  invoice:INV-2091  (acme / prod)
金额      1,250,000 分（¥12,500.00）
差异      收款账户 2026-10-16 由 A 改为 B；B 为新账户（3 天）
影响      单笔；该客户本月第 1 次退款；不可逆
回滚      不可回滚；可发起追回工单，预计 3–5 个工作日
依据      政策 v2026.10.1 / high-value-refund；风控分 0.82（高）
证据      trace:8f3a  diff:acct-change  history:INV-1880 同类已退
超时      15 分钟未批 → 拒绝；拒绝后可补充材料重新提交
请求者    support-3；替代方案：先冻结账户，等待 24h 人工核验

这张卡的信息量大约是一屏。它不包含 prompt、不包含模型自述、不包含几十行工具日志；它包含审批人真正需要的六个判断：做什么、改什么、影响多大、能不能回滚、凭什么、来不及怎么办。

12.4.3 四眼原则：两个独立的人，而不是两个会话

四眼原则（four-eyes principle）要求至少两个独立主体参与批准。工程上，「独立」至少包含四层：

这张表说明什么：两个会话不等于两个人。共享账号、代点、批量批准都会让四眼退化成一眼。技术上的最小校验是：approver != requester、approver 去重、审批对象是参数摘要的哈希、两次批准记录各自带时间与身份。更强的做法是要求不同认证器（密码 + 硬件密钥），或不同团队的角色。

四眼不是越多越好。三个人审批一个低风险变更，不会提高安全性，只会提高「找两个人一起点」的社交成本。审批人数应与风险等级挂钩：中风险 1 人，高风险 2 人，关键动作 2 人且其中一人来自安全/风控。人数之外，还要规定谁不能批：发起者、受益人、直接下属、与被审批动作有利益冲突的人。

12.4.4 超时与降级：默认拒绝，而不是默认放行

审批一定会遇到「没人看」。超时行为必须在设计时写死，不能留给值班人临场决定。三种可选策略：

这张表说明什么：不能自动放行高风险动作。超时的默认结果必须是「没有发生」，而不是「视为同意」。如果业务无法接受拒绝，正确做法是提前扩容审批人、缩短审批链、把动作拆成可逆的小步，而不是把超时改成同意。

一个审批状态机至少要有五个状态：pending、approved、denied、expired、cancelled。每个状态转移都要写一条审计事件，带 wait_s 与 degraded_to。超时事件要记录「当时还差几个人」「最后一次提醒在何时」「升级给了谁」，否则事后无法区分「没人看」与「系统没通知」。

12.4.5 审批疲劳：注意力是有限预算

审批疲劳不是态度问题，是负载问题。当一个审批人每小时收到 40 条请求，每条只有 7 秒处理时间，他的最优策略就是点「同意」——不是因为不负责，而是因为拒绝需要调查，而调查没有时间预算。疲劳的根因通常不是人少，而是审批点放得太多、请求信息太差、批量操作太方便。

可观测的疲劳指标：

这张表说明什么：批准率高不一定是好事。如果高风险请求也以 98% 通过、中位停留 6 秒，说明审批没有产生信息，只是在产生记录。此时应该做的不是加人，而是把低风险请求移出人工队列：提高自动批准上限、按风险路由、对低风险做抽样而不是逐条审批。

批量批准要单独限制。低风险的批量操作可以保留，但高风险动作必须逐条批准，且每条都绑定自己的参数摘要。一个常见的反模式是「全部批准」按钮把 30 条请求一起通过，其中一条是跨租户导出；审计记录上看似有 30 个批准，实际上只有一次注意力。

12.5 策略即代码：OPA/Cedar 思路与决策日志

当策略只存在于文档或代码的 if 分支里，它会有三个问题：无法独立测试、无法解释一次决定、无法安全地灰度。策略即代码（policy as code）要解决的就是这三件事：把策略从业务代码里抽出来，变成有版本、有测试、有决策日志的构件。

12.5.1 三种形态：硬编码、外部策略引擎、授权语言

这张表说明什么：不是所有系统都需要 OPA。策略少、变更慢时，硬编码加上良好的测试也能工作；但一旦出现「不同租户不同限额」「不同环境不同审批人」「监管要求按地区变化」，策略就会从几个 if 变成一张矩阵，此时外部化才划算。

12.5.2 Rego 与 Cedar：两种思路，不写语言教程

OPA（Open Policy Agent）用 Rego 描述「输入文档是否满足条件」。它的典型形态是：宿主把请求打包成 JSON，交给 OPA 求值，得到 allow/deny 或结构化决策。下面是一段示意，不是完整策略：

package agent.authz

default allow := false

deny if {
    input.subject.tenant != input.resource.tenant
}

require_approval if {
    input.action == "refund"
    input.context.amount_cents > 500000
    input.subject.tenant == input.resource.tenant
}

allow if {
    input.action == "read"
    input.subject.tenant == input.resource.tenant
}

三段规则可以同时为真。Rego 只负责求值，优先级必须由调用方显式定义；本章实验用 deny > require_approval > allow 的保守顺序。若把优先级交给规则书写顺序，策略行为会随文件重排而变。Rego 的强项是通用：输入是任意 JSON，策略可以遍历数组、引用数据文档、组合多个包。它适合基础设施授权、Kubernetes 准入、跨服务统一策略。代价是：输入 schema 靠约定，复杂策略的调试成本不低，性能取决于求值方式。

Cedar 走另一条路：实体（principal/resource）、动作、上下文都是类型化的，策略是 permit/forbid 规则，forbid 默认覆盖 permit。它的典型形态：

permit (
    principal,
    action == Action::"read",
    resource
) when {
    principal.tenant == resource.tenant
};

forbid (
    principal,
    action,
    resource
) when {
    principal.tenant != resource.tenant
};

Cedar 的强项是可分析：类型化让策略可以静态检查，forbid 覆盖让「默认拒绝」更容易表达。它适合应用内的细粒度授权，尤其是多租户 SaaS。代价是：实体模型要先设计好，跨系统的通用策略不如 Rego 自然。

这张表说明什么：两者都能表达 allow 与 deny；本章的 require_approval 需要引擎把「审批」作为结构化输出（例如 obligations 或单独的 decision 实体），不能只返回一个布尔。选型时先看输入是否稳定、是否需要跨系统复用、团队是否能维护，而不是看语法是否优雅。语言不是治理的难点，输入契约与版本管理才是。

12.5.3 策略生命周期：测试、影子、灰度、回滚

一个可执行的策略生命周期有六步：

1. 建模输入：定义主体、动作、资源、上下文的 schema；拒绝自由文本进入策略。
2. 写规则与测试：每条规则至少一个 allow、一个 deny、一个边界用例；测试和策略同仓库。
3. 影子模式（dry-run）：新策略只计算、不执行，把「新旧决策差异」写进日志；差异率高就先查输入。
4. 灰度：按租户/动作/比例启用；高风险动作先小范围，保留快速回滚开关。
5. 强制：全量启用；决策日志带策略版本与包哈希；异常决策告警。
6. 复盘与下线：定期清理不再命中的规则；删除前确认没有流量与审计依赖。

每条规则至少配三行测试，测试与策略同仓库、同一次代码评审：

这张表说明什么：测试要覆盖「允许、拒绝、审批、边界、异常」五类，而不是只测 happy path。边界用例尤其重要：> 与 >= 的一字之差，会让审批阈值在真实金额上失效。

影子模式是这里最重要的工程实践。它把「策略变更」从一次不可逆的生产切换，变成一次可比较的实验：

旧策略: allow         新策略: require_approval   diff: 12 条/小时
旧策略: deny          新策略: allow              diff: 3 条/小时   ← 优先审查

第二行最危险：新策略放宽了原本被拒绝的请求。每一条差异都要有人解释：是修 bug，还是放宽了边界？没有解释的放宽，不应该上线。

12.5.4 决策日志：策略的「执行回执」

策略引擎每次求值都要留下决策日志，字段与 12.2 的审计事件对齐：input_digest、policy_version、bundle_hash、decision、rule_id、obligations、latency_ms。日志要能回答三个问题：这次为什么是这个结果、当时用的是哪版策略、如果换成新策略会怎样。

{
  "request_id": "req-002",
  "input_digest": "sha256:5c1e...",
  "policy_version": "2026.10.1",
  "bundle_hash": "sha256:9a0d...",
  "decision": "require_approval",
  "rule_id": "require-approval-high-value-refund",
  "obligations": ["four_eyes", "finance_ticket"],
  "latency_ms": 2
}

四个常见坑：

• 策略求值与执行之间的 TOCTOU：策略看到的是旧属性，执行时属性已变。对策是把决策绑定到输入摘要，执行器拒绝摘要不匹配的请求。
• 义务不执行：策略返回 four_eyes，执行器只检查了 allow。对策是把 obligations 变成执行器的强制参数，而不是注释。
• 版本漂移：决策日志记了版本，但策略包没有哈希；同名版本被覆盖后无法复现。对策是版本 + 内容哈希双记录。
• 策略蔓延：规则越加越多，没人知道哪条还在生效。对策是命中率统计与定期清理，删除前跑影子模式确认无差异。

12.6 合规映射：NIST AI RMF、ISO 42001 与 EU AI Act

合规不是把法条抄进代码，而是把外部要求翻译成可检查的工程产物。同一件事通常有三种说法：框架说「建立治理职能」，标准说「形成文件化信息」，法条说「实施风险管理体系」。工程师需要的是第四种说法：哪个字段、哪条日志、哪个测试、谁签字。这一节只做这种翻译，不解释法律条文，也不构成法律意见。

12.6.1 NIST AI RMF：四个函数与生成式 AI Profile

NIST AI Risk Management Framework（AI RMF 1.0，2023）是自愿性框架，不是认证；它把 AI 风险管理组织成四个函数：Govern、Map、Measure、Manage。它们不是四个阶段，而是持续循环的四类活动：

这张表说明什么：Govern 不是「写一份治理文档」，而是把另外三个函数需要的决策权、证据与时效定下来。没有 Govern，Map 会变成一次性清单，Measure 会变成没有阈值的报表，Manage 会变成出了事再开会。

NIST 的 Generative AI Profile（NIST AI 600-1，2024）在 AI RMF 之上补充了生成式 AI 特有的风险，例如 confabulation、信息完整性、知识产权、数据隐私、信息安全和有害内容。对 agent 系统，最直接的可执行项是：

• confabulation：把「模型声称完成」与「系统验证完成」分开；工具结果与验收测试进入 trace。
• 数据隐私：审计事件最小化；训练/检索数据来源可追溯；删除请求有执行路径。
• 信息安全：prompt injection 的边界在能力隔离与出口约束，见第 11 章。
• 信息完整性：对外发布的内容要有来源与人工复核点，尤其是高影响领域。

12.6.2 ISO/IEC 42001：管理体系落到文件与记录

ISO/IEC 42001:2023 是 AI 管理体系（AIMS）标准，结构沿用 ISO 管理体系的高层结构：组织环境、领导作用、策划、支持、运行、绩效评价、改进。它要求组织建立 AI 政策、角色与职责、风险评估与处置、生命周期管理、供应商管理、事件管理、监视与内部审计。

工程上可以把它压成一张「文件 → 记录 → 证据」表：

这张表说明什么：认证审核看的是「你说有，能不能拿出来」。如果审批日志只有 7 天、策略版本没有哈希、事故复盘没有整改项，管理体系文件再完整也补不上证据缺口。反过来，证据齐全但没人定期看，也不构成「监视」。

12.6.3 EU AI Act：时间表与工程可执行项

EU AI Act 的适用是分阶段的。下表按公开时间线整理，具体适用日期以欧盟官方最新发布为准：

2025 年 11 月，欧盟委员会提出 Digital Omnibus，其中包含对 AI Act 部分义务适用时间的调整建议。截至本书写作时，高风险系统的最终适用时间仍可能变化；不要把它当成已经钉死的日期。 工程上应做的是：按当前官方时间表规划，但把「合规日历」做成可配置项，而不是写死在代码里。

对 agent 系统，EU AI Act 中最直接的工程可执行项是：

这张表说明什么：合规条款最终都要落到「一条记录 + 一个负责人 + 一个时限」。如果某个条款找不到对应的记录，它就没有被工程化；如果找到了记录但没人负责，它就没有被治理。

合规映射的终点不是一张对照表，而是证据清单：每个控制项都能指向一条可验证的记录，每条记录都有负责人和保留期。第 12.8 节的实验把其中最小的一环——策略决策与审批记录——跑成可执行的代码；其余环节（风险登记、技术文档、事件报告）需要在组织流程里落地。

12.7 失败案例：审批疲劳、日志缺失与权限漂移

三个案例分别对应治理四元组的不同缺口：审批疲劳是决策权与注意力的问题，日志缺失是证据的问题，权限漂移是时效的问题。案例中的数据经过脱敏与取整，但触发条件、观测证据与修复路径都来自可复现的工程模式。

02:14:01 INFO  tool=db.migrate action=delete target=orders_v2
02:14:01 INFO  result=ok rows=0
02:14:02 INFO  task finished

三个案例的共同模式可以压成一张表：

这张表说明什么：三个案例都不是「模型变坏了」。它们分别是路由、证据、时效的工程缺口；修复也都不需要换模型，只需要改策略、日志与权限生命周期。

12.8 实验：策略引擎 + 审批工作流

实验把本章的三条主线压成可运行的最小件：策略求值与版本、审批状态机与四眼/超时/break-glass、审计哈希链与权限漂移。全部只依赖 Python 3.11+ 标准库，时钟与输入都是确定的，输出可逐字复现。

实验目录是 experiments/ch12/，四个文件分工如下。

12.8.1 文件与运行

cd agent-systems
python3 experiments/ch12/policy_engine.py demo --log /tmp/ch12-decisions.jsonl

真实输出（macOS，Python 3.13.13）：

[           allow] req-001 read    invoice:INV-1042       rule=allow-own-tenant-read              policy=2026.10.1 dry_run=false
[require_approval] req-002 refund  invoice:INV-2091       rule=require-approval-high-value-refund policy=2026.10.1 dry_run=false
                   obligations=four_eyes,finance_ticket
[            deny] req-003 delete  db:prod-orders         rule=deny-prod-destructive              policy=2026.10.1 dry_run=false
[require_approval] req-004 export  table:customers        rule=require-approval-sensitive-export  policy=2026.10.1 dry_run=true
                   obligations=data_owner_approval,watermark
log=/tmp/ch12-decisions.jsonl events=3
chain=chain OK events=3

四行分别演示：同租户只读被允许；大额退款需要审批；生产删除被拒绝；敏感导出在 dry-run 下只计算、不写日志。最后一行 events=3 是 dry-run 的直接证据——四条决策只落了三条。

python3 experiments/ch12/approval_flow.py demo --log /tmp/ch12-approvals.jsonl

[1] read     invoice:INV-1042         risk=low      status=approved mode=auto        approvers=[] wait=0s
[2] update   config:checkout          risk=medium   status=approved mode=human       approvers=['sre-lead'] wait=90s
[3] refund   invoice:INV-3099         risk=high     status=approved mode=human       approvers=['finance-2', 'finance-4'] wait=150s
[4] export   table:customers          risk=critical status=denied   mode=human       approvers=[] wait=300s
    degraded_to=deny_and_page_oncall reason=timeout
[5] rollback service:checkout         risk=critical status=approved mode=break_glass approvers=[] wait=0s
    post_review_due=2026-10-20T10:18:20Z incident=INC-2026-1019

rejected attempts:
  support-3    apr-003 reason=self_approval

stats:
  submitted=5 auto=1 human=2 timeout=1 break_glass=1 rejected=1
  approval_rate=0.667 mean_wait_s=120.0 anomalous_release=1
  chain=chain OK events=12 ok=true
log=/tmp/ch12-approvals.jsonl

五步覆盖五种路径：低风险自动、中风险单人、高风险四眼（含自批被拒）、超时拒绝并记录降级动作、break-glass 带事件号。实验状态机只保留 pending / approved / denied 三态；生产还要补 expired / cancelled，以及对应的通知与撤销路径。approval_rate=0.667 的分母是「人工批准 + 超时」，不含自动批准与 break-glass；anomalous_release=1 只统计 break-glass，因为它是唯一绕过常规审批的放行。

12.8.2 测试与观测

python3 -m unittest discover -s experiments/ch12 -q

----------------------------------------------------------------------
Ran 16 tests in 0.006s

OK

耗时随机器变化；测试数量与断言内容是判据。测试里最值得看的是四条负向断言：

• test_default_deny：没有规则命中时必须是 deny；
• test_policy_error_fails_closed：规则条件抛异常时不能跳过，必须 deny；
• test_timeout_fails_closed：到达 deadline 仍未凑够人数 → denied，且审计带 wait_s=600；
• test_break_glass_requires_incident_and_is_audited：无事件号拒绝，有事件号放行但写 post_review_within_24h。

从审计日志统计审批通过率、平均等待与异常放行，可以用实验自带命令，也可以直接用 jq：

python3 experiments/ch12/approval_flow.py stats /tmp/ch12-approvals.jsonl

submitted=5 auto=1 human=2 timeout=1 break_glass=1 rejected=1
approval_rate=0.667 mean_wait_s=120.0 anomalous_release=1

jq -s '{granted: ([.[] | select(.event_type == "approval_granted")] | length),
        timeout: ([.[] | select(.event_type == "approval_timeout")] | length),
        break_glass: ([.[] | select(.event_type == "break_glass_used")] | length),
        mean_wait_s: ([.[] | select(.event_type == "approval_granted") | .evidence.wait_s] | (add / length))}
       | . + {approval_rate: (.granted / (.granted + .timeout))}' /tmp/ch12-approvals.jsonl

{
  "granted": 2,
  "timeout": 1,
  "break_glass": 1,
  "mean_wait_s": 120,
  "approval_rate": 0.6666666666666666
}

这条查询说明什么：approval_rate 只应由「有明确结论的人工审批」计算；把自动批准塞进分母，会让通过率虚高；把 break-glass 塞进分子，会掩盖「绕过常规审批」的比例。指标口径要在代码里写死，而不是在报表里解释。

12.8.3 代码骨架：三个关键判断

策略引擎的核心只有十几行，但三个顺序不能错：

def evaluate(self, request):
    for rule in self.bundle.ordered():      # 高优先级 + 更保守的 tie-break
        try:
            hit = rule.matches(request)
        except Exception:                    # 策略写错时 fail-closed
            return Decision(..., decision="deny", reason="policy_error")
        if hit:
            return Decision(..., decision=rule.effect, matched_rule=rule.id)
    return Decision(..., decision="deny", reason="default_deny")

审批状态机的四个判断同样是顺序敏感：

if approver == request.requester:
    reject("self_approval")
elif approver in state.approvers:
    reject("duplicate_approver")
elif APPROVER_ROLE not in roles:
    reject("role_not_allowed")
elif risk.requires_security and "security" not in roles and not already_has_security:
    reject("security_approver_required")

先查身份，再查重复，再查角色，最后查风险特例。顺序反了会出现「先记了一次批准，再发现是自批」的脏状态。审计日志的哈希链则只有一条规则：hash 覆盖除自己以外的全部字段，prev_hash 指向上一条；任何字段变动都会让后续链断掉。

12.8.4 从实验到生产：还缺什么

这个实验刻意省略了生产必需的六件事，读者不应把它直接部署：

这张表说明什么：实验证明的是语义——优先级、默认拒绝、四眼、超时、break-glass、哈希链——不是生产强度。把语义跑对，再接身份、存储与通知，比先接一堆基础设施却说不清策略语义更可靠。

母本对应

读这张表要抓住两点：合规框架只提供要求的方向，不提供实现；本书对 OS 与安全章节只做交叉引用，不重复讲 capability 与 seccomp 的内核细节。表中「背景」表示正文只借用概念与术语，读者需要时再回母本。

本章陷阱

这张表说明什么：十二个陷阱里，只有第 2 个是「归因错误」，其余都是可落地的工程缺口。它们不会因为换模型、换框架而消失；第 9 与第 11 条最危险，因为它们让「有审批」看起来像「有控制」。

本章出口检查

下一站：13 项目一：可沙箱执行的代码 agent 把本章的策略、审批与审计接进一个真实的执行器：工具注册、沙箱、限额、trace 与红队用例。