Wiki Notes

Appearance

企业权限模型专题 ​

版本：v1.2

最后更新：2026-07-08

适用对象：需要为企业 AI 产品、知识库、工具调用、审批助手和多 Agent 工作流建立可落地访问控制的产品、研发、平台与安全同学

企业 AI 系统一旦接入知识库、CRM、工单、审批、文件系统和内部工具，权限问题就会从：

  • 一个技术细节

迅速变成：

  • 整个系统的安全底座

很多项目真正出问题的地方并不是模型答错，而是：

  • 模型看到了不该看的内容
  • 工具调用到了不该调用的资源
  • 检索把跨部门或跨租户的数据召回了
  • 会话历史把旧权限上下文带到了新请求里

根据 2026-07-08 可访问的 Azure RBAC / ABAC 官方文档、Weaviate RBAC overview / manage roles、OpenAI Your data / Safety in building agents / Guardrails and human review 等资料，可以先抓住一个核心判断：

  • AI 权限模型不能只做“入口鉴权”，而要把身份、检索范围、工具权限、动作审批和审计证据串成一条访问决策链。

1. 为什么权限模型在 AI 系统里更难 ​

传统系统里，权限通常主要体现在：

  • 页面访问
  • API 访问
  • 数据库读写

但在 AI 系统里，权限还会出现在很多“中间层”：

  • 检索召回
  • 工具选择
  • 上下文拼接
  • 多轮状态复用
  • Agent handoff

这意味着：

  • 权限不再只是“能不能调用接口”
  • 而是“系统能不能看到、带上、推断出、执行出某些结果”

1.1 检索结果本身就是权限对象 ​

很多团队只盯最终动作，但在知识问答里，更常见的风险其实是：

  • 不该召回的内容被召回了

只要敏感知识已经进了上下文，哪怕最后没执行写操作，也可能已经构成风险。

1.2 工具权限和动作权限不是一回事 ​

例如：

  • 能调用“查询订单”工具
  • 不代表能调用“退款执行”工具
  • 能生成建议
  • 不代表能真正提交变更

AI 场景里经常需要把：

  • 可见
  • 可查
  • 可调
  • 可执行

分开建模。

2. 企业 AI 里更实用的四层权限 ​

单纯讲“用户角色”通常不够，企业里更实用的拆法通常有四层。

2.1 数据权限 ​

回答的是：

  • 谁能看到哪些知识、文件、记录和文档

这层会直接影响：

  • RAG 检索范围
  • 文档引用范围
  • 上下文拼接范围

2.2 工具权限 ​

回答的是：

  • 谁能调用哪些工具

例如：

  • 查询类工具
  • 导出类工具
  • 发消息类工具
  • 管理类工具

2.3 动作权限 ​

回答的是：

  • 哪些结果只能展示
  • 哪些结果可以触发外部动作

这层很关键，因为很多 AI 系统不只是“回答”，还会：

  • 写工单
  • 发邮件
  • 更新系统
  • 执行审批

2.4 审批权限 ​

回答的是：

  • 谁能批准高风险动作
  • 在什么条件下批准
  • 批准后工作流恢复到哪一步

这层通常不属于传统 RBAC 的最小范畴，但在企业 AI 里非常常见。

3. 为什么“能搜到”本身就是权限问题 ​

很多团队会把权限理解成：

  • 某个接口能不能调

但知识库和 RAG 场景里，更关键的问题经常是：

  • 不该召回的内容是不是被召回了

3.1 检索过滤本身就是访问控制 ​

企业知识库里常见要求包括：

  • 按部门隔离
  • 按角色隔离
  • 按租户隔离
  • 权限变更后快速生效

所以 retrieval filter 不是优化细节，而是权限控制的一部分。

3.2 权限边界要在“进入上下文前”生效 ​

更稳妥的做法通常是：

  • 先按权限过滤
  • 再做召回与排序
  • 最后再拼装上下文

如果把权限判断留到最后拦截，很多敏感内容其实已经进过上下文了。

3.3 身份传播链如果断了，后面的权限判断都会失真 ​

企业里一个很常见的问题不是“没有做权限”，而是：

  • 身份在链路中间丢了

例如：

  • 网关知道用户是谁，但检索服务只拿到了匿名请求
  • 工具网关知道 tenant，却不知道用户角色
  • 审批恢复时保留了任务 ID，却没保留 actor scope

更稳的做法通常是沿着整条链路显式传递：

  • user id
  • tenant id
  • group / role
  • department / region
  • request id
  • approval context

4. 常见权限模型：RBAC、ABAC 与混合模式 ​

4.1 RBAC ​

RBAC 的核心是：

  • 按角色控制权限

适合：

  • 角色集合相对稳定
  • 组织边界清楚
  • 权限组合变化不频繁

优点是：

  • 易理解
  • 易沟通
  • 易审计

