Wiki Notes

Appearance

角色权限矩阵专题 ​

版本：v1.3

最后更新：2026-07-09

适用对象：正在做企业知识助手、审批助手、Agent、多租户系统和需要把“谁能看、谁能调、谁能批”落成工程控制点的产品、平台和安全同学

很多企业 AI 项目在讨论权限时，会停留在一句很粗的描述：

  • 谁能看什么

但真正落地到系统里时，你很快会发现还要回答：

  • 谁能调用哪些工具
  • 谁能触发哪些动作
  • 谁能审批哪些结果
  • 谁能看到哪些 trace、日志和审计记录
  • 谁能导出、分享、外发、批量处理

这就是为什么权限模型最终往往要落成一张：

  • 可执行的角色权限矩阵

这篇专题的重点不是讲一个抽象的“最小权限原则”，而是讲：

  1. 企业 AI 系统里矩阵到底应该管哪些对象。
  2. 为什么只靠 RBAC 往往不够。
  3. 怎样把矩阵落到检索、工具、审批、审计这些真实控制点上。
  4. 怎样让矩阵进入发布、审计和事故复盘，而不是只放在文档里。

根据 2026-07-09 可访问的 Azure RBAC / ABAC 官方文档、Microsoft Entra 角色控制与 PIM 资料、OpenAI Guardrails and human review / Safety best practices、NIST AI RMF 与 AI RMF Playbook，一个很值得先建立的认知是：

AI 系统的权限，不只是“看页面”的权限，而是“谁在什么上下文里能看到什么、调用什么、批准什么、执行什么”的组合控制。

1. 什么是角色权限矩阵 ​

角色权限矩阵可以理解成：

  • 角色
  • 资源
  • 动作
  • 条件

四者之间的一张明确映射表。

它的价值在于把“口头上的权限规则”变成：

  • 可检查
  • 可审计
  • 可实现

1.1 为什么 AI 系统比普通系统更需要矩阵化 ​

普通系统里，权限常常只围绕：

  • 页面
  • 接口
  • 菜单

而 AI 系统里，权限还会分布在：

  • 检索范围
  • 工具调用
  • 审批动作
  • 会话上下文
  • 导出与外发
  • trace 与审计
  • 训练样本、失败样例和评测集访问

如果没有矩阵，团队很容易出现：

  • 规则靠记忆
  • 实现不一致
  • 出事后责任边界不清

2. 一张基础矩阵通常长什么样 ​

更实用的字段通常包括：

  • 角色
  • 资源域
  • 可执行动作
  • 作用范围
  • 是否需要审批
  • 审计级别
  • 特殊限制

例如角色可能包括：

  • 普通员工
  • 团队管理员
  • 审核员
  • 平台管理员
  • 安全管理员
  • 值班工程师

一句话理解：

  • 矩阵不是“谁能访问页面”的清单，而是“谁在什么条件下能做什么动作”的表。

2.1 矩阵最好把“人、Agent、服务身份”分开，不要都叫管理员 ​

很多团队做矩阵时，只会列：

  • 普通用户
  • 管理员
  • 安全管理员

但 AI 系统里真正执行动作的主体往往不止是人，还包括：

  • 后台服务账号
  • MCP / tool connector 身份
  • Agent 运行身份
  • 批处理或回放任务身份

如果这些身份和人工角色混在一张“管理员表”里，后面就很难回答：

  • 是谁真正拿着权限在执行动作
  • 哪些权限是人审后临时激活的
  • 哪些权限是系统运行时自动持有的

更稳的矩阵通常至少分三类主体：

  1. human principal
  2. service principal
  3. agent or workflow principal

这样在工具调用、审计和事故复盘时，责任边界才会更清楚。

3. 为什么只靠 RBAC 常常不够 ​

很多企业最终都会发现：

  • 只靠角色不够

