我见过很多 AI 产品早期都从功能演示开始：聊天框能回答，知识库能上传，智能体能调用工具，管理后台能看到模型消耗。演示没有问题，但一到真实组织里就暴露出权限问题。销售能不能看到售后工单，客服能不能读合同，普通成员能不能调用高价模型，A 客户的知识库会不会被 B 客户召回，离职员工的 API key 是否还有效，模型回答引用了哪份资料，智能体执行动作时到底用谁的身份。这些问题不解决，产品越聪明越危险。

AI 产品的权限系统不能只做“登录后才能使用”。它要同时处理多租户、组织空间、角色、资源、操作、数据域、模型能力、工具权限、审计记录、成本预算和人工审批。更准确地说，权限系统不是一个后端中间件，而是贯穿产品架构的控制面。用户每一次检索、每一次模型调用、每一次文件读取、每一次工具执行、每一次导出和每一次后台配置，都应该落在同一套授权和审计体系里。

这篇文章按社区实践帖的方式讲 AI 产品权限系统怎么做，重点不讲概念炫技，而讲真实落地时哪些坑最容易踩，哪些边界必须先定，RBAC 和 ABAC 怎么配合，多租户怎么隔离，知识库和向量索引怎么做权限过滤，智能体工具怎么授权，审计日志怎么留，成本治理怎么和权限挂钩。

一、AI 产品权限比普通后台更难

普通后台系统里，用户通常通过菜单、按钮和列表访问资源。权限控制可以围绕页面、接口和数据行展开。AI 产品的访问方式不一样，用户可能通过自然语言提出一个跨资源请求。比如“帮我总结华东区这个季度所有高风险客户”，这句话背后可能涉及客户表、工单表、合同文档、销售记录、知识库、模型调用和报表导出。系统不能因为用户说得自然，就绕过原来的数据边界。

AI 产品还有一个特殊点：模型上下文本身就是数据暴露面。普通系统把一行数据返回给前端，用户看得到才算访问；AI 系统把资料放进模型上下文，即使最后回答没有展示原文，资料也已经被处理过。若上下文里混入无权限内容，后面再用提示词要求模型不要泄漏，并不能算安全。权限必须在检索、读取和工具调用之前生效。

知识库让问题更复杂。文档被切成片段，片段进入向量索引和全文索引，索引又可能被缓存。用户问一个问题时，系统召回的不是原文档，而是一批片段。权限系统如果只保护原文件下载，不保护片段召回，就会出现“文件打不开，但 AI 能总结”的漏洞。很多知识库权限事故就藏在这里。

智能体让问题进一步升级。聊天助手只回答，智能体会行动。它可能创建工单、发送邮件、修改配置、提交代码、发起退款、更新客户状态、调用数据库查询。每个动作都要判断当前用户是否有权执行，是否需要审批，是否有预算，是否允许由 AI 代操作。不能给智能体一个管理员 token，然后让它替所有用户做事。

模型能力本身也需要授权。长上下文、联网搜索、文件上传、代码执行、图片理解、批量任务、高级模型、外部供应商、本地敏感模型，都可能对应不同风险和成本。如果所有用户都能随意使用最贵模型和最强工具，账单和安全都会失控。

所以 AI 产品权限系统要回答的不只是“用户能不能打开这个页面”，而是“在当前租户、当前组织、当前任务、当前数据范围、当前模型和当前工具下，这个用户能不能让系统读取这些资料、生成这个结果、执行这个动作、保存这条记录、花掉这笔预算”。

二、先画资源图，不要先写权限表

权限设计第一步不是建 roles 表，而是画资源图。资源图要列出产品里所有需要被保护的对象：租户、组织、团队、项目、空间、用户、成员关系、知识库、文档、文档片段、文件、向量索引、会话、消息、模型调用、提示词模板、智能体、工具、任务、工作流、审批、审计日志、API key、预算、账单、报表、导出文件、系统配置。

资源图还要标出资源之间的归属关系。一个租户下有多个组织，一个组织下有多个空间，一个空间里有知识库、智能体和成员，一份文档属于某个知识库，一个片段属于某个文档版本，一次会话属于某个用户和空间，一个工具属于某个智能体或工作流，一次模型调用属于某个任务。归属关系不清，权限继承就会混乱。

