Roles and permissions

Every action a user can take in Strata is gated by their role. This page describes the role model, the granular permissions a role grants, and how to compose custom roles for your team.

The Roles page lives at /admin/roles and requires canManageRoles both to view and to edit. (The nav item is hidden, and the GET /api/admin/roles endpoint returns 403, for admins without it.)

Built-in roles

Two roles are seeded into every new organization and cannot be edited or deleted:

• admin — every administrative permission granted, with one deliberate exception: View member chats (canViewMemberChats) is not granted by default, to prevent blanket surveillance. Orgs that want chat oversight must create a dedicated Compliance role and grant it explicitly. Default database permission is admin. All extensions and every model your organization has enabled are allowed. Description: "Full access to all admin features. Cannot be edited."
• user — no administrative permissions. Default database permission is viewer. Same extension and model list as the admin role. Description: "Standard user. No admin capabilities. Cannot be edited."

Both built-in roles are tagged with a Built-in pill in the Roles table. Their row menu offers only View capabilities (a read-only inspection of the role) — there is no Edit or Delete option. Custom roles get Edit and Delete instead.

Custom roles

To shape access more precisely, click New custom role above the Roles table. The role form is divided into the sections below.

Identity

• Name — required, up to 100 characters. Shown in the Users table and the Role selector. Common patterns: Analyst, Portfolio Manager, Compliance Reader, Contractor.
• Description — optional, helps other admins pick the right role.

Admin panel permissions

A checklist of the granular admin permissions. Checking any sub-permission automatically grants Access admin panel (the canAccessAdmin key) — without it, none of the sub-permissions do anything. Unchecking the last sub-permission automatically revokes admin panel access.

The remaining permissions are Owner-reserved — they carry organization-level control. (There is no separate "Owner" role; "Owner-reserved" is just the escalation-ceiling label. An admin can only grant a permission they themselves already hold, enforced both in the role form, where these checkboxes disable when the acting admin lacks them, and server-side. The built-in admin role is seeded with all of them except canViewMemberChats (see the note on the built-in admin role above); the built-in user role with none.)

Defaults for new users in this role

These apply when a user is first assigned the role and has no user_settings row yet. They do not overwrite existing user preferences.

• Database permission — one of:
  • Viewer — read-only. SELECT queries only.
  • Editor — writes with per-query approval. INSERT/UPDATE/DELETE require an in-chat confirmation.
  • Admin — full database control including DDL (CREATE, DROP, ALTER).
• Rate limit (per hour) — number plus a chats/tokens unit toggle. Leave blank to inherit the org default. See Rate limits and quotas.
• Memory enabled — Strata remembers facts the user shares across conversations.
• Save AI conversations — persist chat history. Required for past chats to work.
• Save extension output — persist SQL results, file contents, email bodies with each conversation.
• Auto-approve database writes — skip the in-chat confirmation prompt before write statements run.

Allowed extensions

The eight extensions are:

• SQL Server — adds Tables, Procedures, Explorer, Schema Map, Database Analytics pages; unlocks run_sql.
• Outlook — email search, read, send; drafts, calendar, tasks, contacts.
• OneDrive — file search, read, save, share, manage folders.
• SharePoint — site and document library access. Requires OneDrive to also be enabled. Disabling it also turns off Knowledge Base search for users in this role.
• Microsoft Teams — create meetings with Teams links, post messages.
• Web search — real-time web search via Brave Search. Lets chats and agents look up current events, prices, documentation, and other live information; disabling removes the search_web tool.
• Jira — search Jira Software issues and Jira Service Management requests; create issues and post internal comments where writes are permitted. Removing it drops search_jira and write_jira for everyone in the role. To keep Jira reads but never write, leave this checked and set the Jira writes capability below to Denied instead.
• Confluence — search spaces and read pages; create pages and post page comments where writes are permitted. Removing it drops search_confluence and write_confluence for everyone in the role. Same pattern as Jira: to keep reads but never write, leave this checked and set Confluence writes below to Denied.

Jira and Confluence are two checkboxes over one Atlassian connection — a role can have either, both, or neither, and members still connect Atlassian once under Settings → Extensions.

Unchecked extensions are hidden from the user's UI entirely (the sidebar, the extensions toggle in chat, the Settings → Extensions page) and the corresponding AI tools become unavailable.

When you save a role change that narrows the allowed extensions, Strata sweeps every user assigned to that role and revokes any OAuth token for an extension that is no longer allowed. The Atlassian token is the exception to the one-token-per-extension shape: unchecking Jira or Confluence withholds that product's tools, and the stored token is dropped only when neither product is allowed to the user.

Allowed AI models

A checklist drawn from the Model Catalog — the central, Kronisys-curated set of AI models served through Microsoft Azure AI Foundry, spanning providers including OpenAI, Anthropic, xAI, DeepSeek, Mistral AI, Cohere, and Microsoft. The checklist shows only the models your organization has enabled, so you pick the role's set from that org-enabled subset. Only checked models appear in the model picker for users in this role.

Use this to cap cost: a "Contractor" role might be restricted to your cheapest small models. To see each model's cost per million tokens, context window, capabilities, and benchmarks before you decide, open the catalog from Organization settings → AI models → Open the catalog.

Note

The available models are whatever your org has enabled in the catalog — not a fixed list. Enabling or disabling a model org-wide is the live source of truth; this role checklist can only narrow within it. See Organization settings.

Capabilities

Fine-grained features the role grants. All three are tri-states, but they resolve differently — the two write controls narrow and never grant.