因为还要考虑：

  • 部门
  • 租户
  • 文档密级
  • 地域
  • 时间窗口
  • 资源标签
  • 数据主权边界

这也是为什么真实落地通常是：

  • RBAC 为主，ABAC 补充

Azure 官方文档当前明确把 Azure RBAC 说明为：

  • 管理谁有权限、能做什么、作用在哪些范围

同时又说明在需要更细粒度访问控制时，可以用 ABAC 条件进一步收窄范围。

这类思路特别适合企业 AI 系统里的：

  • 文档密级
  • 部门隔离
  • 指定资源标签
  • 指定数据域限制
  • 特定工具只能在特定租户范围触发

3.1 高风险角色最好做 eligible assignment，而不是常驻授权 ​

Microsoft 当前 Best practices for Microsoft Entra roles 与 Privileged Identity Management 都在明确强调：

  • 最小权限不只是“权限少”
  • 还包括“只在需要时短时间拥有高权限”

这对 AI 系统尤其重要，因为很多高风险动作并不是全天候都该开放，例如：

  • 导出高敏 trace
  • 修改审批策略
  • 放开外发能力
  • 调整高风险工具白名单

更稳的做法通常是：

  • 普通时间只有 eligible
  • 真正需要时再通过 PIM / JIT activation 激活
  • 激活要带时长、理由、审批和审计

这样矩阵才不只是“有没有权限”，还包含：

  • 什么时候能拿到权限
  • 拿多久
  • 谁批准的

3.2 角色分配权限本身也要进矩阵，不然最小权限会被绕过去 ​

很多团队会仔细控制业务动作，却忽略了一个更危险的权限：

  • 谁能给别人分配角色

Microsoft 当前 Delegate Azure access management to others 明确支持限制委派者可以创建、删除哪些角色分配，以及阻止其继续向下委派。

这对企业 AI 很关键，因为如果“角色分配权”不受控，前面的矩阵再细也可能被一键绕过。

更适合写进矩阵的通常包括：

  • 谁能新增角色分配
  • 谁能删除角色分配
  • 谁能创建带条件的角色分配
  • 谁能授予导出、审批、外发类高风险权限
  • 谁能修改 service principal 和 agent principal 的权限

4. AI 系统里哪些能力最适合做矩阵化 ​

4.1 检索权限 ​

  • 谁能搜哪个知识库
  • 谁能看哪些部门文档
  • 谁能看到原文，谁只能看摘要
  • 谁能看引用片段，谁只能看来源信息

4.2 工具权限 ​

  • 谁能查数据
  • 谁能改状态
  • 谁能触发外发
  • 谁能批量执行
  • 谁能调高风险第三方接口

4.3 审批权限 ​

  • 谁能审批退款
  • 谁能批准外部发送
  • 谁能批准高敏操作
  • 谁能做临时豁免

4.4 观测与审计权限 ​

  • 谁能看 trace
  • 谁能看日志原文
  • 谁能看脱敏前内容
  • 谁能导出审计记录

4.5 运营与治理权限 ​

  • 谁能修改 Prompt / schema
  • 谁能切换模型
  • 谁能发布新索引
  • 谁能调整门禁或回退策略

如果只把“业务数据权限”写进矩阵，却不写“工具、审批、trace、配置发布权限”，矩阵通常是不完整的。

5. 矩阵设计时最容易漏掉的隐蔽控制点 ​

最常被忽略的是：

  • 中间结果权限
  • trace 和审计日志权限
  • 导出权限
  • Agent handoff 后的共享范围
  • 批量任务权限
  • 回放与失败样例访问权限

这些地方如果没写进矩阵，通常就会成为隐蔽风险点。

例如：

  • 用户不能打开原文文档
  • 但能通过 trace 看到原文片段

这就是典型的“系统主链路做了权限，旁路没做权限”。

6. 角色矩阵和多租户边界为什么要一起看 ​

