第 12 章：权限、安全与审计：信任边界
12.1 工程问题的本质：多层信任与纵深防御
智能体系统存在多个信任环节：用户身份是否可信、角色能否做此操作、属性是否允许、输入是否被注入、输出是否泄露、操作是否留痕。单一防线失效即可造成损失——因此信任必须分层，任一层的突破不能直接导致系统失守。
设计原理： 纵深防御（defense in depth）在智能体系统的具体形态是：认证 → 授权（RBAC/ABAC）→ 职责分离（SOD）→ 输入输出防线 → 操作级审核链。每一层只回答一个问题，层间不互相依赖——授权层不能因为"认证过了"就放行，审核链不能因为"规则过了"就跳过确认。
12.2 访问控制：角色与属性的双重判定
权限模型的原则：RBAC 决定"能不能做"，ABAC 决定"在当前属性下能不能做"，两者均通过方可放行。
原理： RBAC（角色访问控制）将权限管理从"逐人授权"抽象为"角色-权限"两层，降低管理复杂度；但角色粒度无法表达情境——同样的角色，金额不同、订单状态不同、所属部门不同，权限应不同。ABAC 补上这一维度：部门属性（销售部不可排产）、金额范围（超 50 万需 admin）、订单状态（已发货不可改）。RBAC 管角色，ABAC 管情境，二者并用是生产系统的标准形态。
角色审批能力矩阵与权限矩阵可训练（存配置），但有一个不可训练项：can_block_override 恒为 False——所有角色（含 admin）均不可绕过硬规则。这是第 6 章第一条约束的权限层落地：权限是授予操作的，不是授予规则的。
12.3 SOD：职责分离的防舞弊原理
SOD 定义不相容权限对：同一用户不可同时拥有"执行"与"审批"同一类操作的能力（接单 vs 审批订单、报工 vs 工资确认、采购 vs 付款审批）。
原理： SOD 针对的不是外部攻击，而是内部舞弊。舞弊成立的充要条件是"一个人能完成闭环"——执行、确认、审批全在自己手里。SOD 通过切断闭环中的关键链路，使任何单点操作都必须引入第二人。因此 SOD 规则是安全铁律：不可被训练修改（防止通过训练给自己开绿灯）、不可被 admin 绕过（防止特权者重建闭环）。
12.4 输入输出防线：四道关卡
智能体与模型交互的防线：提示注入检测（输入侧，阻断"忽略以上指令"类攻击与 SQL 注入）、输出敏感信息过滤（输出侧，致命模式阻断、普通模式打码）、权限与数据访问控制（角色层级 + 数据归属）、操作频率限制（防滥用）。
原理： 输入侧与输出侧防线的不对称性值得注意：输入侧拦截的是"攻击意图"，输出侧拦截的是"泄露事实"。前者失败会执行错误操作，后者失败会泄露敏感信息——两者都不可由模型自纠，必须由确定性模式检测兜底。频率限制则把"合法但异常"的滥用（批量拉取、高频探测）挡在资源层之外。
12.5 七层审核链：操作级治理与可证明性
关键操作须经过七层审核方可落库：身份核验 → 权限校验 → 规则校验 → 操作确认 → AI 合规 → 哈希封签 → 归档。任一层 block 即中止。
原理： 审核链不是七个独立的检查，而是一条可证明的链。第 6 层哈希封签使整条链可验证：每条记录包含前一条记录的哈希，任一层被篡改都会破坏后续全部哈希一致性。这带来两个能力：追溯（操作全貌可回放）与证明（操作未被篡改可验证）。可证明性是合规场景的底线——审计不能只"记录了"，还必须"证明没被改过"。
操作确认层体现人机协同的粒度：高风险操作（删除、取消、状态变更、额度调整）强制确认；确认词分级（强确认直接触发、弱确认仅独立短回复触发）；否定词守卫防止"不要确认"被当作"确认"。
12.6 威胁建模与防御纵深的设计校验
12.6.1 威胁建模：STRIDE 逐类映射
专家级安全设计以威胁建模（threat modeling）为起点：系统性枚举"系统可能被怎样攻击"，再逐类映射防线，而非凭感觉堆安全功能。以 STRIDE 分类法逐类核对本框架的防线覆盖：
| 威胁类别 | 含义 | 框架防线 | 章节 |
|---|---|---|---|
| Spoofing（伪造身份） | 冒充他人 | 认证（JWT 校验）+ 身份核验层 | 11 / 12.5 |
| Tampering（篡改数据） | 修改审计/规则数据 | 链式哈希防篡改 + 配置审批 | 12.5 / 9 |
| Repudiation（否认操作） | 抵赖做过的事 | 签字留痕 + 操作日志 + 哈希链 | 12.5 / 8 |
| Information Disclosure（泄露） | 敏感信息外泄 | 输出脱敏 + 上下文隔离 + 权限裁剪 | 12.4 / 9.2 |
| Denial of Service（拒绝服务） | 资源耗尽 | 频率限制 + 降级体系 | 12.4 / 8.5 |
| Elevation of Privilege（提权） | 越权操作 | RBAC/ABAC + SOD + 工具级门禁 | 12.2 / 12.3 |
原理： 威胁建模的价值在于"完整性检验"——每类威胁都有明确防线，没有"没想到的攻击面"。本框架的纵深防御正是对 STRIDE 六类的系统覆盖：不是单点防护，而是每类威胁都有"检测 + 阻断 + 留痕"三层响应。
12.6.2 fail-open 与 fail-closed 的决策框架
安全组件失效时的默认行为（放行或阻断）不能拍脑袋，决策框架基于两个问题：失效影响面与错误成本方向。
| 判断维度 | 倾向 fail-closed（阻断） | 倾向 fail-open（放行） |
|---|---|---|
| 被保护对象的错误成本 | 假放行成本高（违规落库） | 假阻断成本高（业务中断） |
| 失效可观测性 | 低（静默失败不易发现） | 高（可监控、可补偿） |
| 检测组件角色 | 核心防线（规则、认证） | 辅助护栏（注入检测） |
| 示例 | 规则引擎异常 → block；认证失败 → 拒绝 | 注入检测异常 → 放行并记日志 |
原理： 决策框架的统一表述：失败默认取"错误成本更高的一侧"的对立面。规则引擎假放行成本高 → 失效默认阻断（fail-closed）；注入检测若假阻断则拖垮全部业务 → 失效降级放行（fail-open）。任何安全组件的默认行为都应能从错误成本表推导，而非凭经验选择。
12.6.3 认证令牌的工程考量
JWT 认证的两个常被忽视的工程点：
- 密钥治理：弱密钥在生产环境是绕过认证的直通车——框架在非调试模式对弱密钥 fail-closed（登录入口拒绝），防止"为了测试方便"的弱密钥泄漏到生产；
- 撤销与轮换：JWT 无状态（服务端不保存），撤销需黑名单或短时效；框架以短 TTL + 登录重新签发控制撤销窗口，密钥轮换须纳入运维流程。
原理： 认证的工程本质是"密钥与时效的治理"。无状态令牌把"撤销谁"的问题转移为"令牌多久过期"，因此 TTL、黑名单、密钥轮换必须成为认证设计的显式组成部分，而非事后补丁。
12.7 失败模式与权衡
| 失败形态 | 根因 | 设计应对 |
|---|---|---|
| 权限静默失效 | 配置列名不匹配、加载被吞 | 双键兼容读取 + 加载日志 |
| 单人完成舞弊闭环 | 执行与审批同人 | SOD 铁律 + 流程 Gate 校验 |
| 审计记录被篡改 | 无防篡改机制 | 链式哈希 + 完整性验证 |
| 安全检测拖垮业务 | 检测异常直接报错 | 安全检测异常降级不阻断（可用性优先） |
权衡： 安全与可用性的平衡点：输入侧注入检测异常时降级不阻断业务——攻击检测是"尽力而为"的护栏，业务可用性是底线；而规则引擎异常时默认阻断——业务正确性是底线。两处默认值相反，因为两者的失败成本方向相反。
12.8 本章小结
- 信任必须分层，纵深防御的每一层只回答一个问题；
- RBAC 管角色、ABAC 管情境，双重判定方可放行；
- SOD 切断舞弊闭环，因此不可训练、不可绕过；
- 输入输出防线拦截攻击与泄露，频率限制拦截滥用；
- 七层审核链以哈希封签实现可证明性；安全与可用性的默认值因失败成本方向而异。