第 24 章：权限与数据边界

这是《LLM 应用开发 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 LLM 应用必须继承企业已有的身份、租户、角色和数据权限体系。模型不能决定用户能看什么，所有数据访问都应由服务端在检索或查询前强制过滤。

24.1 身份链路

User
  -> Identity Provider
     -> Access Token
        -> Gateway
           -> Application
              -> Retrieval / Tools / DB

每次请求都要确定：

1. 用户 ID；
2. 租户 ID；
3. 角色；
4. 组；
5. 数据范围；
6. 会话 ID；
7. 审批权限；
8. 令牌有效期。

不能仅靠前端传来的 user_id。

24.2 权限模型

示例：

{
  "tenant_id": "tenant-a",
  "user_id": "u-100",
  "roles": ["cs_agent"],
  "groups": ["north_region"],
  "data_scope": {
    "order": "assigned_or_own",
    "doc": ["public", "internal", "cs_kb"]
  }
}

24.3 RAG 边界

错误流程：

向量检索 top K
  -> 应用层再过滤权限

风险：相关文档可能因未带权限而被过滤掉，或实现失误导致泄露。

正确流程：

认证
  -> 构造过滤条件
     -> 检索时执行 tenant/acl/status
        -> rerank
           -> 引用再校验

查询条件必须包含：

1. tenant；
2. ACL；
3. 文档状态；
4. 生效时间；
5. 数据区域；
6. 业务归属。

24.4 工具边界

工具不应直接暴露内部服务，应包一层授权：

def list_orders(args, current_user):
    if current_user.is_agent:
        return db.orders.filter(assignee_id=current_user.id)
    return db.orders.filter(user_id=current_user.id)

边界原则：

1. 工具凭证最小权限；
2. 服务间调用认证；
3. 写操作有独立授权；
4. 查询范围绑定当前用户；
5. 分页限制；
6. 字段投影；
7. 审计。

24.5 会话隔离

会话可能跨设备和跨时间，但权限必须实时计算。

风险场景：

1. 用户登出后继续使用旧 token；
2. 角色变更后仍访问旧文档；
3. 共享设备保留上下文；
4. 缓存跨用户复用；
5. 多租户系统缓存键缺失。

处理：

1. token 校验和刷新；
2. 权限版本检查；
3. 缓存键包含权限主体；
4. 登出清理会话；
5. 高敏操作重新认证；
6. 管理员切换身份时重置上下文。

24.6 脱敏

示例：

手机号：138****5678
身份证：110***********1234
银行卡：**** **** **** 1234

24.7 多租户

隔离方式：

无论哪种方式，应用查询必须强制 tenant 条件，并防止缓存、对象存储和日志串租户。

24.8 审批

Agent 请求高危动作
  -> 生成动作详情
     -> 检查权限
        -> 用户或审批人确认
           -> 服务端执行
              -> 回执和审计

审批要绑定：

1. 请求 ID；
2. 目标资源；
3. 变更内容；
4. 操作者；
5. 审批者；
6. 时间；
7. 版本或状态；
8. 结果。

24.9 测试

权限测试必须包含：

1. 未登录；
2. token 过期；
3. 跨用户读；
4. 跨租户读；
5. 角色降级；
6. 文档 ACL 变化；
7. 缓存命中；
8. 引用输出；
9. 工具参数替换；
10. 高危操作未审批。

这些用例应自动化并阻止发布。

本章小结

权限和数据边界必须由服务端强制执行。检索前过滤、工具包装授权、缓存隔离、实时校验和高危审批是关键点。模型只能处理已经授权的数据，不能成为权限判断点。

思考题

1. 为什么不能先检索再由应用补权限？
2. 会话缓存如何避免跨用户泄露？
3. 工具凭证为什么要最小权限？
4. 角色变更后如何让权限及时生效？
5. 高危动作审批应记录哪些信息？