• Analysis — lets the AI run code in an isolated sandbox (data analysis, charts, file transforms) during chats. Its options read Inherit org default, Allowed, and Denied. Inherit follows the org-wide setting; the same control can be set per user in the Users page, where the most specific level wins.
• Jira writes — lets the AI create Jira issues and post comments on this role's behalf. Its options read Inherit org setting, Allowed (if the org allows), and Denied.
• Confluence writes — lets the AI create Confluence pages and post page comments on this role's behalf. Same three options, resolved the same way, and independent of Jira writes: denying one leaves the other untouched.

Jira writes and Confluence writes do not follow the "most specific level wins" pattern Analysis uses. Each can only narrow its product's organization toggle — Let Strata create issues and comment for Jira, Let Strata create and edit pages for Confluence — both set on the Atlassian extension page (Settings → Extensions → Atlassian → Manage, described in Organization settings):

• Allowed grants nothing. It means "this role does not narrow". If the organization has that product's writes off, every role set to Allowed still cannot write — hence the label.
• Denied is the only value that changes anything: nobody in this role writes to that product, even though the organization allows it.
• Inherit org setting behaves exactly like Allowed.

The same two tri-states exist per member under Admin → Users → (manage user) → Extensions & Data, and a Denied at either layer is enough to stop the write. If the organization has turned on Apply to everyone, with no exceptions for that product on the Atlassian extension page, the role control stops applying entirely. Denying a role also stops the agents owned by its members from writing, and on the Jira side it narrows Jira Service Management comments along with ordinary writes. Changes bite on the next request. See Atlassian extensions.

Model governance

The models a user can actually pick are the intersection of three layers, enforced everywhere the AI runs — chat, scheduled agents, the Teams bot, voice mode, and the /v1 API:

1. Organization — the models your org has enabled in the Model Catalog (Organization settings). This is always authoritative; a disabled model is unavailable to everyone.
2. Role — the Allowed AI models checklist above narrows the org set for everyone in the role.
3. Per-user — from Admin → Users → (manage a user) → Extensions & Data → AI models, you can restrict a single person below their role's set. Leaving every box checked (or unchecking all of them) means inherit — the user gets every model the org and role allow. Unchecking a subset caps that one user without touching their role.

If a user (or an API client) requests a model that isn't in the effective intersection, Strata silently snaps the request to the first allowed model instead of failing.

Note

There is no longer a separate "allowed-models lock" toggle. The enabled-models list is authoritative on its own; you no longer have to lock it to make it stick.

Database permission tiers

The three SQL permission tiers (viewer, editor, admin) are the database side of role permissions. They control what run_sql is allowed to execute against any connection where the user has access:

• Viewer — SELECT only. INSERT/UPDATE/DELETE/DDL are blocked at the run_sql tool layer.
• Editor — same as Viewer, plus INSERT/UPDATE/DELETE allowed, but each write requires the user to confirm an in-chat approval card before it runs. Toggle Auto-approve database writes to skip the prompt.
• Admin — same as Editor, plus DDL (CREATE, DROP, ALTER, etc.) is allowed.

The tier can be set in three places, with the more specific level winning:

1. Per-connection access in the Users page → user modal → Profile & Access (most specific).
2. Role default in the Roles page (above).
3. Organization default in Organization settings → Defaults.

Agent governance

Scheduled agents are governed at three layers that compose together:

1. Role permission — the Create + edit scheduled agents (canCreateAgents) checkbox above. When off, users in the role can view agents but cannot build, edit, run, or pause them.
2. Org-wide controls — the Agents lock in Organization settings is a kill-switch for the whole org, and the Agents sub-tab there publishes reusable org agent templates that every member can deploy in one click.
3. Per-user controls — from Admin → Users → (a user) → Agents, you can lock agent creation for one person and mask which extensions that user's agents may call at runtime, without changing their role. See Per-user agent governance.

A user's effective agent capability is the intersection of all three: the role grants the base permission, the org lock can override it for everyone at once, and the per-user mask narrows a single individual further.

The Allowed extensions checklist above applies to agent runs as well as chat, so it is also the lever for deciding which members' agents may reach a system at all. Unchecking Jira (or Confluence) for a role means no agent owned by anyone in that role can search or write to that product, whatever capabilities the agent itself was given. That matters most for writes: an agent run has nobody to show an approval prompt to, so a scheduled agent holding write_jira or write_confluence creates issues, pages, and comments without asking. An agent's write permission is resolved for its owner, so setting the Jira writes or Confluence writes capability to Denied stops the agents owned by everyone in the role while leaving their reads intact. See Atlassian extensions.

Assigning a role to a user

1. Open /admin/users.
2. Click Manage on the user's row.
3. Pick a role from the Role dropdown in the Profile & Access tab.
4. Save.

The change appears in the audit log as user.role_assigned. Session permissions rehydrate within roughly 30 seconds. To force the change to take effect immediately, use Force sign out (all devices) in the same modal.

Deleting a custom role

From the row menu in the Roles table, pick Delete. The dialog warns that users currently assigned to this role must be reassigned first; the request returns Cannot delete role — N user(s) still assigned. Reassign them first. if any users remain.

Built-in roles cannot be deleted.

Best practices

• Least privilege. Default new users to a role with the minimum capability they need; promote individuals as their responsibilities grow.
• Lean on locks instead of removing permissions. If you want every analyst to have memory off, set Memory enabled off on the Analyst role AND turn on the Memory toggle lock in Organization settings so users cannot re-enable it.
• Pair canViewAudit with canExportAudit for compliance reviewers; both keys are needed to satisfy external auditors who want a downloadable record.
• Use a "User manager" role with canManageUsers + canInviteUsers (no canManageOrgSettings) to let HR onboard people without touching engine configuration.

What can go wrong

Related

• Users
• Organization settings
• Per-user agent governance
• Atlassian extensions
• Audit log