缺点是：

  • 粒度不够细时容易角色爆炸

4.2 ABAC ​

ABAC 的核心是：

  • 按属性做访问决策

Azure 当前 ABAC 文档强调：

  • 可以基于主体属性、资源属性和环境属性来判断访问

这对企业 AI 很有现实意义，因为很多访问条件都不是纯角色能表达的，例如：

  • 部门
  • 地域
  • 租户
  • 文档敏感级
  • 生效时间
  • 场景风险级别

4.3 混合模型 ​

企业里最常见的其实不是纯 RBAC 或纯 ABAC，而是：

  • 角色负责大边界
  • 属性负责细粒度约束
  • 审批负责高风险动作例外

这比单一模型更贴近真实业务。

4.4 AI 系统里最常见的不是纯 RBAC，而是“RBAC 打底 + ABAC 收口” ​

根据 Azure 当前 RBAC / ABAC 官方文档，更精确的理解通常是：

  • RBAC 负责先给出“谁在什么范围内可以做哪些动作”
  • ABAC 再用主体、资源、请求和环境属性把权限收紧到具体条件

在 AI 系统里，这种组合很常见，因为你经常需要同时表达：

  • “客服主管可以看客服知识库”
  • “但只能看自己区域、自己租户、自己业务线的记录”

5. AI 系统里权限校验应该放在哪 ​

不要只在最后一步校验。

更稳妥的做法通常是在多个环节同时检查：

text
Identity
 -> Retrieval Filter
 -> Tool Access Check
 -> Action Approval
 -> Audit Log

5.1 入口身份校验 ​

至少要确认：

  • 当前主体是谁
  • 属于哪个租户或部门
  • 具备哪些基础角色与属性

5.2 检索前权限过滤 ​

至少要确认：

  • 当前 query 能命中的知识范围
  • 是否要按 tenant / role / sensitivity 过滤

5.3 工具调用前权限校验 ​

至少要确认：

  • 当前主体是否允许调用该工具
  • 参数范围是否也需要限制

5.4 动作执行前审批与门禁 ​

至少要确认：

  • 这是只读动作还是写动作
  • 是否高风险
  • 是否需要人类批准

5.5 事后审计留痕 ​

至少要保留：

  • 谁请求了什么
  • 为什么允许
  • 最终执行了什么

5.6 更完整的权限决策链通常包含 PEP、PDP 和证据面 ​

虽然很多团队不会显式用这几个术语，但工程上很有帮助：

  • PEP：Policy Enforcement Point，真正拦截动作的地方
  • PDP：Policy Decision Point，计算“允不允许”的地方
  • Evidence：支撑审批、审计和复盘的证据面

放到 AI 系统里可以这样理解：

  • API gateway / tool gateway / retrieval service 经常承担 PEP
  • 角色、属性、审批规则的组合逻辑经常承担 PDP
  • trace、audit log、approval record、tool log 共同形成 evidence

6. 为什么检索过滤、工具白名单、审批门禁必须分开 ​

这三件事很容易被混在一起，但职责完全不同。

6.1 检索过滤 ​

决定的是：

  • 系统能看到什么

6.2 工具白名单 ​

决定的是：

  • 系统能调用什么

6.3 审批门禁 ​

决定的是：

  • 系统最终能执行什么

如果把它们混成一层，经常会出现：

  • 看得见但不该调
  • 调得了但不该执行
  • 能执行但没有审批证据

OpenAI 当前关于 guardrails 与 human review 的资料也明确把：

  • 自动校验
  • 人工批准

作为两类不同控制。

7. 权限和工具设计是什么关系 ​

高风险工具天然应该带更强权限边界。

7.1 工具 scope 要足够清楚 ​

例如：

  • 只能查当前租户订单
  • 只能读自己部门文档
  • 只能给 allowlist 域名发消息

7.2 工具参数也属于权限面 ​

不是只有“能不能调”才算权限问题。

例如：

  • 同一个导出工具
  • 对 department=a 和 department=*

风险完全不同。

所以工具参数应当：

  • 可校验
  • 有范围约束
  • 高风险参数进入审批

7.3 工具返回结果也要受权限约束 ​

不是调通就结束。

还要控制：

  • 返回字段范围
  • 敏感字段是否脱敏
  • 是否允许被写回对话上下文

7.4 工具参数最好也支持属性约束，而不是只靠角色放行 ​

这正是 ABAC 思路在工具层非常有价值的地方。

例如：

  • 允许导出工具，但仅允许导出自己部门数据
  • 允许查订单，但只能查询自己区域订单
  • 允许发消息，但不能对外部群组发送

8. 会话历史和 handoff 也会引入权限问题 ​

多轮系统最容易失控的地方之一，就是：

  • 老上下文继续流入新请求

