AI SaaS平台权限体系设计：从RBAC到对象级鉴权实践-代码聚汇网

AI SaaS平台权限体系设计：从RBAC到对象级鉴权实践

丁茂华·2026-09-04·阅读 89 GEO检测（免费）

RBAC权限模型AI SaaS

|难度：普通|阅读约 45 分钟

很多人把AI SaaS平台的用户权限体系设计想简单了，觉得不就是“用户表加角色表，登录后查一下角色，再判断能不能点某个按钮”嘛。但真把一个带模型调用、数据集管理、Agent任务、API配额计费等功能的AI SaaS产品上线之后，你会发现权限问题永远不只出现在菜单层级，更多是出现在对象层级、动作层级甚至Token层级的越权里。今天趁着一个周末复盘的空档，我把做AI SaaS时梳理权限模型到最终落地RBAC的这套实践完整写下来，全程不贴官方废话，只讲我在选型、建表、编码和排障过程中真正用到并且验证有效的方案。

本文适合至少已经了解基本RBAC概念、准备在AI SaaS产品里动手做权限体系的技术负责人或后端开发。如果你还在犹豫是纯自研还是接现成框架，这篇也能帮你看清各自边界。我会重点拆解资源维度的权限设计、AI Agent操作时的授权难题、以及多租户下容易出现的越权场景，尽量做到直接抄作业。

1. AI SaaS平台的权限需求远比你想象的复杂

1.1 传统RBAC解决的只是一半问题

先说为什么我不建议直接照搬十年前论坛系统的角色权限模型。传统RBAC的核心是“用户-角色-权限”三层，权限往往是一个个功能点，比如“创建数据集”“删除模型”“查看账单”。这种模型适合业务边界清晰、资源类型少的后台系统，但对AI SaaS而言，用户的权限经常要和具体资源绑定：A用户只能看到自己创建的LoRA模型，B用户只能调用某个已开通的模型服务。如果权限只做到功能点级别，那你只能允许用户“查看模型”，但他能看哪些模型，还需另配一套规则。

在搭建我们自己的AI智能体编排平台时，一开始我就是加的“普通成员/超级管理员”两级角色，上线第三天就接到一条故障反馈：某个普通用户能通过直接改URL里的项目ID，访问到同租户另一个项目下的Prompt调试记录。问题并不出在登录鉴权，而在于我的接口只校验了“该用户是不是该项目的成员”，却没有校验“该用户在项目内是否拥有读取调试记录这个动作的权限”。传统RBAC里“角色”这个中间层管住了动作，却管不住动作作用在哪个对象上。

所以我对AI SaaS平台的权限模型做了这样的拉高：RBAC要解决的是“谁能做什么”，但要真正避免越权，还需要在每一个资源实例前回答“谁能对哪一条数据做”。这正是业界常说的对象级权限，通俗一点就是把菜单级权限和行级权限拆开设计。很多入门教程告诉你RBAC已经足够，那是指“角色管理本身”，你的平台若要接API Key、模型租户隔离，那RBAC一定要突破五张表的概念，落成“角色+资源范围+权限约束”的组合。

1.2 AI产品的资源类型长什么样

为了讲清模型设计，我先给出一份很典型的AI SaaS资源清单。你可以对照自己的平台进行删减：

应用：可视化搭建的对话应用、Agent应用、工作流应用，每一项都有自己的粒度。
模型服务：为每个租户开通的模型API、私有化部署的模型服务、模型版本。
Dataset数据集：用户上传的训练数据、标注数据、评测集文件。
Prompt模板：可复用的提示词资产。
知识库及文档分段：企业版几乎都是按数据源和知识库做隔离。
Agent任务实例：一次自动化任务运行，包含输入、中间步骤日志、输出结果、Token消耗。
批量推理任务：定时执行任务、异步任务组。
费用与配额：账户余额、模型配额、调用次数。
团队成员：邀请成员、管理成员角色。

你会发现前六项属于典型的“业务数据”，而最后两项既是资源，也经常被当作权限管控的元数据。比如一个子账号在调用某个模型功能时，系统要同时检查“该子账号所在工作区是否开通了此模型”“子账号的角色允许不允许调用外部模型”“该子账号的配额是否足够”。这三层任何一个没打通，都会出现权限或计费上的漏洞。

1.3 先治权限设计的两个典型病

每个把权限做崩的项目，踩的坑都差不多，我在Code Review和线上事故复盘里总结了两种典型：一是“前端藏按钮，后端裸奔”，很多团队只是把没权限的按钮从界面上隐藏起来，但接口只要知道了ID就能调通。二是“租户看到别的租户”，开发时全员使用同一份开发数据，导致SQL在过滤租户ID时漏了一个查询条件，结果线上用户通过翻页能拉到其他公司的私有知识库片段。

用一句话概括我的结论：AI SaaS平台必须采用“三层权限检查”的降级方案。第一层，基础身份认证；第二层，RBAC角色判定，解决“能不能触发该功能”的问题；第三层，资源Owner和数据范围判定，解决“能触发该功能但能不能动这条记录”的问题。每一层都不能省略，实践中也少了任何一层都会成为隐患加高危险。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 数据模型设计：从五张表到可落地的九张表

2.1 基础表设计要避开的坑

很多老项目里权限相关表只有五张左右，但到了真实AI产品中，我需要额外增加“资源范围”“动作权限策略”等概念。先展示基础RBAC表的建表方式，加了编号便于回忆：

sql复制--用户主表，这里的字段会和租户/成员关系整合
CREATE TABLE auth_user (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    email VARCHAR(255) UNIQUE NOT NULL,
    password_hash VARCHAR(128) NOT NULL,
    status TINYINT NOT NULL DEFAULT 1,
    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
);

--角色表，作用域是全局还是某个租户
CREATE TABLE auth_role (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    role_code VARCHAR(64) UNIQUE NOT NULL,
    role_name VARCHAR(128) NOT NULL,
    scope VARCHAR(32) NOT NULL DEFAULT 'WORKSPACE',
    -- 可选值：GLOBAL/WORKSPACE
    data_scope VARCHAR(32) NOT NULL DEFAULT 'SELF',
    description VARCHAR(512),
    is_system TINYINT NOT NULL DEFAULT 0
);

-- 权限资源表（权限点）
CREATE TABLE auth_permission (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    perm_code VARCHAR(128) UNIQUE NOT NULL,
    display_name VARCHAR(128) NOT NULL,
    resource_type VARCHAR(64) NOT NULL,
    action VARCHAR(64) NOT NULL,