服务器最小权限管理需覆盖全链路，从数据写入到结果生成按“租户+角色+资源”三重维度控制；关系型库、向量库、对象存储须同步隔离；权限下推至检索与重排环节；支持abac动态策略、文档级水印脱敏及秒级权限同步；安全网关作为枢纽统一鉴权与审计。
服务器最小权限管理不是加一道锁，而是从数据写入、索引构建、检索执行到结果生成，全程按“租户+角色+资源”三重维度卡住访问路径。企业级多租户隔离真正的难点不在“能不能分”，而在“分得够不够细、下推得够不够深”。很多系统在API层做了租户校验，但向量库检索时没带租户上下文，权限就断在了第一步。
租户隔离必须覆盖全链路存储层
只靠数据库加 tenant_id 字段远远不够。真实场景中，三类存储必须同步隔离：
- 关系型数据库：所有业务表（订单、用户、商品）必须含 tenant_id，且查询一律强制走该字段索引；禁止跨租户 JOIN 或视图共享
- 向量数据库：每个租户应有独立 collection 或命名空间前缀（如 vec_company_a_docs），避免混合索引导致越权召回
- 对象存储：文件路径必须嵌入租户标识，例如 s3://bucket/docs/{tenant_id}/2026/contract_v2.pdf；禁用纯递增ID或可预测路径
权限下推要落到检索与重排环节
权限不能只在应用层做“事后过滤”。一旦检索返回了其他租户的片段，后续重排、Prompt拼接、LLM生成就已暴露风险。正确做法是：
- 向量检索前，将当前请求的 tenant_id + 用户角色 + 文档可见范围 编码为元数据过滤条件，传入检索接口
- 混合检索（关键词+向量）时，BM25 和向量相似度得分需统一在租户上下文中归一化，防止跨租户文档因高关键词匹配被错误召回
- 重排模型输入必须包含租户上下文特征（如租户行业标签、文档密级字段），让排序器天然“知道谁不该排前面”
最小权限需支持动态策略与实时生效
静态RBAC无法应对研发、法务、销售等角色对同一份合同的不同查看需求。企业级方案应支持：
- 基于属性的访问控制（ABAC）：策略可定义为“当 doc.classification == 'confidential' 且 user.department == 'legal' 时允许读取”
- 文档级动态水印与脱敏：非授权用户看到的PDF摘要自动隐藏金额、替换人名，且水印含用户账号与时间戳
- 权限变更秒级同步：用户调岗或离职后，其访问令牌在10秒内失效，向量库缓存、ES索引、API网关鉴权缓存全部联动刷新
安全网关是权限落地的关键枢纽
不要让每个服务自己实现鉴权逻辑。应在统一入口部署轻量级安全网关，承担三件事：
- 身份可信锚点：复用企业微信/钉钉/AD账号体系，不维护第二套凭证
- 请求上下文化：解析JWT中的 tenant_id、role、scopes，注入下游服务调用头（如 X-Tenant-ID、X-Allowed-Resources）
- 出口收敛与审计：所有出向数据流经网关，自动记录谁、何时、访问了哪个租户的哪类资源，满足等保三级日志留存要求
