AI 自動化平台處理敏感資料和關鍵的 workflow。客戶記錄流經 recipe 步驟。財務報表產生並分發。內部通訊起草後發出。存取控制模型必須與重要性相匹配。
「管理員或使用者」的二分法已不敷使用。你需要一個能閱讀稽核記錄但不能執行任何操作的合規人員。你需要管理團隊自動化但不能觸及其他部門的部門主管。你需要與組織架構相符的清晰界線，而非扁平的二元開關。
本文涵蓋 JieGou 的 RBAC 系統：6 種角色階層、26 項細緻權限、部門範圍覆寫，以及在每次 API 呼叫上執行的強制機制。
六種角色階層
JieGou 中的每位使用者都有一個全域角色——一個單一的數值等級，決定其在整個帳戶中的基準權限。
| 角色 | 等級 | 用途 |
|---|---|---|
| Owner | 50 | 帳戶建立者。完全存取權限，包括刪除帳戶。 |
| Admin | 40 | 完整管理權：帳單、使用者、API key、跨部門分析。 |
| Dept Lead | 30 | 部門領導者。編輯/刪除所屬部門的任何內容。安裝套件。推廣 workflow。 |
| Member | 20 | 標準使用者。建立內容、編輯自己的內容、執行 recipe/workflow、管理排程。 |
| Auditor | 15 | 稽核記錄、分析、治理的唯讀存取。無法建立或執行。 |
| Viewer | 10 | 內容的唯讀存取。無法執行任何操作。 |
數值等級並非任意設定。它們實現了 O(1) 權限檢查——系統不需遍歷角色清單，而是比較兩個整數。權限需要最低等級，使用者要麼符合要求，要麼不符合。
Auditor 角色
Auditor 是最新加入的角色，專為合規設計。它位於 Viewer（10）和 Member（20）之間，等級為 15。
與 Viewer 的關鍵差異：Auditor 擁有 audit:read 權限。他們可以存取稽核記錄、分析儀表板和治理報告。Viewer 不行。
與 Member 的關鍵差異：Auditor 無法建立內容、執行 recipe、執行 workflow 或管理排程。他們只觀察和報告。僅此而已。
這對受監管產業很重要。你的合規人員需要驗證 workflow 是否遵循政策、資料處理是否符合要求，以及使用者活動是否符合治理框架。他們不應需要——也不應擁有——修改或執行任何操作的能力。
Auditor 可用於 SSO 群組對角色的對應，因此你可以從 IdP 自動配置合規人員。將你的 compliance-team 或 internal-audit 群組對應到 Auditor 角色，這些群組的新成員在首次登入時就能獲得正確的存取權限。無需手動指派角色。
橫跨 8 類別的 26 項權限
角色是簡寫。權限才是實際被檢查的項目。JieGou 定義了 26 項細緻權限，分為 8 個類別：
帳戶（4 項權限）
| 權限 | 最低角色 | 說明 |
|---|---|---|
account:delete | Owner | 刪除整個帳戶 |
account:admin | Admin | 管理操作（SSO 設定、帳戶設定） |
account:settings | Admin | 管理帳戶層級設定 |
account:billing | Admin | 管理帳單和訂閱 |
使用者（2 項權限）
| 權限 | 最低角色 | 說明 |
|---|---|---|
users:manage | Admin | 管理帳戶中的所有使用者 |
users:manage-department | Dept Lead | 管理自己部門內的使用者 |
內容（6 項權限）
| 權限 | 最低角色 | 說明 |
|---|---|---|
content:create | Member | 建立新的 recipe、workflow、文件 |
content:edit-own | Member | 編輯自己建立的內容 |
content:edit | Dept Lead | 編輯部門內的內容 |
content:edit-any | Admin | 編輯所有部門的任何內容 |
content:delete-any | Admin | 刪除所有部門的任何內容 |
content:read | Viewer | 讀取內容（recipe、workflow、文件） |
執行（3 項權限）
| 權限 | 最低角色 | 說明 |
|---|---|---|
execution:run | Member | 執行 recipe 和 workflow |
execution:schedules | Member | 建立和管理排程執行 |
execution:triggers | Member | 設定事件驅動的觸發器 |
分析（2 項權限）
| 權限 | 最低角色 | 說明 |
|---|---|---|
analytics:read-department | Auditor | 讀取自己部門的分析資料 |
analytics:read-all | Admin | 讀取所有部門的分析資料 |
功能（4 項權限）
| 權限 | 最低角色 | 說明 |
|---|---|---|
features:chat | Member | 使用 AI 聊天介面 |
features:documents | Member | 管理 knowledge base 文件 |
features:packs | Dept Lead | 安裝和管理部門套件 |
features:connectors | Admin | 設定 MCP connector 和整合 |
治理（3 項權限）
| 權限 | 最低角色 | 說明 |
|---|---|---|
governance:audit | Auditor | 讀取稽核記錄和治理報告 |
governance:environments | Dept Lead | 管理部署環境 |
governance:promote | Dept Lead | 在環境之間推廣 workflow |
安全（2 項權限）
| 權限 | 最低角色 | 說明 |
|---|---|---|
security:byok | Admin | 管理 BYOK API key |
security:embedded-api | Admin | 設定 embedded API |
角色到權限的對應是靜態的。Dept Lead（等級 30）自動擁有所有最低角色為 30 或以下的權限。沒有個別使用者權限覆寫，沒有自訂角色定義。這使模型保持可稽核性——你可以查看使用者的角色，就能確切知道他們能做什麼和不能做什麼。
部門範圍的角色覆寫
全域角色適用於所有地方。但組織並非扁平結構。產品經理可能在全域需要 Member 存取權限，但在產品部門需要 Dept Lead 存取權限來管理團隊的自動化。
部門範圍覆寫解決了這個問題。使用者有一個全域角色，加上零個或多個特定部門的角色覆寫。
範例：Sarah 在全域是 Member。她在銷售部門有 Dept Lead 覆寫。在銷售部門，她可以編輯任何內容、安裝套件並推廣 workflow。在工程部門，她是標準 Member——她只能編輯自己的內容。
關鍵設計原則：覆寫只能提升，永不降低。如果你是全域 Admin，但在工程部門有 Viewer 覆寫，你在工程部門的有效角色仍然是 Admin。覆寫會被忽略，因為它會降低存取權限。這防止配置錯誤的覆寫意外鎖定某人應該能存取的部門。
有效角色解析
當系統需要確定使用者在特定部門可以做什麼時，它會執行此解析：
- 檢查此使用者在此部門是否存在部門覆寫
- 如果覆寫存在，回傳全域角色和覆寫中的較高者
- 如果沒有覆寫，回傳全域角色
偽代碼：
effectiveRole(user, department):
override = getDepartmentOverride(user, department)
if override exists:
return max(user.globalRole, override.role)
return user.globalRole部門範圍的權限檢查使用此有效角色。當 Sarah 嘗試在銷售部門安裝套件時，系統解析她在銷售部門的有效角色（Dept Lead，等級 30），檢查 features:packs 所需的最低等級（30），並授予存取權限。當她在工程部門嘗試相同操作時，她的有效角色是 Member（20），低於所需等級。
防提權規則
角色變更是系統中最敏感的安全操作。四項規則防止權限提升：
-
你不能變更自己的角色。 不能自我晉升。想成為 owner 的 admin 需要另一個 owner 進行變更。
-
你不能指派 Owner 角色。 Owner 轉移是一個獨立、刻意的操作，有自己的保護措施。它不會透過標準角色變更 API 發生。
-
你不能指派大於或等於自己角色的角色（除非你是 Owner）。Admin（40）可以指派 Dept Lead（30）、Member（20）、Auditor（15）或 Viewer（10）。他們不能指派 Admin（40）或 Owner（50）。只有 Owner 可以建立其他 Admin。
-
你不能變更角色大於或等於自己角色的人的角色（除非你是 Owner）。Admin 不能修改另一個 Admin 的角色。Dept Lead 不能修改 Admin 的角色。階層向上嚴格執行。
這些規則完美組合。綜合起來，它們保證沒有使用者可以提升自己或同儕的權限——只有 Owner 不受此約束。
權限如何強制執行
JieGou 中的每個 API 路由在執行任何業務邏輯之前，都會經過三步驗證防護：
步驟 1：驗證 session cookie。 HTTP cookie 的 session token 會對 Firebase Auth 進行驗證。結果會快取在 Redis 中，TTL 為 5 分鐘，因此來自同一 session 的重複請求不會在每次呼叫時都存取 Firebase Auth。
步驟 2：查找 AccountUser 記錄。 從 Firestore 取得使用者的帳戶成員資格——包括其全域角色和部門覆寫。這也會快取在 Redis 中，TTL 為 5 分鐘。
步驟 3：根據角色階層檢查權限。 所需權限對應到其最低角色等級。使用者的有效角色（如果檢查是部門範圍的，則考慮部門覆寫）會與之比較。這是 O(1)——一次雜湊查找以找到最低等級，加上一次數值比較。
權限檢查時不需要資料庫查詢。不需要遍歷權限清單。兩次快取查找和一次整數比較。
資源層級檢查
除了基於角色的權限之外，個別資源（recipe、workflow、文件）還有基於所有權的存取規則：
- Owner、Admin、Dept Lead——可以修改其範圍內的任何資源
- Member——只能修改自己建立的資源
- Auditor、Viewer——不能修改任何資源
這與角色層級權限結合。擁有 content:edit-own 的 Member 只能編輯 resource.createdBy === user.id 的資源。擁有 content:edit 的 Dept Lead 可以編輯部門內的任何資源，無論是誰建立的。
與平台功能整合
RBAC 並非孤立的——它連接到每個主要的平台子系統：
審批閘道。 審批資格遵守角色階層。你可以設定審批步驟需要最低角色——例如，只有 Dept Lead 或以上才能在 workflow 輸出投入生產前批准。
執行可見度。 Workflow 執行有 4 種可見度範圍：private（僅執行者）、department（同部門的任何人）、group（指定群組）和 account（所有人）。RBAC 決定誰可以看到執行結果，誰不行。
環境推廣。 不同環境（development、staging、production）可以要求不同的最低角色。Development 可能允許 Member 等級推廣。Production 可能需要 Admin。RBAC 控管每個轉換。
治理報告。 治理儀表板顯示帳戶中的角色分佈、每位使用者可存取的資源計數，以及權限使用情況。Auditor 可以審查這些資料，以確保存取模式符合政策。
可用性
RBAC 在所有方案中都可用。每個 JieGou 帳戶都能取得完整的 6 種角色階層和 26 項權限。部門範圍覆寫和 Auditor 角色在 Team 和 Enterprise 方案中可用。探索所有功能 或 開始免費試用。