如果系统是多租户或多部门共享，矩阵不能只写：

  • 角色 A 能查知识库

还要写：

  • 角色 A 能查哪个租户 / 哪个部门 / 哪类密级的知识库

这类约束更适合落到：

  • retrieval filter
  • namespace / tenant scope
  • tool access layer
  • approval workflow
  • audit export layer

如果矩阵和多租户架构脱节，最终会出现：

  • 文档写得很严
  • 系统实现却只做了一个大开关

6.1 多租户矩阵最好把“租户边界”和“数据边界”拆开 ​

很多团队写了：

  • A 租户不能访问 B 租户

但真实系统里经常还要再拆一层：

  • A 租户里的哪些数据域可以被哪个角色访问

因为很多企业 AI 不是简单的“一个租户一块平地”，而是还存在：

  • 密级差异
  • 地域差异
  • 法务或合规保留区
  • 只读知识域和可执行业务域

如果矩阵里只写租户、不写数据边界，最后仍然可能出现：

  • 没有跨租户
  • 但发生了租户内越权

7. 角色矩阵如何进入工程实现 ​

一张好矩阵不应该只停留在文档层。

更好的落地路径通常是：

  1. 先定义角色和动作。
  2. 再把资源分类。
  3. 再明确审批条件和豁免条件。
  4. 最后映射到系统控制点。

控制点通常包括：

  • retrieval filter
  • tool access layer
  • approval workflow
  • audit logging
  • trace redaction / access control
  • export/download control

7.1 最关键的一点 ​

不要只在前端做权限判断，真正关键的是后端和执行层控制点也要落地。

7.2 trace 脱敏最好按字段分级，不要只做“全量可见 / 全量隐藏” ​

OpenAI 当前 Guardrails and human review 和相关安全资料强调要对敏感动作做审批边界；Microsoft 与 NIST 的治理思路则都指向另一件事：

  • 审查和诊断所需的信息不等于所有原始敏感内容

这意味着 trace 与审计权限更适合做分级暴露，例如：

  1. metadata tier request id、workflow、耗时、错误码、模型版本。
  2. masked content tier 脱敏后的输入输出、摘要化工具参数、部分引用片段。
  3. raw content tier 原始用户输入、原始文档片段、原始工具参数、完整审批附件。

这样排障、产品分析、安全审计可以拿到不同层级，而不是：

  • 要么什么都看不到
  • 要么默认全量明文

8. 为什么“看”和“做”的权限必须拆开 ​

很多团队一开始只做一种权限：

  • 能不能看到

但 AI 系统很快会遇到第二类问题：

  • 能不能做

这两类权限必须拆开，因为：

  • 能看到报价制度，不等于能触发批量报价修改
  • 能看到工单摘要，不等于能给客户自动发信
  • 能看到模型建议，不等于能批准执行

所以矩阵里至少要把：

  • read
  • suggest
  • approve
  • execute
  • export

这些动作区分开。

8.1 批量权限和单次权限最好也拆开 ​

很多团队会区分“看”和“做”，但还会漏掉另一条非常关键的边界：

  • 单次做
  • 批量做

例如：

  • 能改单条工单状态，不等于能批量改
  • 能导出一条审计记录，不等于能批量导出
  • 能重放一条失败样例，不等于能批量回放全量样本

批量权限在 AI 系统里往往意味着：

  • 更大 blast radius
  • 更高合规风险
  • 更强的人工确认需求

所以矩阵更适合显式区分：

  • execute_once
  • execute_bulk
  • export_once
  • export_bulk

9. 为什么“建议”和“执行”之间必须有边界 ​

OpenAI 当前 Guardrails and human review 文档明确把：

  • 自动 guardrails
  • human review 审批决策

分成两层。

这给矩阵设计一个很直接的启发：

  • 生成建议的权限，不应自动等于执行动作的权限

尤其在这些场景里必须分开：

  • 对外发送
  • 财务审批
  • 合规判断
  • 客户状态修改
  • 高风险数据导出

