Zanzibar / Cedar / OPA 授权与 Policy Architecture 解读

Source Anchors

核心导读

AI runtime 的权限边界不能由 prompt 承担。Prompt 可以引导模型行为，但不能作为安全边界、审计证据或访问控制机制。

Zanzibar、Cedar 和 OPA 代表三类互补能力: 关系型授权、应用级策略语言、通用 policy-as-code。它们共同指向一个架构原则: 每次检索、工具调用、数据读取、建议生成和高风险行动，都应被外部化的 policy system 判断、执行、记录和测试。

系统价值在于把授权从分散在页面、API 和 prompt 里的局部判断，提升为贯穿 RAG、工具网关、工作流和审计的控制面。好的授权架构不只回答 allow/deny，还要表达 mask、draft-only、step-up、require approval、break-glass 等受控结果，并把每次判断绑定主体、资源、关系、上下文和策略版本。

治理边界在于：policy system 负责可执行边界，模型只负责生成意图、解释或候选动作。策略是否合理、关系数据是否新鲜、属性是否可信、紧急访问是否被复核，则需要 identity、data governance、security、risk owner 和业务流程共同维护；不能把“模型会拒绝”当作控制证据。

问题定义

传统应用中，用户点击按钮，后端检查权限。AI Agent 和 RAG 系统改变了风险面:

• 模型可以主动选择工具。
• 检索系统可能把未授权文档送入上下文。
• 员工 copilot 可能继承过宽系统账号权限。
• 客户 facing AI 可能被 prompt injection 诱导泄露内部政策或他人数据。
• Agent 可能草拟、提交、修改、发送或触发 workflow。
• 审计需要解释某次检索或工具调用为什么被允许。

因此，授权问题从“页面按钮能不能点”变成:

who or which agent
  acting on behalf of whom
  wants to perform which action
  on which resource
  for what purpose
  under what context
  with what risk tier
  according to which policy version

权限架构的目标不是让模型“记住不要越权”，而是让越权请求无法被执行。

核心原理

外部化授权的基本结构:

Application / Agent / Retrieval / Tool Gateway
  -> Policy Enforcement Point
  -> Policy Decision Point
       -> identity
       -> relationships
       -> attributes
       -> resource metadata
       -> consent and purpose
       -> runtime context
       -> policy version
  -> decision
  -> enforcement
  -> audit log

RBAC、ABAC、ReBAC 解决不同问题:

AI 场景通常需要组合:

allow if
  role permits
  and relationship permits
  and resource attributes permit
  and purpose and consent permit
  and action risk tier permits
  and workflow state permits

Zanzibar 的机制价值在于把权限表达为主体、对象和关系的图，并在大规模系统中一致判断访问关系:

document:123#viewer@user:alice
folder:finance#editor@group:risk-team
case:456#assignee@user:bob
customer:789#relationship_manager@user:claire

Cedar 的机制价值在于面向应用授权表达:

principal can action on resource when context satisfies conditions

OPA 的机制价值在于把策略决策外部化，让应用、网关、基础设施和 AI runtime 使用统一 policy decision 模型。

系统/架构模型

AI runtime policy architecture 可以组织为:

User / Agent Session
  -> identity and delegation service
  -> context builder
       -> user role
       -> acting_as / delegation
       -> customer and resource relationship
       -> consent / purpose
       -> data classification
       -> workflow state
       -> risk tier
  -> Policy Enforcement Point
  -> Policy Decision Point
       -> relationship graph
       -> attribute store
       -> policy bundle
       -> resource metadata
  -> controlled surface
       -> retrieval filter
       -> tool gateway
       -> model routing
       -> response policy
       -> workflow decision
  -> audit and evidence store

RAG 权限过滤必须前置:

wrong:
  retrieve all chunks -> send to model -> ask model not to reveal unauthorized content

correct:
  query -> subject/resource policy check -> retrieve authorized chunks only
        -> generate answer with citations -> output policy check

工具调用应按能力风险分层:

Agent 不是超级用户。它应该有 delegated authority，并记录 actor、subject、agent session、tool、purpose、resource、policy version 和 decision。

关键机制与取舍

关键取舍不是选择某一种权限模型，而是把关系、属性、角色、目的、风险和 workflow state 放到正确的决策位置。

证据与控制

Policy system 必须像代码一样测试和发布:

审计日志应包含:

decision_id
actor
acting_as / delegated authority
action
resource
relationship snapshot or relation revision
context attributes
policy version
decision
enforcement result
evidence references

没有 enforcement result 的 policy log 只说明系统做过判断，不说明判断被真正执行。

金融零售场景映射

客服 Copilot:

• 可读公开产品信息和当前会话客户的必要资料。
• 不可读无关客户、高敏财富信息或内部调查结论。
• 可草拟回复，但高风险承诺、赔付、费用减免和投诉结论需要人工确认。
• RAG 检索前做关系和数据分类过滤，输出前做敏感字段和话术检查。

信贷 Copilot:

• 贷审人员可读申请材料、政策和补件证据。
• Agent 可以检查缺失字段、整理证据、草拟 memo。
• 拒贷、额度、adverse action reason 和最终审批不能由 Agent 单独决定。
• 所有建议进入 case record，绑定政策版本和证据引用。

AML / Fraud:

• Analyst 只能访问分配案件和授权证据。
• 内部 typology、SAR/STR 判断和调查结论不能暴露给客服或客户 facing AI。
• 高敏外部数据源应有单独 action tier 和 purpose 限制。
• break-glass 访问必须限时、记录和复核。

企业 RAG:

• 文档索引需要携带 ACL、relationship metadata、版本、数据分类和有效期。
• 权限变更要能及时影响检索结果。
• 过期或撤销的文档不能继续被引用。

反模式

• 把 prompt 当作权限控制，让模型自行拒绝越权请求。
• RAG 先召回所有内容，再在生成阶段要求模型不要泄露。
• 给 Agent 一个系统级服务账号，绕过真实用户关系和目的限制。
• 只在前端隐藏按钮，后端工具和检索服务没有 PEP。
• 策略硬编码在多个服务里，无法集中测试、模拟和审计。
• 只返回 allow/deny，无法表达 mask、draft-only、step-up 或 require approval。
• 权限日志没有 policy version、resource metadata 或 enforcement result。
• break-glass 没有过期、事后复核和异常监控。

最终心智模型

AI 授权架构的核心是把“模型想做什么”转成“受控系统是否允许这个主体在此上下文中对该资源执行这个动作”。Prompt 是意图约束，policy system 是执行边界。

正确的心智模型是: Identity 确认主体，ReBAC 表达关系，ABAC 表达上下文和资源属性，policy-as-code 计算决策，PEP 执行决策，audit evidence 证明决策和执行都发生过。

---

SOTA 状态标注 (2026-07-01)

本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。