AI automation platforms handle sensitive data and critical workflows. Customer records flow through recipe steps. Financial reports get generated and distributed. Internal communications are drafted and sent. The access control model needs to match the stakes.
“Admin or User” doesn’t cut it. You need a compliance officer who can read audit logs but can’t execute anything. You need department leads who manage their team’s automations but can’t touch other departments. You need clear boundaries that map to your org chart, not a flat binary toggle.
This post covers JieGou’s RBAC system: the 6-role hierarchy, 26 granular permissions, department-scoped overrides, and the enforcement mechanism that runs on every API call.
The 6-role hierarchy
Every user in JieGou has a global role — a single numeric level that determines their baseline permissions across the entire account.
| Role | Level | Purpose |
|---|---|---|
| Owner | 50 | Account creator. Full access including account deletion. |
| Admin | 40 | Full management: billing, users, API keys, cross-department analytics. |
| Dept Lead | 30 | Department leader. Edit/delete any content in their departments. Install packs. Promote workflows. |
| Member | 20 | Standard user. Create content, edit own, run recipes/workflows, manage schedules. |
| Auditor | 15 | Read-only access to audit logs, analytics, governance. Cannot create or execute. |
| Viewer | 10 | Read-only access to content. Cannot execute anything. |
The numeric levels aren’t arbitrary. They enable O(1) permission checks — instead of iterating through role lists, the system compares two integers. A permission requires a minimum level, and the user either meets it or doesn’t.
The Auditor role
Auditor is the newest addition, designed specifically for compliance. It sits between Viewer (10) and Member (20) at level 15.
The key difference from Viewer: Auditors get the audit:read permission. They can access audit logs, analytics dashboards, and governance reports. Viewers cannot.
The key difference from Member: Auditors cannot create content, execute recipes, run workflows, or manage schedules. They observe and report. Nothing else.
This matters for regulated industries. Your compliance officer needs to verify that workflows follow policy, that data handling meets requirements, and that user activity aligns with your governance framework. They should not need — and should not have — the ability to modify or execute anything.
Auditors are available in SSO group-to-role mapping, so you can auto-provision compliance officers from your IdP. Map your compliance-team or internal-audit group to the Auditor role, and new hires in those groups get the right access on their first login. No manual role assignment required.
26 permissions across 8 categories
Roles are shorthand. Permissions are what actually get checked. JieGou defines 26 granular permissions organized into 8 categories:
Account (4 permissions)
| Permission | Min Role | Description |
|---|---|---|
account:delete | Owner | Delete the entire account |
account:admin | Admin | Administrative actions (SSO config, account settings) |
account:settings | Admin | Manage account-level settings |
account:billing | Admin | Manage billing and subscription |
Users (2 permissions)
| Permission | Min Role | Description |
|---|---|---|
users:manage | Admin | Manage all users across the account |
users:manage-department | Dept Lead | Manage users within own department(s) |
Content (6 permissions)
| Permission | Min Role | Description |
|---|---|---|
content:create | Member | Create new recipes, workflows, documents |
content:edit-own | Member | Edit content you created |
content:edit | Dept Lead | Edit content in your department |
content:edit-any | Admin | Edit any content across all departments |
content:delete-any | Admin | Delete any content across all departments |
content:read | Viewer | Read content (recipes, workflows, documents) |
Execution (3 permissions)
| Permission | Min Role | Description |
|---|---|---|
execution:run | Member | Run recipes and workflows |
execution:schedules | Member | Create and manage scheduled runs |
execution:triggers | Member | Configure event-driven triggers |
Analytics (2 permissions)
| Permission | Min Role | Description |
|---|---|---|
analytics:read-department | Auditor | Read analytics for own department(s) |
analytics:read-all | Admin | Read analytics across all departments |
Features (4 permissions)
| Permission | Min Role | Description |
|---|---|---|
features:chat | Member | Use the AI chat interface |
features:documents | Member | Manage knowledge base documents |
features:packs | Dept Lead | Install and manage department packs |
features:connectors | Admin | Configure MCP connectors and integrations |
Governance (3 permissions)
| Permission | Min Role | Description |
|---|---|---|
governance:audit | Auditor | Read audit logs and governance reports |
governance:environments | Dept Lead | Manage deployment environments |
governance:promote | Dept Lead | Promote workflows between environments |
Security (2 permissions)
| Permission | Min Role | Description |
|---|---|---|
security:byok | Admin | Manage Bring Your Own Key API keys |
security:embedded-api | Admin | Configure the embedded API |
The mapping from role to permissions is static. A Dept Lead (level 30) automatically has every permission with a minimum role of 30 or below. No per-user permission overrides, no custom role definitions. This keeps the model auditable — you can look at a user’s role and know exactly what they can and cannot do.
Department-scoped role overrides
A global role applies everywhere. But organizations aren’t flat. A product manager might need Member access globally but Dept Lead access in the Product department to manage their team’s automations.
Department-scoped overrides solve this. A user has one global role, plus zero or more department-specific role overrides.
Example: Sarah is a Member globally. She has a Dept Lead override in the Sales department. In Sales, she can edit any content, install packs, and promote workflows. In Engineering, she’s a standard Member — she can only edit her own content.
The critical design principle: overrides can only elevate, never reduce. If you’re a global Admin with a Viewer override in Engineering, your effective role in Engineering is still Admin. The override is ignored because it would reduce access. This prevents a misconfigured override from accidentally locking someone out of a department they should have access to.
Effective role resolution
When the system needs to determine what a user can do in a specific department, it runs this resolution:
- Check if a department override exists for this user in this department
- If an override exists, return the higher of the global role and the override
- If no override exists, return the global role
In pseudocode:
effectiveRole(user, department):
override = getDepartmentOverride(user, department)
if override exists:
return max(user.globalRole, override.role)
return user.globalRoleDepartment-scoped permission checks use this effective role. When Sarah tries to install a pack in Sales, the system resolves her effective role in Sales (Dept Lead, level 30), checks the minimum level for features:packs (30), and grants access. When she tries the same in Engineering, her effective role is Member (20), which falls below the required level.
Anti-escalation rules
Role changes are the most security-sensitive operation in the system. Four rules prevent privilege escalation:
-
You cannot change your own role. No self-promotion. An admin who wants to become owner needs another owner to make the change.
-
You cannot assign the Owner role. Owner transfer is a separate, deliberate operation with its own safeguards. It doesn’t happen through the standard role-change API.
-
You cannot assign a role greater than or equal to your own (unless you’re the Owner). An Admin (40) can assign Dept Lead (30), Member (20), Auditor (15), or Viewer (10). They cannot assign Admin (40) or Owner (50). Only the Owner can create other Admins.
-
You cannot change the role of someone with a role greater than or equal to yours (unless you’re the Owner). An Admin cannot modify another Admin’s role. A Dept Lead cannot modify an Admin’s role. The hierarchy is strictly enforced upward.
These rules compose cleanly. Combined, they guarantee that no user can escalate their own privileges or the privileges of their peers — only the Owner sits outside this constraint.
How permissions are enforced
Every API route in JieGou runs through a three-step auth guard before executing any business logic:
Step 1: Verify session cookie. The session token from the HTTP cookie is validated against Firebase Auth. The result is cached in Redis with a 5-minute TTL, so repeated requests from the same session don’t hit Firebase Auth on every call.
Step 2: Look up AccountUser record. The user’s account membership — including their global role and department overrides — is fetched from Firestore. This is also cached in Redis with a 5-minute TTL.
Step 3: Check permission against role hierarchy. The required permission is mapped to its minimum role level. The user’s effective role (accounting for department overrides if the check is department-scoped) is compared against it. This is O(1) — a single hash lookup to find the minimum level, plus a numeric comparison.
No database queries at permission-check time. No iterating through permission lists. Two cached lookups and one integer comparison.
Resource-level checks
Beyond role-based permissions, individual resources (recipes, workflows, documents) have ownership-based access rules:
- Owner, Admin, Dept Lead — can modify any resource in their scope
- Member — can modify only resources they created
- Auditor, Viewer — cannot modify any resource
This combines with role-level permissions. A Member with content:edit-own can only edit resources where resource.createdBy === user.id. A Dept Lead with content:edit can edit any resource in their department regardless of who created it.
Integration with platform features
RBAC isn’t isolated — it connects to every major platform subsystem:
Approval gates. Approval eligibility respects the role hierarchy. You can configure an approval step to require a minimum role — for example, only Dept Lead or above can approve workflow outputs before they go to production.
Run visibility. Workflow runs have 4 visibility scopes: private (only the runner), department (anyone in the same department), group (specified groups), and account (everyone). RBAC determines who can see run results and who can’t.
Environment promotion. Different environments (development, staging, production) can require different minimum roles. Development might allow Member-level promotion. Production might require Admin. RBAC gates each transition.
Governance reporting. The governance dashboard shows role distribution across the account, per-user accessible resource counts, and permission utilization. Auditors can review this data to ensure access patterns match policy.
Availability
RBAC is available on all plans. Every JieGou account gets the full 6-role hierarchy and 26 permissions. Department-scoped overrides and the Auditor role are available on Team and Enterprise plans. Explore all features or start a free trial.