10. 为什么 trace 和审计权限经常比业务数据权限更危险 ​

很多系统把业务主链路保护得不错，但 trace 权限给得过宽。

典型风险包括：

  • trace 里能看到原始用户输入
  • trace 里能看到检索原文片段
  • trace 里能看到敏感工具参数
  • 审计日志里能反推出高敏数据

因此在很多企业 AI 系统里，trace 权限不该默认等于“开发权限”。

更好的做法通常是：

  • trace 脱敏展示
  • 按角色控制原文可见范围
  • 审计导出单独审批

10.1 失败样例、回放集和评测集也要单独做权限矩阵 ​

很多团队会认真保护线上业务数据，却忽略：

  • 失败样例集
  • 回放样本
  • 评测集

这些数据往往同样敏感，因为它们可能包含：

  • 原始用户输入
  • 高风险审批上下文
  • 工具调用参数
  • 投诉、事故和人工接管记录

如果这些集合被默认开放给“做评测的人”，就很容易形成另一条旁路。

更稳的设计通常是把它们单独做成资源域，并明确：

  • 谁能看样例明文
  • 谁只能看脱敏样例
  • 谁能导出
  • 谁能用于 replay
  • 谁能把样例回写到训练或评测流程

11. 矩阵如何避免失控 ​

矩阵很容易随时间膨胀，变成没人看得懂的大表。

更稳妥的方式通常是：

  • 按系统域拆分
  • 按高风险动作单独列
  • 对例外规则单独说明
  • 把临时豁免单独登记

这样比把所有东西堆成一张巨表更可维护。

11.1 更可维护的拆分方式 ​

  • 检索矩阵
  • 工具矩阵
  • 审批矩阵
  • 审计矩阵
  • 发布矩阵

而不是所有能力混在一个 sheet 里。

11.2 权限漂移最好做周期复核，不然矩阵会和现实逐渐脱节 ​

NIST AI RMF GOVERN 2.1 强调角色、职责和沟通线必须被清晰记录并在组织内明确；Microsoft Entra 角色最佳实践也强调要定期审查高权限角色分配。

这在 AI 系统里尤其重要，因为权限漂移很容易来自：

  • 新工具接入
  • 新知识域上线
  • 临时豁免长期遗留
  • 值班和事故期间的临时加权没有回收

更可执行的做法通常是周期性复核下面这些对象：

  • 高风险角色常驻人数
  • eligible 角色的激活频率
  • 例外豁免是否到期
  • trace 原文查看权限是否扩散
  • service / agent principal 是否还持有旧权限

12. 条件型权限最适合放在哪些地方 ​

ABAC 或条件型权限在企业 AI 里尤其适合这些场景：

  • 只允许访问特定标签知识域
  • 只允许操作指定部门资源
  • 只允许在办公时间触发高风险动作
  • 只允许对自己拥有 owner 责任的知识域做发布
  • 只允许值班工程师在事件窗口里访问某类诊断数据

这类条件如果不进入矩阵，最后就很容易变成：

  • 一堆口头例外
  • 一堆人工记忆
  • 一堆审计时说不清的临时规则

12.1 条件权限最好优先落在“对象属性”和“运行上下文”上 ​

Azure ABAC 当前文档明确把 role assignment conditions 作为在操作上下文中利用属性进一步收窄权限的机制。

对企业 AI 来说，最值得优先结构化的通常是两类条件：

  1. object attributes 例如租户、密级、资源标签、知识域 owner、是否高风险工具。
  2. runtime context 例如办公时间、是否值班窗口、是否事故模式、是否审批后执行。

如果条件只是写在说明文档里，而没有落成可判定字段，最后就很容易退化成：

  • “这次先人工注意一下”

13. 矩阵如何进入审批和发布流程 ​

角色矩阵不应该只是“开发时参考一下”。

