S59：Auth、Policy Engine 与 Audit Trail 的决策流

内容类型：预习教材（不代表已完成）
日期：2027-01-20
阶段：P2 · AI Systems Engineering 90
总路线：Day 149 / 360
周次：W9 · Security、Privacy、AI Supply Chain
节奏：周三引导练习
状态：教材已备；学习未完成
标签：authentication、authorization、policy-engine、audit-trail、decision-flow

一句话定义

安全决策流把凭证验证、策略求值、业务审批和审计记录分成独立步骤，使 allow、deny 与 escalate 都能追溯到主体、资源、目的、上下文和策略版本。

学习目标

1. 沿 auth→policy→handler→audit 解释每层输入、输出与失败方式。
2. 能为 allow/deny/escalate 设计一致的决策记录。
3. 理解 audit trail 应记录决定证据而不是复制敏感内容。
4. 观察现有教学实现与生产身份、策略和审计能力之间的边界。

核心知识

• AuthN 验证 token/credential 的 signature、issuer、audience、expiry 和主体；AuthZ/Policy 再结合 action、resource、purpose、risk 与上下文求值。
• Policy Enforcement Point 截获真实动作；Policy Decision Point 求值；Policy Information Point 提供属性；Policy Administration Point 管理规则。概念分开有助于明确失败与缓存。
• allow/deny/escalate 比布尔值更适合高风险 Agent：escalate 表示自动权限不足但可以进入受控人工决定，绝不等于临时 allow。
• Audit 要记录 actor chain、request/action/resource、purpose、policy version、decision、reason、evidence refs、effect/result 和 correlation；secret、token 与大段 PII 不应写入。
• Policy 缓存要谨慎：主体状态、案件分配、风险或策略可能变化。缓存 key 与 TTL 必须包含影响决定的上下文。
• 默认拒绝需要可解释错误和合法升级路径，否则团队会寻找绕过方式。

机制与推导

决策序列：

request
 -> authenticate credential
 -> normalize actor/delegation/resource/action/purpose
 -> collect trusted attributes
 -> evaluate policy@version
 -> allow: execute through enforcement point
    deny: return reason without leaking policy internals
    escalate: create human task, do not execute effect
 -> record decision and eventual effect as linked audit events

Audit 中“决定”和“效果”应分开。policy.allowed 说明当时允许尝试；tool.effect.confirmed 才说明外部效果确认。若执行失败，不能覆盖原 allow 记录为 deny。用 causation id 连接二者，才能解释授权正确但依赖失败的情况。

属性来源也有信任等级：token claim、内部目录、请求体和模型输出不能等价。资源 owner、purpose 与 risk 应从受信系统解析，而非完全接受模型参数。

最小练习或观察步骤

1. 只读查看 auth.ts、policyEngine.ts 和 auditTrail.ts 的类型与决策分支。
2. 准备三个合成请求：只读 allow、高风险 escalate、跨案件 deny。
3. 为每个请求写主体链、资源、动作、目的、属性来源和 policy version。
4. 生成预期 audit event 形状，分开 decision 与 effect，不填真实 token。
5. 构造策略更新与缓存未过期的反例，判断 cache key/TTL 风险。
6. 若没有运行代码，只报告静态观察和推演，不称为“权限验证通过”。

常见误区与边界

• token 验证通过就跳过资源级授权。
• 模型输出 purpose=approved 就视为可信属性。
• escalate 后先执行动作再等待人工追认。
• audit 只有成功事件，拒绝、未知与人工覆盖消失。
• 将 token、prompt、PII 和策略秘密全部写日志以便排障。
• 教学 policy engine 不等于企业 IAM、集中策略分发、不可篡改审计或合规控制。

系统 / 金融 / Web3 场景连接

AML 分析师可读取分配案件，跨案件访问应 deny，冻结建议则 escalate 给有决策权的主管。审计链需要分开“允许提交建议”“主管批准”“核心系统接受”。Web3 Agent 的 simulation 可 allow，签名请求可 escalate 到用户，超限或错误链则 deny；签名后广播仍是独立效果。

自检问题

1. AuthN、policy decision、approval 与 effect confirmation 各发生在哪里？
2. 为什么 audit 要分开 decision 和 effect？
3. 哪些属性不能信任请求或模型直接提供？
4. Policy cache 应考虑哪些变化？

专业课程对齐

• 阅读 Model Context Protocol 官方文档 的 authorization 与 security guidance，重点映射 client、authorization server、MCP server/resource server 的职责。
• 阅读 Kubernetes 官方文档 的 authentication、authorization、RBAC 与 admission control，比较身份验证、授权和准入在请求链中的不同位置。
• 阅读 OpenTelemetry 官方文档 的 context propagation、events 与 security 相关指导，思考怎样关联决策和效果而不把敏感凭证放入 telemetry。

深入学习提示

按 allow、deny、escalate 三条路径逐一走读，尤其追问 escalate 是否真的阻止副作用。深入时标记每个属性来源和信任等级，再检查 policy cache 是否包含所有决定变量。无需扩展成完整 IAM 实验；能解释一次决定链和证据链即可。

学后填写区

• 实际查看的组件范围：
• 三条决策路径：
• 属性来源与信任等级：
• Decision / effect 审计事件：
• 教学与生产边界：