Permission model
The three-tier hierarchy Scrydon uses to resolve who can do what — organisation roles, direct workspace membership, and team-based grants.
Every authorisation decision in Scrydon resolves through a three-tier hierarchy. This page explains the hierarchy and the role table that backs it.
Resolution order
If yes → full access to all workspaces in the organisation. Bypass workspace-level checks.
If yes → use the actor's workspace-scoped role (member, admin, owner).
If yes → take the highest role granted across all team memberships that apply to this workspace.
→ Access denied. No implicit grants. No fallback.
This same hierarchy is used by the client (useHasPermission() in the UI) and by the server (hasPermission() in API routes). Inline role checks are forbidden — every permission decision goes through this hierarchy.
Org-level roles
| Role | What they can do |
|---|---|
| Admin | Full org-level access. Manage workspaces, members, teams, integrations, billing. (Top org-membership role — there is no separate "Owner" tier.) |
| Member | No org-level powers. Can be granted workspace access via direct membership or team grants. |
Platform super admins
A platform super admin is the global operator of a Scrydon deployment — the first user created during setup, plus anyone listed in SUPER_ADMIN_EMAILS or promoted from Settings → Super admin. This is a platform-level role, distinct from the organisation roles above.
Platform super admins are automatically treated as an organisation admin of every organisation. On sign-in, a super admin is granted (or, if already a plain member, elevated to) an admin membership of the organisation they operate on, so the admin areas under Settings → Organization — members, teams, workspaces, integrations, the org chart — load and are editable without anyone manually adding them to each organisation.
This is a deliberate operator-model grant. In a single-tenant self-hosted install the super admin is the operator; if you run multiple organisations on one deployment, treat super admin as a deployment-wide privileged role. The automatic grant or elevation is recorded in the audit log. Organisation deletion is a super-admin operator action — the customer-facing delete UI was removed; deletion lives under Settings → Super admin → Danger zone, performed by an operator with the super_admin platform role. The grant is applied at sign-in, so a newly promoted super admin must sign out and back in to pick it up.
Workspace-level roles
| Role | What they can do |
|---|---|
| Owner | Full control of the workspace. Delete, transfer, configure integrations. |
| Admin | Manage workspace settings, members, knowledge bases, integrations. |
| Member | Use workflows, run agents, read knowledge bases according to clearance. |
Team-based grants
Teams aggregate users across the organisation. A team can be granted a role on a workspace, and every team member inherits that role for that workspace. A user can be in multiple teams; if two teams grant different roles on the same workspace, the highest role wins.
Teams are the primary handle for SCIM provisioning — assigning a group to the Scrydon app in your IdP creates / updates a matching team. See Identity & Provisioning.
Document clearance (separate axis)
The permission hierarchy answers who can access this resource. Document clearance is a separate axis that answers which knowledge-base documents this user is allowed to see at all. Clearance is derived from the user's organisation role:
| Org role | Max clearance | Can read |
|---|---|---|
| Member | RESTRICTED | UNCLASSIFIED, RESTRICTED |
| Admin | CONFIDENTIAL | + CONFIDENTIAL |
A workspace member who has full workspace access still cannot see CONFIDENTIAL knowledge-base documents unless they're an org admin. TOP SECRET access is granted per-user via the user_clearance table (IdP claim or four-eyes admin override) — not derived from an org role tier. See Knowledge base clearance for the full model.
Clearance is not configurable per user. It tracks the organisation role. Granting someone access to higher-clearance documents requires promoting them, not granting a clearance flag.
Why it's structured this way
- One hierarchy, used everywhere. UI checks, server checks, audit log filters, and Rego policies all consult the same model. No drift between the surface and the backend.
- Team-based scaling. Direct-membership grants don't scale to thousands of users; team grants do, and they survive IdP-driven user lifecycle changes.
- Audit-friendly. Every grant has a recorded source — direct, team, or org-level — so the audit log can answer "how did this user get access" without ambiguity.
Related
- Authorization — the policy decision point that consumes this model.
- Identity & Provisioning — SCIM group → team mapping.
- Knowledge base clearance — the document-level clearance axis.
- Audit logging — every permission grant and revoke is logged.