很多团队跳过资源图，直接设计角色。结果角色越来越多，权限越来越乱。比如“管理员”到底是租户管理员、组织管理员、知识库管理员、模型管理员，还是系统超级管理员？“成员”能不能上传资料，能不能发布资料，能不能删除资料，能不能邀请别人，能不能查看成本？如果资源边界没画清，角色名会越来越像口号。

资源图还要区分业务资源和平台资源。业务资源包括客户、订单、合同、项目、工单、数据报表；平台资源包括模型、知识库、智能体、工具、API key、预算和审计。AI 产品常见错误是只管平台资源，不管业务资源。智能体调用 CRM 时，如果只检查“用户能不能用这个智能体”，不检查“用户能不能看这个客户”，就会越权。

权限设计也要把派生产物列出来。文档解析后的片段、embedding、摘要、缓存、导出文件、任务结果、评测样本、日志截图、错误信息，都可能包含原始敏感数据。很多系统只保护原始文件，却让摘要、缓存和日志自由流动。AI 产品里，派生产物数量很多，必须跟随原始资源继承权限或重新定义访问规则。

画完资源图后，再定义动作。常见动作包括读取、创建、更新、删除、分享、发布、导出、邀请、配置、调用、审批、执行、取消、恢复、查看审计、管理预算。不要把所有动作都简化成读写。AI 场景里，“读取资料”“把资料送入模型”“基于资料生成对外内容”“导出包含资料的报告”风险等级不同，不能用一个 read 覆盖。

三、多租户边界要先定

如果产品面向多个客户，租户边界必须先定。租户通常代表合同、账单、数据隔离和最高管理边界。组织、团队、项目和空间可以在租户内部变化，但租户之间的数据默认互不可见。AWS SaaS 资料里反复区分认证授权和租户隔离，这个区分对 AI 产品尤其重要：用户登录成功不代表他能访问所有租户数据。

多租户最常见的错误，是所有表都有 tenant_id，但并不是所有查询都强制带租户条件。早期接口少时还能靠工程师自觉，功能一多就会漏。AI 产品更危险，因为检索、任务、日志、缓存和索引查询不一定走同一套 ORM。某个后台批处理忘了加租户过滤，可能导致向量索引里混入别的租户片段。

租户隔离有多种实现方式。高隔离客户可以独立部署或独立数据库；中等隔离可以共享应用但独立 schema 或独立数据库；普通 SaaS 可以共享表并用租户字段和行级策略隔离。选择哪种方式取决于客户风险、合规要求、成本和运维能力。不要为所有客户都上最高隔离，也不要用最低隔离服务高敏客户。

共享表模式下，要尽量让数据库参与隔离。PostgreSQL Row Level Security 可以把租户过滤写进数据库策略，减少应用层漏条件的风险。应用层仍要检查权限，但数据库行级策略能作为第二道防线。尤其是知识库文档、任务、会话、消息、审计日志和 API key 这类核心表，不建议只靠业务代码约定。

向量索引也要做租户隔离。很多早期产品把所有文档片段放进一个 collection，只在召回后过滤租户。这个顺序不对。正确做法是检索前就带上租户和权限过滤，或者按租户、数据域拆索引。召回后再过滤会浪费性能，也可能在重排、日志或调试输出中暴露无权限片段。

对象存储要按租户分路径和权限。用户上传的 PDF、图片、音频、解析中间文件、缩略图、导出结果、智能体生成文件，都要有租户归属和生命周期。临时文件也不能放在公共目录里长期可访问。预签名链接要短时有效，并且生成前检查用户是否有权下载。

租户切换也要小心。有些用户属于多个租户，前端会提供租户切换。所有 API 请求都要带当前租户上下文，后端不能只根据用户 ID 推断默认租户。用户在 A 租户打开的会话、任务和导出链接，切到 B 租户后不应该继续可访问。会话上下文、缓存键和模型调用元数据都要包含租户 ID。

四、RBAC 管职责，ABAC 管场景

AI 产品通常需要 RBAC，但不能只靠 RBAC。RBAC 适合把职责打包成角色，例如租户管理员、组织管理员、空间管理员、知识库维护者、智能体配置员、普通成员、访客、审计查看者、财务查看者、开发者。角色能让权限管理更容易理解，也能减少逐人授权。