8.1 历史消息可能带着旧权限结果 ​

例如：

  • 用户上轮在高权限身份下查到内容
  • 下轮换了身份或切了租户
  • 历史摘要仍保留旧结果

8.2 Agent handoff 可能共享了不该共享的状态 ​

例如：

  • 一个子 Agent 只该处理 A 租户
  • 却拿到了上一环节里的 B 租户上下文

8.3 缓存也会形成隐性越权 ​

如果缓存 key 没包含足够权限上下文，常见后果就是：

  • A 用户命中的结果被 B 用户复用

所以权限模型也必须覆盖：

  • 会话状态
  • handoff 状态
  • 缓存 key 设计

8.4 临时提权和会话续期也要受控 ​

企业系统里经常会有：

  • 值班提权
  • 审批后提权
  • 故障期临时放宽权限

这类能力如果没有时间边界和证据链，很容易变成长期漏洞。

9. 多租户场景里的权限模型要额外注意什么 ​

多租户不是权限模型的附加题，而是它最容易出事故的场景之一。

9.1 角色和租户边界不能混成一个概念 ​

同样是“管理员”，也可能只是：

  • 某个租户管理员

而不是：

  • 全局管理员

9.2 检索过滤必须带 tenant scope ​

否则就算角色对了，也可能出现：

  • 跨租户命中

9.3 工具也必须 tenant-aware ​

工具不仅要知道：

  • 用户是谁

还要知道：

  • 当前租户是谁
  • 当前租户允许做什么

9.4 tenant scope 和 role scope 不能互相替代 ​

这是企业里很容易混淆的一点。

  • tenant scope 解决“属于哪个租户”
  • role scope 解决“在该租户里能做什么”

如果把两者混成一个字段，后面通常会出现：

  • 权限模型越来越难解释
  • tenant 切换和角色切换互相污染
  • 审批链无法准确表达边界

10. 权限模型怎么评测 ​

权限模型不能只靠代码 review，需要被系统性验证。

10.1 无权限召回测试 ​

验证：

  • 无权用户是否还能召回敏感文档

10.2 工具越权测试 ​

验证：

  • 模型是否会绕过工具限制
  • 工具参数是否能被构造成越权请求

10.3 审批触发测试 ​

验证：

  • 高风险动作是否会进入审批
  • 审批拒绝后是否真的阻断

10.4 多轮污染测试 ​

验证：

  • 历史消息是否残留旧权限结果
  • handoff 是否带错租户上下文

10.5 缓存与状态测试 ​

验证：

  • 缓存结果是否按主体和租户隔离
  • 权限变更后旧缓存是否失效

10.6 临时提权与审批恢复测试 ​

验证：

  • 提权是否按时失效
  • 审批恢复后是否仍在原授权范围内
  • 紧急模式结束后是否自动回到默认权限

这些测试通常要和：

  • 红队测试
  • guardrails 回归
  • audit logs

一起看，才更完整。

11. 更适合企业的最小权限模型 ​

如果团队现在还没有成体系权限设计，可以先从下面这套最小方案开始：

  1. 身份层：明确 user、role、tenant、department
  2. 检索层：所有 query 必带权限过滤
  3. 工具层：工具按 scope 分级，默认 deny
  4. 动作层：写动作与高风险动作单独审批
  5. 状态层：会话、缓存、handoff 全部带权限上下文
  6. 审计层：所有关键决策留痕

这套虽然不是终态，但已经比“只在入口做鉴权”可靠得多。

12. 常见反模式 ​

12.1 只做前端权限，不做后端权限 ​

这样模型与工具层依然可能越权。

12.2 检索层不做权限过滤 ​

这在知识库场景里几乎是最危险的问题之一。

12.3 只限制工具，不限制参数范围 ​

最终容易出现：

  • 工具对了
  • 参数越权了

12.4 角色设计过粗 ​

结果是：

  • 一旦给了“管理员”
  • 就什么都能做

12.5 缓存和会话不带权限上下文 ​

最后问题往往不是出在主链路，而是旧状态复用。

12.6 只做静态角色，不处理属性和上下文 ​

这在 AI 系统里经常不够，因为很多决策依赖：

  • tenant
  • 文档分类
  • 工具参数
  • 审批状态
  • 环境上下文

12.7 没有职责分离与临时提权规则 ​

如果同一角色既能发起高风险动作、又能自己批准、还能长期保有提权，风险会非常高。

13. 推荐搭配阅读 ​

14. 重点官方资源 ​

15. 落地检查清单 ​

  • 是否区分了数据权限、工具权限、动作权限和审批权限
  • 检索层是否默认带权限过滤
  • 工具参数是否也受权限与范围约束
  • 会话、缓存和 handoff 是否带权限上下文
  • 高风险动作是否有人类在环
  • 审计日志是否能重建一次关键权限决策