更成熟的做法通常是把矩阵接进：

13.1 上线前检查 ​

  • 新工具有没有对应角色边界
  • 新知识域有没有对应读取范围
  • 新审批动作有没有对应批准角色

13.2 变更审核 ​

  • 权限模型变更是否经过 review
  • 是否影响高风险动作
  • 是否需要灰度和回滚预案

13.3 事故复盘 ​

  • 当时谁能看
  • 谁能批
  • 谁能执行
  • 哪个控制点没有拦住

13.4 break-glass 角色也要进矩阵，而且必须单独留痕 ​

很多团队知道生产上需要应急权限，但没把它正式写进矩阵，最后常见情况是：

  • 出事故时临时找人开全权限
  • 事后说不清谁为什么拿到了权限

更稳的做法通常是把 break-glass 明确为一类特殊角色，并至少定义：

  • 触发条件
  • 最长激活时长
  • 是否必须双人批准
  • 激活后哪些动作必须强审计
  • 事后多久内必须复盘

这样应急权限才不会变成“制度外的万能钥匙”。

14. 角色矩阵怎么进入审计和复盘 ​

权限矩阵最有价值的地方之一，是事故后能回答：

  • 这个人为什么能看到这份资料
  • 这个动作为什么被允许执行
  • 审批为什么会落到这个角色

如果矩阵和审计记录打不通，出事后就很难证明：

  • 是规则设计错了
  • 还是规则没落地
  • 还是例外豁免失控了

14.1 审计里最好同时保留“授权依据”和“实际调用主体” ​

很多审计系统只记：

  • 这个动作发生了

但对角色矩阵来说，真正重要的是还能回答：

  • 它是依据哪条角色分配发生的
  • 是哪个 human principal 批的
  • 是哪个 service / agent principal 实际执行的

如果只记动作，不记授权依据和执行主体映射，后面就很难判断：

  • 是矩阵本身设计有洞
  • 还是执行身份被赋权过宽

15. 一个更适合企业 AI 的最小矩阵思路 ​

如果团队现在还没有正式矩阵，可以先从这四列开始：

  1. 角色
  2. 资源域
  3. 动作
  4. 条件 / 审批要求

然后优先覆盖：

  • 高敏知识库
  • 高风险工具
  • 外发动作
  • 审批动作
  • trace / audit 导出

15.1 第一版最小矩阵最好再补两张配套表 ​

如果真的想让矩阵能落地，除了主表，第一版通常还值得补两张配套表：

  1. exception register 记录临时豁免、到期时间、批准人和回收状态。
  2. principal inventory 记录 human / service / agent principal 各自持有哪些高风险权限。

这样矩阵才不会只描述“应该怎样”，还会记录：

  • 现实里有哪些例外
  • 到底有哪些主体真正拿着高权限

16. 常见反模式 ​

  • 只做页面权限，不做检索和工具权限
  • 只做“能看”，不做“能执行”
  • 把 trace 当成默认开发可见
  • 多租户边界只写在文档里，不进 filter
  • 审批权限和执行权限没有分开
  • 例外豁免没有单独记录
  • 高风险角色长期常驻，不做 JIT / eligible 管理
  • 只审人类角色，不审 service 和 agent 身份

17. 推荐搭配阅读 ​

18. 重点官方资料 ​

以下资源已按 2026-07-09 做过可访问性检查：

19. 落地检查清单 ​

  • 是否把检索、工具、审批、审计、发布权限都纳入矩阵
  • 是否单独管理了 human、service、agent 三类主体的高风险权限
  • 是否区分了 read、suggest、approve、execute、export 几类动作
  • 是否为高风险角色设计了 eligible / JIT / break-glass 机制
  • 是否把多租户、密级、时间窗口等条件真正落到系统控制点
  • 是否对 trace 和审计原文做了单独权限设计
  • 是否能在事故后回答“谁为什么能做这件事”