角色要少而清楚。早期最容易把每个客户需求都变成一个角色，最后出现“高级成员”“业务成员”“高级业务成员”“临时管理员”“项目管理员增强版”之类难以维护的角色。更稳的做法是把角色定义为稳定职责，把细粒度差异交给属性和策略。比如“知识库维护者”是角色，“只能维护某个空间的公开资料”是属性限制。

ABAC 用来处理动态场景。它根据用户属性、资源属性、操作属性和环境属性做判断。用户属性包括租户、部门、岗位、地区、认证方式、雇佣状态；资源属性包括租户、项目、密级、数据类型、所有者、状态、保留期限；操作属性包括读取、导出、调用模型、执行工具、发布、审批；环境属性包括时间、网络、设备、风险等级、供应商区域。NIST SP 800-162 对 ABAC 的定义很适合这类复杂授权。

AI 产品里，RBAC 和 ABAC 应该组合使用。比如客服主管角色可以查看工单，但 ABAC 继续限制只能查看本租户、本区域、本团队、当前授权客户的数据。知识库维护者可以上传文档，但只有文档责任人或空间管理员能发布到全员可见。开发者可以调用代码分析智能体，但涉及生产密钥的文件必须额外审批或脱敏。

ABAC 也适合模型路由。资源属性如果标记为高敏，策略可以禁止外部供应商，只允许本地模型或私有云模型；任务属性如果是合同审查，策略可以要求强模型和人工复核；用户属性如果是试用租户，策略可以限制高价模型和批量任务。这样权限系统不仅管数据访问，也管模型能力和成本。

策略表达要可测试。无论使用 Open Policy Agent、云厂商 IAM 条件、数据库策略还是自研策略引擎，都要有策略测试集。测试样本要覆盖允许、拒绝、跨租户、离职用户、过期成员、密级变化、角色撤销、模型禁用、工具写操作、导出限制等情况。权限规则如果只能靠人工脑补，迟早会出错。

策略结果要可解释。用户被拒绝时，前端不需要展示内部字段，但系统内部要知道拒绝原因：缺少角色、资源不在当前租户、文档密级过高、模型能力未开通、预算不足、操作需要审批。没有可解释的拒绝原因，客服和管理员很难处理真实问题。

五、知识库权限不能只控文件

AI 知识库权限的第一原则是：用户能召回的片段，必须是他有权访问的资料。不要把权限控制放在生成后，也不要只控制文件下载。模型上下文里出现无权限片段，本身就是越权。

文档进入知识库后，会产生多个对象：原始文件、解析文本、结构化元素、文档版本、片段、embedding、全文索引、摘要、引用、缩略图、缓存、评测样本。每个对象都要知道自己来自哪份文档、哪个版本、哪个租户、哪个空间、哪个权限范围。片段不能脱离文档权限独立漂浮。

权限变化要能同步到索引。员工离职、成员移出项目、文档从公开改成私密、客户合同到期、项目归档、资料删除，这些变化都应立即影响召回。理想情况下，索引查询实时读取权限元数据；如果为了性能做权限快照，也要有失效机制。不能等下一次全量重建才更新权限。

知识库还要区分资料状态。草稿、待审核、已发布、已归档、已删除、过期资料，不应该同等参与回答。普通用户默认只能检索已发布且有权限的资料；维护者可以查看草稿和解析结果；管理员可以查看失败任务和版本历史。状态本身就是权限条件。

引用也要权限过滤。一个回答可能引用多份资料，用户点击引用时仍要再次检查权限。不要因为回答已经生成，就让引用链接绕过资源访问控制。导出带引用的报告时，也要确认导出人有权导出这些来源。

知识库检索常见坑是先召回再过滤。向量检索召回一百条，重排后取十条，最后才过滤权限。这样不仅可能让无权限片段进入重排模型，也可能污染日志和质量评测。更稳的流程是：先按租户、空间、资源状态和用户权限缩小候选范围，再做向量和全文检索，再重排，再生成。

