Roles & permissions

RebelCore™ uses a boolean permission model: every role is a named bundle of yes/no flags, and the app checks those flags both in the UI (to hide buttons and pages) and in the backend (to reject unauthorised requests). There are no inherited tiers, no wildcards, and no opaque “admin” levels — what a role can do is exactly the set of flags it has on.

Where roles live

Roles belong to a customer. A customer can have any number of custom roles, and there are also three system roles that ship with the platform and apply to every customer:

• RebelCore_SuperUser — every flag enabled. The default role for new admins.
• RebelCore_User — a sensible read-mostly default. Can view datasets, create projects, view the tree, and use the agent.
• RebelCore_AgentUser — agent-only access. Just the can_access_agent flag; no portal permissions. Users on this role sign in at www.rebelcore.ai/login and land directly on RebelCore™ Agent with no “back to RebelCore™” affordance.

System roles are read-only: they show up with a System badge in the role list, can’t be edited, and can’t be deleted. You can clone the behaviour by creating a custom role that mirrors the flags you want.

A user is assigned exactly one role. When the role’s flags change, the next call to /auth/core/me re-evaluates the user’s permissions, so changes take effect on the next page load — there’s no need to sign the user out and back in.

The Customer Super Admin bypass

The Customer Super Admin is the customer’s “owner” account — created when the customer is provisioned in CAS. They sit outside the role system entirely:

• They appear in the Users list with an OWNER badge and no Edit/Delete actions.
• They bypass every permission check. All flags are evaluated as true for them, both in the UI and in the backend.
• They can manage users and roles for their customer regardless of which flags they technically have.

This is intentional: someone always has to be able to climb out of a misconfigured role state. That someone is the Customer Super Admin.

The permission flags

Permissions are organised into five groups in the role editor. Each flag controls a specific surface — there’s no overloading.

Datasets & Modules

Flag	What it gates
View Datasets	The Datasets sidebar item, the dataset list page, and GET /api/v1/customers/{id}/import-batches. Without this, the user can’t see the page at all.
Add Datasets	The floating + button on the Datasets page (creating a new import batch and uploading the raw file).
Add Module	The inline CREATE MODULE action on each dataset row, plus the BUILD MODULE button in the Module Dataset Builder. Also gates finalize, run-import, labels, and settings endpoints.

Projects

Flag	What it gates
Add Projects	The + Create Project floating button on the Projects page and POST /api/v1/projects.
View Tree	Whether the user can open and navigate the project tree view.

Semantic Datasets

Flag	What it gates
Create Semantic Dataset	The Build Semantic Dataset button in the project tree’s Data tab and POST /api/v1/projects/{id}/semantic/build.
Delete Semantic Dataset	The hover-only X on each semantic dataset card and DELETE /api/v1/projects/{id}/semantic/specs/{specId}.

Agent

Flag	What it gates
Access Agent	Loading the RebelCore™ Agent UI at all, plus the RebelCore™ Agent launcher buttons in the project tree and POST /api/v1/inference. A user without this flag who navigates directly to agent.rebelcore.ai sees an Access denied screen with a Log out button.

Administration

Flag	What it gates
Add Users	The Users sidebar item, the Users page, and the user create/edit/delete/regenerate-password endpoints.
Add Roles	The Roles sidebar item, the Roles page, and the role create/edit/delete endpoints.

Implied permissions

Some flags require others to make any sense, and the system enforces that automatically:

• Add Datasets requires View Datasets.
• Add Module requires View Datasets and Add Datasets.

In the role editor:

• The dependent checkbox is disabled until its prerequisite is enabled, and shows a small italic Requires … hint.
• Ticking a child auto-ticks its parents, and unticking a parent auto-unticks its children.

The same rules apply on the backend on every role write — even a hand-crafted API call that tries to set can_add_module=true with can_view_datasets=false is normalised to the consistent state on disk.

The other groups are independent — Create and Delete Semantic Dataset, for example, are not tied to any other flag, so you can grant Delete without Create if that suits your workflow.

Defense in depth

Every UI gate has a matching backend gate. Even if a user crafted a request directly:

• The endpoint dependency rejects it with 403 permission denied if the flag is missing.
• The Customer Super Admin bypass and the role lookup both run on the server using the session cookie, so the client can’t claim to have permissions it doesn’t have.

This means hiding a button is a usability choice, not a security boundary — the security boundary is the API.

Deleting a role

Each non-system row has a Delete action. What happens next depends on whether anyone currently has that role assigned:

No users on the role

You see a small confirmation dialog with a type yes to confirm input. Once you type yes and click the confirm button, the role is gone — the call hits DELETE /api/v1/core/roles/{id} and the row disappears from the list.

One or more users on the role

A user has exactly one role, so the role can’t simply be removed. The dialog expands with:

• A line stating how many users are currently on the role.
• A Move users to dropdown listing every other active role (system roles are valid targets — they’re often the natural fallback). Inactive roles and the role being deleted are excluded.
• The type yes to confirm input.
• A confirm button labelled e.g. “Move 3 users to RebelCore_User & delete ”.

Confirming sends a single atomic call to POST /api/v1/core/roles/{id}/reassign-and-delete with the chosen target. The server moves every assignment over to the target role and deletes the source role in one transaction — either both happen or neither does.

When deletion is blocked

If, after filtering out the role being deleted and inactive roles, there are no eligible target roles (rare, since at least one system role usually qualifies), the dialog shows an amber notice and only a Cancel button. Create another active role first and try again.

What gets recorded

Every successful delete is written to the Activity audit trail:

• role.delete for an unassigned-role removal.
• role.reassign_and_delete for the migrate-then-delete path, with metadata recording the source role, target role, and the number of users moved.

What’s not in this model

A few things deliberately sit outside the per-customer role system:

• CAS (the global admin app) uses a separate system_type='CAS' account class. Users created via the rebelcore UI are always created with system_type='REBELCORE' and cannot sign in to CAS.
• Audit views are visible only to the Customer Super Admin — the audit panel is an inherent super-admin surface and isn’t toggleable per role.
• Cross-customer access is not supported; a Customer Super Admin can only manage users and roles within their own customer.

Where to go next

• Managing users — creating, editing, and resetting passwords.
• Audit — drill into any user’s sessions and the MCP call tree.
• Governance & access — the conceptual model behind these flags.