Roles and permissions
The full access map — which role is required to use each Scrydon product, what every role can do to each resource, how programmatic (API) access works, and how data clearance forms a second axis on top of roles.
This page is the complete access map: who can use which product, what each role can do to each resource, how programmatic (API) access is scoped, and how data clearance layers on top. For the mechanics of how a decision resolves, see Permission model; this page is the what.
The three access axes
Scrydon separates access into three independent axes. A request is allowed only when all three that apply to it agree.
| Axis | Answers | Who it applies to | Where it's set |
|---|---|---|---|
| Identity & roles | Can this person reach this resource at all? | Every human user | Organisation & workspace membership |
| Capability scopes | What may this program do through the API? | Mini-apps & service accounts | OAuth scopes at registration |
| Data clearance | Which classified items inside a resource may this user see? | Every human user | Clearance level + classification |
Roles and clearance are orthogonal. A workspace admin with broad workspace access still cannot read a document classified above their clearance. Conversely, a highly-cleared member still cannot touch a workspace they aren't a member of. Access is the intersection, never the union.
Roles at a glance
Scrydon has three role tiers. They never cross-check against each other — a workspace admin is not an organisation admin.
Platform (deployment operator)
| Role | Responsibility |
|---|---|
| Super admin | The global operator of a Scrydon deployment — the first user created at setup plus anyone in SUPER_ADMIN_EMAILS or promoted under Settings → Super admin. Automatically treated as an organisation admin of every organisation. Only a super admin can create or delete organisations. |
Super admin is a deployment-wide privileged role, not an organisation role. In a single-tenant self-hosted install the super admin is the operator. Every automatic grant or elevation is written to the audit log, and it is applied at sign-in — a newly promoted super admin must sign out and back in. See Platform admins and impersonation.
Organisation
There are exactly two organisation-membership roles — there is no separate "owner" tier.
| Role | Responsibility |
|---|---|
| Admin | Full organisation control: manage members, teams, and workspaces; configure integrations and entitlements; install and retire packs; edit organisation settings; billing; governance (DLP, clearance, cost insights). Holds implicit read access to every non-personal workspace in the org for oversight — your personal workspace is excluded, even from org admins. |
| Member | No organisation-level powers. Gains access to work only through direct workspace membership or a team grant. Since access is explicit, a plain member with no workspace membership can sign in but sees nothing. |
Workspace
See Workspaces for the difference between a shared
workspace and your personal workspace — the roles below apply to shared
workspaces; your personal workspace has fixed owner-only settings.
| Role | Responsibility |
|---|---|
| Owner | Full control of the workspace: rename, delete, transfer, configure integrations, manage members, and the highest settings tier. Assigned automatically to the workspace creator. |
| Admin | Manage workspace settings, members, knowledge bases, and integrations. Everything an owner can do except transfer and the owner-only settings tier. |
| Member | Do the work: create and run workflows, use Chat, author knowledge, read resources (subject to clearance). Cannot manage members or delete the workspace. |
Workspace roles are granted directly or through a team. If a user inherits different roles from multiple teams on the same workspace, the highest wins (owner > admin > member). Teams are the handle for IdP / SCIM group provisioning — see Permission model → Team-based grants. A read-only viewer tier exists in the model but is not currently assignable through the invite or add-member flows.
Product access map
Every product requires an authenticated user who is a member of the organisation. Beyond that, access is gated as follows.
| Product | What it is | Who can use it | Who administers it |
|---|---|---|---|
| Chat (Cortex) | The workspace AI assistant — conversations, knowledge, building automations by chat | Any workspace member. Each member accepts a one-time AI-usage consent on first use. | Org admins get topic & conversation oversight views. |
| Workflows & Process flows (Automations) | Build and run agentic workflows and human-in-the-loop process flows | Any workspace member creates and runs their own; workspace admins/owners manage shared settings | Workspace admin / owner for workspace-level settings & integrations |
| Copilot | The AI builder assistant inside the workflow editor | Any workspace member | — |
| Analytics | Governed tables, notebooks, and the ontology graph | Any workspace member; which rows/columns you see is governed by table classification & masking (higher-classified tables restrict to admins/owners) | Workspace admin / owner; requires object storage provisioned for the org |
| Ontology | The semantic layer — object/link/action types and instances | Read: any org member. Instance reads are clearance-filtered. | Types authored by org admins, workspace admins/owners, or the ontology-author role (proposals only) |
| Knowledge bases | RAG / Memex knowledge bases and their documents | Read: workspace members, per document clearance | Knowledge-base owner or workspace admin / owner |
| Marketplace & Packs | Install content packs (ontologies, workflows, integrations, knowledge) | Browse: any org member | Install / retire packs and manage pack sources: org admin |
| Integrations & Connections | Connect vendor accounts and enable capabilities (LLM, STT, storage, tools…) | Use enabled integrations: workspace members (subject to entitlement) | Enable integrations & manage entitlements: org admin |
| Horizon (Common Operating Picture) | Live situational-awareness view over governed operations | Any workspace member — but only when the deployment flag is on. Data is clearance-filtered per viewer. | Enabled per deployment via the HORIZON_ENABLED flag (off by default) |
| Settings (Platform) | Account, organisation, and governance control plane | Account settings: any member | Organisation settings, members, teams, workspaces, billing, and governance (DLP, clearance, cost): org admin. Deployment operation: super admin. |
Horizon is off by default. It only appears when an operator sets HORIZON_ENABLED=true for the deployment. The underlying engine features it composes (governed map reads, operational events) are always available to packs; only the Horizon console is flag-gated.
Resource permission matrix
Below is what each role can do to each kind of resource. Unless noted, an organisation admin can do everything a workspace role can, across all non-personal workspaces (oversight). Access is deny-by-default: anything not granted here is denied.
Workspace content
Workflows, chats, folders, schedules, memories, webhooks, process flows, execution logs, files, and managed tables.
| Action | Who can |
|---|---|
| View / run | Any workspace member (owner, admin, member) |
| Create & edit | The item's creator/owner, plus workspace admin / owner |
| Delete | The item's creator/owner, plus workspace admin / owner |
Files also allow read by any organisation member when shared at organisation scope; organisation-scope writes require an org admin.
Knowledge bases & documents
| Action | Who can |
|---|---|
| Read a knowledge base | Any workspace member (including read-only members); any org member for org-scoped bases |
| Create / edit / delete a knowledge base | The knowledge-base owner, or workspace admin / owner; org admin for org-scoped bases |
| Read a document | Requires knowledge-base read access and clearance ≥ the document's classification and, if the document is restricted, an explicit per-document grant |
| Edit a document | Requires knowledge-base write access and clearance ≥ the document's classification (no writing down) |
Documents enforce three layers at once: role (are you a member of the knowledge base?), need-to-know (do you hold a grant for a restricted document?), and clearance (is your level high enough?). See the Data clearance section below.
Ontology (semantic layer)
| Resource | Read | Create / edit | Notes |
|---|---|---|---|
| Types (object / link / action) | Any org member | Org admin; workspace admin/owner (own workspace); the ontology-author role on proposal branches | Pack-installed types are read-only for everyone except the system |
| Instances (objects / links) | Org members, filtered by clearance; sensitive fields may be redacted | Org admin; workspace admin/owner | Cross-organisation access is always denied |
| Branches | Any org member | Propose: any org member. Publish: org/workspace admin, or the ontology-approver role | An approver cannot publish their own proposal (separation of duties); the main branch is immutable to non-system actors |
Templates & packs
| Resource | Read | Manage |
|---|---|---|
| Templates (workflow / process) | Any org member | Org admin only |
| Pack catalogue | Any org member | Install / edit / retire: org admin only |
| Pack sources (customer-managed feeds) | — | Org admin only |
Settings & administration
| Surface | Read | Write | Highest tier |
|---|---|---|---|
| Workspace settings | Any workspace member | Workspace admin / owner | Workspace-owner-only actions (e.g. transfer) |
| Organisation settings | Any org member | Org admin | Org-admin-only |
| Organisation admin operations | — | — | Execute: org admin only |
| Integration entitlements | — | Org admin only | — |
| Using an integration | Governed by the workspace's entitlement (org-wide / granted / denied), not by role — an org admin decides which workspaces may use each integration |
A concrete example of the workspace-settings rule: recording your own Chat AI-usage consent is a personal action, so every member can do it. Managing the workspace's settings is a write, so it requires a workspace admin or owner.
Programmatic access (API scopes)
Human roles govern the product UI. Programs — mini-apps and service accounts — authenticate with OAuth and carry capability scopes instead. This is a completely separate axis from org administration: a service account with workflows:write can trigger workflows but cannot invite an organisation member.
Who holds scopes
| Principal | Grant type | How scopes are granted |
|---|---|---|
| Mini-apps | OAuth authorization_code | An org admin selects the allowed scopes at registration. A user's token carries only the intersection of what they consented to and what the app is allowed. |
| Service accounts | OAuth client_credentials | An org admin creates the account (org-admin only) and selects its scopes. It exchanges a client id + secret for a short-lived (15-minute) token. |
Capability scopes
Scopes are resource:action, where action is read or write. A write scope satisfies the matching read on the same resource; scopes never cross resources.
| Resource | Governs | API surface today |
|---|---|---|
workflows | Workflow definitions, canvas state, deploy, trigger, execution results, blocks & model catalogues | Active — the /api/v1/workflows/*, /blocks, /models routes |
knowledge | Knowledge bases, documents, ingestion, semantic search, the ontology geo layer | Active — the /api/v1/knowledge/* and /ontology/geo routes |
storage | Mini-app-scoped file upload and presigned download | Active — the /api/v1/storage/* routes |
tools | The governed integration tool bridge — discover and execute org-enabled integration tools | Active — the /api/v1/tools/* routes |
logs | Read workflow execution logs and canvas snapshots | Active (read) — the /api/v1/logs/* routes |
capabilities | Direct AI capability execution — LLM, embeddings, speech-to-text, OCR, text-to-speech, image, video — through one governed edge | Active — the /api/v1/capabilities/execute route (gated by capabilities:write) |
chat, templates, tables | Reserved for future API surfaces | Reserved vocabulary — not yet exercised by a public route |
Which AI capabilities an organisation may actually run (which LLM, whether OCR is enabled, billing, DLP) is decided by the integration registry and enforced server-side per call — never by the OAuth scope. capabilities:write is a single stable gate; adding a new AI capability never adds a new scope. This is what keeps the programmatic surface small and auditable.
Data clearance (the second axis)
Roles answer can you reach the resource. Clearance answers which classified items inside it you may see. It is a mandatory control — it cannot be waived by a role.
The clearance ladder
Documents and records are ranked on a five-level ladder:
| Level | Rank | Meaning |
|---|---|---|
| Unclassified | 0 | Unrestricted access |
| Restricted | 1 | Org staff only |
| Confidential | 2 | Need-to-know |
| Secret | 3 | Tightly controlled |
| Top Secret | 4 | Strictly compartmented |
The labels shown in the UI depend on your organisation's active classification scheme — the commercial default (Public / Internal / Confidential / Restricted), NATO, or EU. The ranks compare the same way underneath. See Knowledge base clearance for scheme selection.
How clearance is decided
| Source | Result |
|---|---|
| Organisation member (default) | Up to Restricted |
| Organisation admin (default) | Up to Confidential |
Per-user grant (user_clearance) | Secret / Top Secret — set from an IdP claim, or via a four-eyes admin override (two-admin approval, time-boxed) |
Clearance is not a free-form per-user flag an admin can toggle. By default it tracks the organisation role; elevation above Confidential goes through the audited user_clearance process. To give someone broad higher-clearance access, promote them — don't hand out a flag.
The enforcement rules
A user cannot read an item whose classification rank is above their clearance rank — regardless of workspace role. Search and retrieval apply this as an invisible filter, so over-classified items never even appear in results or counts.
Writes always require clearance ≥ the item's classification, so a cleared user cannot copy sensitive content into a lower-classified place.
A document may additionally be restricted, requiring an explicit per-document grant on top of clearance and knowledge-base membership.
Ontology records tagged with data-protection labels (e.g. PII / PHI) are returned with those fields redacted unless the caller holds the matching capability. Org admins hold them implicitly.
Enforcement modes
An organisation chooses how strictly clearance is enforced. Spillage detection is always active regardless of mode.
| Mode | Behaviour |
|---|---|
| Disabled | No enforcement; requires a time-boxed, referenced exception that auto-reverts |
| Test with notifications | Log only; notify admins; nothing blocked |
| Audit | Log violations and allow access; emit high-severity audit events (the default for a new activation) |
| Enforce | Block inline; retrieval filters silently with no count disclosure |
How a decision is made
Authenticate the session (or the OAuth token for a program). No session → denied.
Org admin? → oversight access. Else direct or team workspace role. No role → denied. (See Permission model.)
A central policy engine (OPA) decides the specific action against the specific resource using the rules above. It is fail-closed: if the engine is unreachable, the decision defaults to deny.
For classified data, apply the clearance rules. For API calls, check the capability scope. Every grant and denial is written to the audit log.
Related
- Permission model — the three-tier resolution hierarchy behind this map.
- Authorization — the policy decision point that enforces it.
- Platform admins and impersonation — super admin vs organisation admin.
- Knowledge base clearance — classification schemes and how clearance is set.
- DLP — data-loss prevention and redaction.
- Audit logging — every permission grant and revoke is recorded.