另一个常见坑是管理员调试入口泄漏。工程师为了排查召回质量，会做“查看原始片段”“查看检索结果”“查看模型上下文”的调试页面。如果这个页面没有严格权限，就会绕过正式产品权限。生产系统里，调试能力也必须有角色、审批、脱敏和审计。

六、智能体工具要按用户身份执行

智能体的工具权限，是 AI 产品最容易出事故的地方。很多早期实现会给智能体配置一个高权限服务账号，让它调用所有内部 API。演示时很方便，真实上线后非常危险。用户只要能让智能体执行，就可能间接获得服务账号的权限。

正确原则是：智能体代表某个用户或某个受控工作流执行，工具调用必须带上执行主体。用户发起的任务，应按用户身份和当前租户授权；系统定时任务，应按服务身份授权，并限制资源范围；审批后的动作，应记录审批人和执行人。不要让所有动作都落在同一个万能账号上。

工具要分级。只读工具风险较低，例如搜索文档、查询订单、读取项目状态，但也要受数据权限控制。写入工具风险更高，例如修改客户状态、发送邮件、创建发票、更新配置、提交代码、执行数据库变更。外部动作风险最高，例如付款、退款、删除数据、发布内容、封禁账号、触发生产部署。不同级别要有不同确认和审计。

工具输入要校验。模型生成的参数不能直接信任。比如模型生成客户 ID、金额、邮箱、SQL、文件路径、API 参数，都要经过类型校验、范围校验、权限校验和业务规则校验。不要把自然语言直接拼成 SQL 或 shell 命令，也不要让模型自由构造内部接口 URL。

工具结果要做最小返回。工具返回给模型的内容越多，泄漏风险越高，成本也越高。查询客户信息时，不一定要把完整身份证、手机号、合同原文都返回给模型。可以根据任务只返回必要字段，敏感字段脱敏，原始记录留在业务系统里。模型需要知道“该客户符合退款条件”，不一定需要看到所有支付细节。

高风险动作要有人类确认。确认界面应展示面向用户的关键信息：将要执行什么动作、影响哪个对象、依据是什么、是否可撤销、成本或风险是什么。不要把内部 JSON、工具名、参数字段暴露给普通用户。用户确认后，系统再调用工具，并把确认记录写入审计。

工具权限还要支持撤销和轮换。API key、OAuth token、机器人账号、集成凭证都要有所有者、有效期、权限范围和最后使用时间。成员离职或角色变化后，相关凭证要失效。智能体平台如果允许用户自定义工具，更要提供凭证隔离，不能让一个用户上传的工具影响整个租户。

七、模型权限和成本权限要一起设计

AI 产品里，模型能力本身就是资源。不同模型价格、能力、上下文长度、数据处理条款和风险等级不同。权限系统如果只管知识库和工具，不管模型，产品很快会出现成本失控和合规问题。

模型权限至少包括供应商权限、模型权限、能力权限和用量权限。供应商权限决定某个租户能不能使用外部供应商、国内供应商、本地模型或私有云模型。模型权限决定能否使用某个具体模型或能力别名。能力权限决定能否使用长上下文、图片理解、文件分析、代码执行、联网搜索、批量任务、智能体自动执行。用量权限决定每分钟、每天、每月能花多少额度。

成本预算要按租户、组织、团队、用户、应用和任务类型归因。只按供应商账单看总数没有意义。一个智能体任务可能包含问题改写、检索、重排、生成、工具调用总结、结果校验和失败重试。用户看到一次操作，系统可能发生多次模型调用。权限系统要能限制一次任务的最大预算，也要能限制某个用户或团队的月度预算。

高价模型不要直接暴露成随便选的下拉项。更好的方式是让产品暴露任务能力，例如“快速草稿”“高质量分析”“敏感资料本地处理”“长文档审阅”。背后由模型网关按权限、预算、质量要求和数据等级路由。普通用户不需要理解每个模型名，管理员需要能配置策略。

模型路由也要受数据等级控制。公开资料可以走通用外部模型，内部资料可能只能走签约供应商，高敏资料可能只能走私有化模型或本地模型。数据等级应来自知识库、业务对象和用户选择，而不是靠用户在提示词里说明“这是敏感资料”。系统判断到高敏内容后，应自动限制路由。

