角色型存取控制 (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 | ✓ | |
| Assistants | 建立及擷取 Assistants | 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 | ✓ |
| Webhooks | 在你的專案中建立及檢視 Webhooks | 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） | 適用於 /v1/files 的檔案讀取權限（api.files.read） |
寫入（api.batch.write） | 批次處理讀取權限 適用於 /v1/models 的列出模型權限（api.model.read 和 model.read）適用於 /v1/files 的檔案讀取及寫入權限（api.files.read 和 api.files.write）適用於 /v1/audio、/v1/chat/completions、/v1/embeddings、/v1/images、/v1/moderations、/v1/realtime 及 /v1/responses 的模型能力請求權限（api.model.request 和 model.request）適用於 /v1/videos 的影片讀取及寫入權限（api.videos.read 和 api.videos.write） |
設定 RBAC
角色變更及群組同步最多可能需要 30 分鐘 才會全面生效。
-
建立群組 為團隊新增群組（例如「資料科學」、「支援」）。如果你使用身分識別提供者（IdP），請啟用 SCIM 同步，讓群組成員資格保持最新。
-
建立自訂角色 從最小權限開始。例如：
- 模型測試人員：模型讀取、模型能力請求、評估
- 模型工程師：模型能力請求、檔案讀取／寫入、微調
- App 發布者：應用程式讀取、應用程式寫入
-
指派角色
- 組織層級 的角色適用於整個組織（組織內的所有專案）。
- 專案層級 的角色僅適用於該專案。 你可以將角色指派給 使用者 和 群組。使用者可以同時擁有多個角色；實際存取權為這些角色權限的 聯集。
-
驗證 使用非擁有者帳戶，確認 API 和儀表板的存取權限符合預期。如果使用者能看到超出需求範圍的內容，請調整角色。
遵循最小權限原則。先授予執行任務所需的最低權限，再視需要增加。
存取權限組態範例
小型團隊
- 為核心團隊指派組織層級角色，授予模型能力請求及檔案讀取／寫入權限。
- 為每個應用程式建立專案；僅將外包人員加入相關專案，並指派專案層級角色。
較大型組織
- 從 IdP 同步群組（例如「研究」、「支援」、「財務」）。
- 依職能建立自訂角色，並在組織層級指派；若專案需要更嚴格的控管，則只授予該專案專屬的角色。
外包人員與供應商
- 建立「外包人員」群組，不指派任何組織層級角色。
- 將他們加入特定專案，並指派權限範圍受限的專案角色（例如僅允許唯讀存取）。
如何判定使用者的存取權限
在儀表板中，我們會合併以下角色：
- 來自 組織 的角色（直接指派及透過群組取得）
- 來自 專案 的角色（直接指派及透過群組取得）
實際生效的權限是所有已指派角色權限的 聯集 。
如果使用專案內的 API 金鑰發送請求，我們會根據指派給該 API 金鑰的權限，確認使用者具有授予這些權限的專案角色。例如，向 /v1/models 發送請求時，API 金鑰必須獲指派 api.model.read 權限，使用者也必須具有包含 api.model.read 權限的專案角色。
最佳實務
- 以群組反映組織架構：依照 IdP 中的團隊建立對應群組，並將角色指派給群組，而非個別使用者。
- 職責分離：將讀取模型、上傳檔案和管理金鑰的職責分開。
- 劃分專案界線：將實驗、預備環境和正式環境分別放在不同專案中。
- 定期審查：移除未使用的角色和金鑰，並輪替敏感金鑰。
- 以非擁有者身分測試：在全面推出前，驗證存取權限是否符合預期。