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 方案中可用。探索所有功能 或 开始免费试用。