成本权限也要体现在产品体验里。用户启动大任务前，可以看到预计消耗或任务额度；预算不足时，系统可以提示申请额度、改用低成本模式或缩小资料范围；后台批处理要有并发和总预算限制。不要等供应商账单爆了，再去查是谁点了什么按钮。

模型使用审计要记录实际路由。响应里可以不展示复杂内部信息，但审计中必须知道用了哪个供应商、哪个模型、哪个能力名、为什么选择它、是否触发降级、消耗多少 token、费用估算多少。否则质量和成本问题无法追溯。

八、审计日志要能还原一次 AI 行为

AI 产品审计日志的目标，是在出现投诉、越权、错误回答、成本异常或安全事件时，能还原一次 AI 行为。只记录请求路径和状态码远远不够。一次 AI 行为可能包含用户提问、权限判断、知识库检索、模型调用、工具调用、人工确认、业务写入和最终输出。

最少要记录这些信息：租户、用户、角色、当前空间、业务对象、会话、任务、操作、权限结果、模型能力、供应商模型、输入输出 token、费用估算、知识库引用、工具调用、审批记录、成功失败、错误类型、时间和 trace ID。对高风险动作，还要记录动作前后的关键状态。

审计日志要结构化。不要只把一大段文本丢进日志。结构化字段能支持查询和告警，比如“过去一小时某租户高价模型消耗异常”“某用户连续触发越权拒绝”“某智能体工具失败率升高”“某文档被大量引用”“某供应商降级次数激增”。结构化审计也是成本治理和质量复盘的基础。

审计内容要分级保存。普通任务可以保存元数据、引用 ID、脱敏输入输出摘要；高风险任务可以保存完整执行轨迹；高敏资料任务可能只保存哈希、资源 ID、审批和权限结果。保存越多，排查越方便，但隐私风险越高。企业要根据数据等级设置保留期限和访问权限。

审计查看本身也要授权。很多团队把日志平台开放给所有工程师，结果日志绕过了产品权限。AI 日志可能包含客户数据、合同片段、模型上下文和工具返回。查看审计日志应有专门角色，敏感内容要脱敏，必要时走审批，所有查看行为也要记录。

审计要支持导出，但导出更要控制。客户可能要求导出自己的 AI 使用记录，企业内部也可能要做合规复盘。导出前要按租户和权限过滤，导出文件要有有效期，下载要审计。不要生成一个永久公开链接。

还有一个容易忽略的点：拒绝也要记录。权限拒绝、预算拒绝、模型策略拒绝、工具审批未通过、敏感资料拦截，都应该进入审计。拒绝记录能帮助管理员发现配置问题，也能帮助安全团队发现异常试探。

九、前端体验：不要把权限复杂度甩给用户

权限系统很复杂，但前端不能把复杂度直接甩给最终用户。用户不需要看到内部策略名、字段名、租户 ID、模型路由规则和权限表达式。面向最终用户的文案应该清楚说明当前能做什么、为什么不能做、下一步可以找谁或申请什么。

权限拒绝文案要分场景。没有登录，可以提示登录；没有加入空间，可以提示联系空间管理员；资料无权访问，可以提示当前账号没有该资料权限；预算不足，可以提示额度不足并提供申请入口；高风险动作需要审批，可以进入审批流程。不要统一显示“403 forbidden”或“权限校验失败”。

产品界面要避免展示用户无权操作的入口。普通成员没有管理预算权限，就不应该看到预算配置按钮；访客不能发布知识库，就不应该看到发布入口；没有高价模型权限，就不应该看到高价模式开关。必要时可以展示灰态和申请入口，但不要让用户频繁点击后才失败。

智能体执行高风险动作时，确认界面要清楚。比如“将向客户发送这封邮件”“将把订单状态改为已退款”“将创建一条生产变更申请”。用户要看到影响对象、关键信息、依据和可撤销性。不要展示工具 JSON，也不要把内部实现说成用户指令。

知识库引用的访问体验也要一致。用户看到引用后点击，如果无权访问，应给出明确提示，而不是报错页面。若回答中某些引用因为权限变化不可访问，应提示“该来源当前不可访问”，并避免继续展示敏感摘要。

