基于角色的访问控制 (RBAC) 让您决定组织和项目中的哪些人可以执行哪些操作，无论是通过 API 还是在控制台中。两者采用相同的权限规则：如果某人可以调用某个端点（例如 /v1/chat/completions），就可以使用对应的控制台页面；缺少权限时，相关界面控件（例如 Playground 中的 上传 按钮）会被禁用。使用 RBAC，您可以：
- 对用户分组并批量分配权限
- 创建自定义角色，精确配置所需权限
- 在组织或项目级别设置访问范围
- 在控制台和 API 中实施一致的权限控制
核心概念
- 组织：您的顶层账户。组织角色可以授予对所有项目的访问权限。
- 项目：用于存放密钥、文件和资源的工作空间。项目角色仅授予对该项目的访问权限。
- 用户组：可被分配角色的一组用户。用户组可以通过 SCIM 从您的身份提供商同步，以自动更新成员信息。
- 角色：一组权限（例如模型请求或文件写入权限）。您可以在 组织设置中为组织创建角色，也可以在特定项目的设置中为该项目创建角色。创建后，组织角色或项目角色可以分配给用户或用户组。用户可以拥有多个角色，其访问权限为这些角色权限的并集。
- 权限：角色允许执行的具体操作（例如向模型发送请求、读取文件、写入文件、管理密钥）。
权限
下表列出了可用权限、包含这些权限的预设角色，以及是否可以为自定义角色配置这些权限。
| 类别 | 允许的操作 | 组织所有者权限 | 组织读取者权限 | 项目所有者权限 | 项目成员权限 | 项目查看者权限 | 可用于自定义角色 |
|---|---|---|---|---|---|---|---|
| 列出模型 | 列出此组织有权访问的模型 | Read | Read | Read | Read | Read | ✓ |
| 用户组 | 查看和管理用户组 | Read、Write | Read | Read、Write | Read、Write | Read | |
| 角色 | 查看和管理角色 | Read、Write | Read | Read、Write | Read、Write | Read | |
| 组织管理 | 管理组织的用户、项目、邀请、管理 API 密钥和速率限制 | Read、Write | |||||
| 用量 | 查看用量仪表板并导出数据 | Read | ✓ | ||||
| 外部密钥 | 查看和管理企业密钥管理功能所用的密钥 | Read、Write | |||||
| IP 允许列表 | 查看和管理 IP 允许列表 | Read、Write | |||||
| mTLS | 查看和管理双向 TLS 设置 | Read、Write | |||||
| OIDC | 查看和管理 OIDC 配置 | Read、Write | |||||
| 模型能力 | 向聊天补全、音频、嵌入向量和图像接口发送请求 | Request | Request | Request | Request | ✓ | |
| 助手 | 创建和检索助手 | Read、Write | Read、Write | Read、Write | Read、Write | Read | ✓ |
| 会话线程 | 创建和获取会话线程、消息和运行 | Read、Write | Read、Write | Read、Write | Read、Write | Read | ✓ |
| 评测 | 创建、获取和删除评测 | Read、Write | Read、Write | Read、Write | Read、Write | Read | ✓ |
| 微调 | 创建和获取微调作业 | Read、Write | Read、Write | Read、Write | Read、Write | Read | ✓ |
| 文件 | 创建和获取文件 | Read、Write | Read、Write | Read、Write | Read、Write | Read | ✓ |
| 向量存储 | 创建和获取向量存储 | Read、Write | Read、Write | Read、Write | Read、Write | ✓ | |
| Responses API | 创建响应 | Read、Write | Read、Write | Read、Write | Read、Write | ✓ | |
| 提示 | 创建和获取提示，用作 Responses API 和 Realtime API 的上下文 | Read、Write | Read、Write | Read、Write | Read、Write | Read | ✓ |
| Webhook | 在您的项目中创建和查看 Webhook | Read、Write | Read | Read、Write | Read、Write | Read | ✓ |
| 数据集 | 创建和获取数据集 | Read、Write | Read、Write | Read、Write | Read、Write | Read | ✓ |
| 应用 | 在控制台中创建、管理应用并提交审查 | Read、Write | ✓ | ||||
| 隧道 | 检查、使用和管理组织范围内的隧道 | Read、Use、Manage | ✓ | ||||
| 项目 API 密钥 | 允许用户管理自己的 API 密钥 | Read、Write | Read、Write | Read、Write | Read、Write | Read | ✓ |
| 项目管理 | 通过管理 API 管理项目用户、服务账户、API 密钥和速率限制 | Read、Write | Read、Write | ||||
| 批处理 | 创建和管理批处理作业 | Read、Write | Read、Write | Read、Write | Read、Write | Read | |
| 服务账户 | 查看和管理项目服务账户 | Read、Write | Read、Write | ||||
| 视频 | 创建和检索视频 | Read、Write | Read、Write | Read、Write | Read、Write | ||
| 语音 | 创建和检索语音 | Read、Write | Read、Write | Read、Write | Read、Write | Read | |
| 智能体构建器 | 在智能体构建器中创建和管理智能体与工作流 | Read、Write | Read | Read、Write | Read、Write | Read | ✓ |
批处理权限的连带授权
批处理权限包括准备批处理输入文件、执行请求和检索结果所需的访问权限。这些实际授予的访问权限与可在批处理中提交请求的端点是两回事；后者列于批处理 API 指南中。
| 批处理权限 | 额外授予的访问权限 |
|---|---|
读取（api.batch.read） | 文件读取（api.files.read），适用于 /v1/files |
写入（api.batch.write） | 批处理读取 列出模型（ api.model.read 和 model.read），适用于 /v1/models文件读取和写入（ api.files.read 和 api.files.write），适用于 /v1/files模型能力请求（ api.model.request 和 model.request），适用于 /v1/audio、/v1/chat/completions、/v1/embeddings、/v1/images、/v1/moderations、/v1/realtime 和 /v1/responses视频读取和写入（ api.videos.read 和 api.videos.write），适用于 /v1/videos |
设置 RBAC
角色变更和群组同步最多需要 30 分钟 才能传播生效。
-
创建群组 为团队添加群组（例如“数据科学”“支持”）。如果您使用 IdP，请启用 SCIM 同步，以保持群组成员信息最新。
-
创建自定义角色 从最小权限开始。例如：
- 模型测试员：模型读取、模型能力请求、评测
- 模型工程师：模型能力请求、文件读取/写入、微调
- 应用发布者：应用读取、应用写入
-
分配角色
- 组织级 角色适用于整个组织（组织内的所有项目）。
- 项目级 角色仅适用于该项目。 您可以向 用户 和 群组分配角色。用户可以拥有多个角色，其访问权限是这些角色权限的 并集。
-
验证 使用非所有者账户确认访问权限是否符合预期（包括 API 和控制台）。如果用户能看到超出其所需范围的内容，请调整角色。
遵循最小权限原则。先授予完成任务所需的最低权限，再按需增加。
访问权限配置示例
小型团队
- 为核心团队分配包含模型能力请求权限和文件读写权限的组织级角色。
- 为每个应用创建一个项目；仅将承包商添加到相关项目，并分配项目级角色。
较大型组织
- 从您的 IdP 同步用户组（例如“研究”“支持”“财务”）。
- 按职能创建自定义角色，并在组织级别分配；如果某个项目需要更严格的管控，则仅授予该项目专属的角色。
承包商与供应商
- 创建一个“承包商”用户组，不为其分配组织级角色。
- 将他们添加到特定项目，并分配权限范围较小的项目角色（例如只读访问权限）。
如何确定用户的访问权限
在控制台中，我们会合并以下角色：
- 来自 组织 的角色（直接分配及通过用户组获得）
- 来自 项目 的角色（直接分配及通过用户组获得）
最终生效的权限是所有已分配角色权限的 并集 。
如果使用项目内的 API 密钥发起请求，我们会检查分配给该 API 密钥的权限，并确保用户拥有授予这些权限的项目角色。例如，请求 /v1/models 时，API 密钥必须被授予 api.model.read 权限，且用户必须拥有包含 api.model.read 权限的项目角色。
最佳实践
- 用用户组体现组织结构：在您的 IdP 中按团队建立对应的用户组，并将角色分配给用户组，而非个人。
- 分离职责：将读取模型、上传文件和管理密钥等职责分开。
- 明确项目边界：将实验、预发布环境和生产环境放在不同的项目中。
- 定期审查：移除不再使用的角色和密钥；轮换敏感密钥。
- 以非所有者身份测试：在大范围推行前，验证访问权限是否符合预期。