管理员界面要提供权限解释工具。管理员需要知道某个用户为什么能或不能访问某资源，哪些角色生效，哪些 ABAC 条件命中，预算是否不足，模型能力是否开通。这个解释面向管理员，不面向普通用户。没有解释工具，权限问题会变成客服和工程师之间的来回猜测。

前端还要避免泄漏隐藏信息。有些系统会在无权限时显示资源标题、文件名或客户姓名，这本身可能泄漏。列表查询、搜索建议、自动补全、最近访问、通知、审计摘要，都要遵守同样的权限规则。

十、权限数据模型的一个实用起点

一个可落地的 AI 产品权限模型，可以从这些表或对象开始：租户、用户、成员关系、角色、权限、资源、资源成员、策略、知识库、文档、文档版本、片段、智能体、工具、模型能力、预算、任务、审计日志。具体实现可以根据技术栈调整，但概念不要缺。

成员关系表要记录用户属于哪个租户、哪个组织或空间，角色是什么，状态是否有效，加入时间和失效时间。不要只在用户表里放一个全局角色。真实企业里，同一个用户可能在 A 租户是管理员，在 B 租户只是访客，在某个空间是维护者，在另一个项目没有权限。

资源表或资源描述要统一表达归属。每个核心资源都有租户 ID、空间 ID、所有者、资源类型、状态、密级、创建者、更新时间和删除状态。文档片段、任务结果、导出文件这些派生产物也要能追溯到原始资源。权限判断时，策略引擎才能拿到足够属性。

角色和权限不要直接写死在代码里。代码里可以有默认权限集合，但产品应能在管理后台配置角色授权，至少支持启用或关闭某些能力。企业客户经常会要求自定义角色，比如“只能上传不能发布”“只能查看审计不能看内容”“只能管理模型预算不能管理成员”。如果一开始完全写死，后面会很痛。

策略层负责动态判断。比如资源密级高于用户级别则拒绝，文档未发布则只允许维护者查看，预算不足则拒绝高价模型，外部供应商禁止处理高敏资料，工具写操作需要审批，离职成员全部拒绝。策略可以用 OPA 这类通用引擎，也可以先做自研规则，但要保证可测试、可解释和可审计。

任务表很重要。AI 行为往往不是单次请求，而是一个任务。任务要记录发起人、租户、空间、目标、状态、模型调用、工具调用、引用、成本、审批和最终结果。后续审计、重试、暂停、取消和成本归因都依赖任务。

审计日志不要只作为文本日志存在。它应该是可查询的业务数据。核心字段进数据库或日志分析系统，敏感正文按策略保存。审计 ID 要能和会话、任务、模型调用、工具调用、业务写入关联起来。

十一、测试权限，不能只测正常用户

权限系统最怕只测“有权限用户能不能用”。真正应该重点测“无权限用户拿不到什么”。AI 产品的权限测试要覆盖 API、知识库、向量检索、工具调用、缓存、导出、日志、后台任务和前端显示。

第一类测试是跨租户。A 租户用户不能读取 B 租户文档，不能通过搜索看到 B 租户标题，不能召回 B 租户片段，不能下载 B 租户文件，不能看到 B 租户任务和审计，不能通过缓存拿到 B 租户回答。这个测试要覆盖所有入口，而不是只测主页面。

第二类测试是角色边界。访客不能上传，普通成员不能发布，维护者不能管理预算，空间管理员不能管理租户级配置，审计查看者不能修改内容，财务查看者不能读取无关知识库。每个角色都要有允许和拒绝样本。

第三类测试是 ABAC 条件。文档密级变化后权限是否立即变化；项目归档后是否只读；资料过期后是否不参与默认回答；用户离职后是否失效；预算不足后高价模型是否拒绝；高敏资料是否禁止外部模型；工作流是否要求审批。动态条件最容易漏。

第四类测试是知识库召回。给 A 用户提问，确认召回结果里没有无权限片段；给同一问题用 B 用户提问，结果应不同；删除或收紧文档权限后，确认片段不再出现；点击引用时再次校验权限。不要只看最终回答，要检查检索上下文。

第五类测试是智能体工具。让低权限用户尝试诱导智能体执行高权限动作，看工具层是否拒绝；让用户在提示词里要求“忽略权限”，看系统是否仍按策略执行；让模型生成越界参数，看工具校验是否拦截；让审批被拒绝，看后续动作是否停止。

第六类测试是缓存和日志。相同问题在不同租户下不能共用敏感缓存；调试页面不能显示无权限上下文；导出文件不能被无权限用户下载；日志查询不能绕过产品权限。很多生产事故都出现在这些旁路。

权限测试要自动化。每次改模型调用、知识库索引、工具框架、角色配置或多租户逻辑，都要跑权限回归。AI 功能迭代很快，如果权限测试跟不上，风险会被新功能反复引入。

十二、几个真实落地坑

第一个坑：用前端隐藏按钮当权限。前端隐藏只能改善体验，不能作为安全边界。AI 产品还有 API、智能体、后台任务和导出入口，所有后端操作都必须独立鉴权。

第二个坑：知识库按文件控权，片段不控权。用户不能打开文件，但检索能召回片段，模型还能总结。这是典型 AI 知识库越权。片段、摘要、embedding、缓存和引用都要继承权限。

第三个坑：一个管理员 token 调所有工具。这样智能体会绕过业务权限。工具调用必须按用户身份或受控服务身份执行，高风险动作要审批。

第四个坑：多租户只在业务表隔离，向量索引不隔离。原始文档查不到，不代表向量库召回不到。索引查询也要带租户和权限过滤，必要时物理拆分。

第五个坑：审计日志保存太多，又没人管。完整 prompt 和 response 对排查有用，但可能包含敏感资料。日志要分级、脱敏、限权和设置保留期限。

第六个坑：权限拒绝没有解释。用户只看到失败，管理员也不知道为什么失败。系统内部要能解释拒绝原因，前端要用面向用户的语言给出下一步。

第七个坑：预算和权限分离。用户虽然没有高价模型权限，却可以通过某个智能体间接触发高价模型；团队预算用完了，后台批处理还在跑。模型能力和成本必须进入授权体系。

第八个坑：只测正向流程。演示时管理员账号什么都能用，但真实用户一上来就遇到跨空间、跨租户、离职、预算不足、资料过期、审批未通过等复杂场景。权限系统要用反向样本测试。

第九个坑：把供应商安全条款当作自己的权限系统。模型供应商可以提供数据控制、企业管理和安全承诺，但你的产品仍要负责用户身份、资源授权、租户隔离、工具权限和业务审计。供应商不是你的业务权限边界。

第十个坑：把所有管理员都做成超级管理员。企业客户通常需要分权管理。租户管理员、空间管理员、知识库管理员、模型管理员、审计查看者、财务查看者最好分开，否则一个账号泄漏影响面太大。

十三、推荐落地顺序

第一步，先确定租户、组织、空间和资源模型。不要急着做复杂角色。先让每个资源都有明确归属，让每个请求都有当前租户和当前空间，让派生产物能追溯原始资源。

第二步，建立最小 RBAC。定义租户管理员、空间管理员、成员、访客、知识库维护者、审计查看者等基础角色。角色要少，职责要清楚。把页面、接口和核心资源先纳入角色控制。

第三步，把知识库权限做对。文档、版本、片段、索引、引用、下载、导出都要继承权限。检索前过滤，引用点击再校验，权限变化能及时生效。没有这一步，不要大规模开放企业知识库问答。

第四步，引入 ABAC。先从数据等级、资源状态、租户、空间、预算、模型供应商和工具风险做动态策略。不要一开始设计过度复杂的策略语言，但要让策略可测试、可解释。

第五步，收口模型调用。所有模型请求经过统一网关或统一 AI 服务，记录用户、租户、任务、模型、token、费用和路由结果。把高价模型、外部供应商、长上下文、批量任务和智能体执行纳入权限。

第六步，治理智能体工具。工具按用户身份执行，只读和写入分级，高风险动作人工确认，工具输入校验，工具结果最小返回，所有工具调用写审计。不要用万能服务账号上线真实客户。

第七步，完善审计和成本看板。审计能还原一次 AI 行为，成本能按租户、团队、用户、应用和任务归因。拒绝记录、审批记录、降级记录、越权尝试都要能查。

第八步，建立权限测试集。跨租户、角色边界、ABAC 条件、知识库召回、工具调用、缓存、导出、日志都要测试。每次上线 AI 新能力，权限测试必须一起跑。

这个顺序的核心是先保护数据，再开放能力；先把读权限做稳，再做写动作；先有审计，再扩大智能体执行范围。权限系统不是最后补的后台配置，而是 AI 产品能不能进入生产环境的前提。

十四、一个参考架构

一个实用的 AI 产品权限架构，可以分成六层。第一层是身份层，接入 SSO、企业账号、OAuth、SAML、OIDC 或内部账号体系，确认用户是谁，属于哪些租户和组织。第二层是资源层，统一记录租户、空间、知识库、文档、任务、智能体、工具、模型能力和预算的归属与状态。第三层是策略层，用 RBAC 和 ABAC 判断用户是否能对资源执行某个动作。

第四层是执行层，包括知识库检索、模型网关、工具调用、工作流引擎和导出服务。执行层不能绕过策略层。知识库检索要带权限过滤，模型网关要检查模型能力和预算，工具调用要按执行主体授权，导出服务要重新校验资源访问。

第五层是审计层，记录每次权限判断、模型调用、检索、工具执行、审批、导出和失败。审计层要能串起一次任务，而不是散落在多个日志里。第六层是运营层，提供管理员配置、权限解释、预算管理、审计查询、异常告警和质量复盘。

这个架构里，模型不是权限中心，智能体也不是权限中心。真正的权限中心是资源、身份和策略。模型只在被允许的上下文里生成，智能体只在被允许的工具范围内行动。这样即使模型被提示注入诱导，底层工具和数据仍会拒绝越权请求。

如果团队早期人少，可以不用一次做完整平台，但边界要保留。至少做到：所有表有租户归属，所有 API 从后端取当前租户，所有知识库片段带权限元数据，所有模型调用有用户和任务 ID，所有工具调用检查用户权限，所有高风险动作需要确认，所有审计能查到关键链路。

十五、结语：权限系统决定 AI 产品上限

AI 产品越强，权限系统越重要。一个只会回答公开资料的助手，权限问题相对简单；一个能读取企业知识库、调用业务工具、生成报告、执行动作的智能体平台，权限就是产品骨架。骨架不稳，能力越强，风险越大。

真正生产级的 AI 产品，不会把权限做成上线前的补丁。它会从资源模型开始，把租户隔离、RBAC、ABAC、数据隔离、模型权限、工具授权、审计、成本预算和前端体验连成一套系统。用户用自然语言工作，但系统不能用自然语言权限。每一次读取、生成、调用和执行，都要落到明确的身份、资源、动作和策略上。

权限系统做得好，AI 产品才能放心开放给更多团队、更多客户和更多业务流程。权限系统做不好，产品会长期停留在演示环境，只能让管理员账号展示能力，却不敢进入真实组织。AI 产品最终拼的不只是模型效果，也是谁能把聪明能力放进可靠边界里。

参考资料

1. NIST SP 800-162 Attribute Based Access Control: https://csrc.nist.gov/pubs/sp/800/162/upd2/final
2. NIST Role Based Access Control project: https://csrc.nist.gov/Projects/Role-Based-Access-Control
3. OWASP Authorization Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
4. OWASP API Security Top 10: https://owasp.org/API-Security/editions/2023/en/0x11-t10/
5. OWASP Top 10 for Large Language Model Applications: https://owasp.org/www-project-top-10-for-large-language-model-applications
6. AWS SaaS Architecture Fundamentals, tenant isolation: https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/tenant-isolation.html
7. AWS IAM attribute based access control: https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html
8. PostgreSQL Row Security Policies: https://www.postgresql.org/docs/current/ddl-rowsecurity.html
9. Open Policy Agent policy language: https://www.openpolicyagent.org/docs/latest/policy-language/
10. Microsoft Entra role-based access control: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/
11. Microsoft Entra attribute-based access control: https://learn.microsoft.com/en-us/azure/role-based-access-control/conditions-overview
12. Google Cloud IAM audit logging: https://cloud.google.com/iam/docs/audit-logging
13. OpenAI API data usage policies: https://openai.com/policies/api-data-usage-policies/
14. Anthropic Trust Center: https://trust.anthropic.com/