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. Every extension except Microsoft Teams, and every model your organization has enabled, is 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.

Both built-in roles leave Microsoft Teams out on purpose, so Teams stays opt-in. Because a built-in role can't be edited, give members Teams with a custom role that lists it, either as their own role or bound to one of their groups (see Binding a role to a group).

Custom roles

To shape access more precisely, click New custom role above the Roles table. The role form has four tabs: Overview (name, description and a summary of the role), Admin panel, Access (extensions and AI models) and Member defaults (starting values, rules and capabilities). The sections below cover each.

Identity

• Name — required, up to 100 characters, and one per organization: a name another role already has (capitals aside) turns the field red with Name already taken, as you type and when you save. 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, with Select all and Clear above it and how many are on (5 of 19 on). Checking any sub-permission automatically grants Access admin panel (the canAccessAdmin key) — without it, none of the sub-permissions do anything — and holds it on: it can't be cleared while any sub-permission is checked. Unchecking the last sub-permission automatically revokes admin panel access. The list shows the permissions you hold yourself (you can grant only those) and any the role already has, which you can't change; the rest are counted under the list as not listed, and the role's count is out of the permissions listed.

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.)

Member defaults

The Member defaults tab has three groups: Starting values, Rules and Capabilities (see Capabilities below).

Starting values — Used once, when someone joins with this role. Changing a member's role later keeps their own choices.

• Memory at start — whether a new member's memory starts on.
• Chat history at start — whether a new member's conversation history starts saved.

Each offers Organization default, On or Off. Organization default uses the Memory or Conversation history default under Organization → Member defaults; if you hold Manage org settings, it also shows that value in parentheses, for example Organization default (Off). Every role starts on Organization default, and a built-in role always stays on it, so nothing changes for anyone until you pick On or Off on a custom role.

A starting value is applied once, at the member's first sign-in, after their role and groups are in place, and it replaces only what the organization default gave them: a value an invitation's pre-configuration set is kept. It is never applied again, so a later sign-in, or a move to another role, keeps what the member has. When the member's own role is on Organization default, the roles bound to their groups can supply the value instead, where group roles add settings (see Binding a role to a group) and every one of them that sets a value sets the same one. A closed Memory or Conversation history padlock under Organization › Member defaults still decides the value for everyone.

Rules — These apply all the time.

• Database permission — the level members of this role get on your organization's shared connections, unless a member has their own level for a connection. 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. The unit counts this role's number and any per-user override for a member of the role; with the number blank, the unit has no effect and the organization's number and unit apply (or, if the organization sets no number either, the deployment default, counted in chats). See Rate limits and quotas.
• Auto-approve database writes — skip the in-chat confirmation prompt before write statements run. It applies on your organization's shared connections unless a member has their own setting for a connection, and it never comes from a role bound to one of their groups.

Database permission and Auto-approve database writes appear once SQL Server is allowed for your organization.

Whether turns that used an extension are saved is not a role setting. It is governed for the whole organization by Extension output in history in Organization, and each member can only narrow it for themselves.

Allowed extensions

The eight extensions are:

• SQL Server — adds the Tables, Procedures, Explorer and Schema Map 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; where writes are permitted, create issues, add comments (always internal notes on a service request), change an issue's status, and edit its fields. 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 → Apps.

Unchecked extensions are hidden from the user's UI entirely (the sidebar, the extensions toggle in chat, the Settings → Apps page) and the corresponding AI tools become unavailable. A role saved with nothing ticked grants no extension and no connector, including connectors your organization adds later, on every surface: web chat, the Outlook add-in, the Teams bot, the /v1 API and scheduled agents. Whatever a role bound to one of the member's groups grants still reaches them, and shows in their sidebar, the agent form and the Directory.

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 → Models → Manage models.

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.

Capabilities

The last group on the Member defaults tab. Each capability can only narrow the organization's setting: no role can turn on something the organization has switched off.

• Analysis — lets the AI run code in an isolated sandbox (data analysis, charts, file transforms) during chats. Its options read Inherit org default, Allowed (does not narrow), and Denied. Inherit and Allowed both follow the org-wide setting; Denied turns it off for members of the role. The same control can be set per user in the Users page, where the most specific level wins: a member set to Allowed there keeps it even if their role says Denied, but never while the organization has it off.
• Sub-agents — lets the AI spawn parallel sub-agents for complex, multi-part work. Same three options, resolved the same way as Analysis.
• Jira writes — lets the AI create Jira issues, post comments, change an issue's status, and edit its fields 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.
• Sub-agent approvals — the most members of this role can choose for a chat's sub-agents: Inherit from organization, Members can choose any mode, Up to Do not ask, refuse instead, Up to Ask before anything leaves, Up to Ask only when risky, or Always ask. It sits with the Sub-agents control. Like the write controls, it can only narrow: the most restrictive of organization, role and user applies, so a role set to "any mode" cannot loosen an organization limit.

Narrowing one of these here is visible from the other end. Each of the four capabilities carries a cascade line under its switch under Organization › Member defaults — Organization: On · 2 of 5 roles turn it off · 3 members have an exception — and the role count links back to this page. An admin reading the org switch can see at a glance that roles are narrowing it, rather than discovering it from a member's support ticket. See The cascade line on a capability.

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 pages and comment for Confluence — both set on the Atlassian extension page (Settings → Apps → Atlassian → Manage, described in Organization):

• 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 Organization → Users → (manage user) → Access, 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 writes to Jira Service Management requests (comments, status changes and field edits) 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). 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. When a user also belongs to a group with roles bound to it, this layer is the union of their direct role's list and every group-bound role's list — a group can add models, never remove them. The union is still capped by the organization layer above.
3. Per-user — from Organization → Users → (manage a user) → Access → AI models, you can restrict a single person below their role's set. A model their roles don't allow is listed as Not allowed by their role and can't be ticked there; widen the role instead. Leaving every box checked (or unchecking all of them) means inherit — the user gets every model the org and role allow, and with nothing ticked the list says Nothing is ticked, so this user gets every model their role allows: N of M. 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. A scheduled agent pinned to such a model doesn't snap. Turning a model off for the whole organization asks first while an agent that can still run is set to it: the Model Catalog lists those agents by owner and turns the model off only when you confirm (paused agents, and agents owned by disabled members, aren't counted). The role, group and per-user layers warn rather than refuse: saving a role, changing a member's role (on their record or with the bulk Change role action), changing their groups, removing them from a group (on the group or with the bulk Remove from group action), unbinding a role from a group, deleting a group, or narrowing a member's per-user list goes through even when it leaves out a model one of their agents uses, and the page then names the agents that will pause — <N> agents will pause, <agent> (<owner>), <agent> (<owner>), <agent> (<owner>) and <N> more, owned by <M> people, run on a model this change no longer allows. They pause the next time they run on a schedule, a webhook or another agent, until moved to another model; Run now is refused. Each owner is told. It names three agents at most, however many there are, and counts the rest and their owners; when they are all one person's it reads …, owned by <owner>, run on… and ends Their owner is told., and for one agent <agent>, owned by <owner>, runs on a model this change no longer allows. It pauses the next time it runs… and Its owner is told. Only the agents the change newly leaves without their model are named; one an earlier change already left out isn't named again. If Strata can't check which agents were left without their model before the save, or which are after it, the save still goes through, without that warning; each owner still gets the Inbox notice when their agent pauses. A change your identity provider makes over SCIM doesn't warn. The next time such an agent's schedule, a webhook or another agent starts it, it is paused, and its owner's inbox names the setting that refuses it — for a role, Agent model "<model name>" is not allowed by your role or group roles. An admin can allow it on your role in Organization › Roles, or you can edit this agent to use one of: … — and says to press Resume on it to start it again. Until the owner may use the model or the agent is edited to another one, Resume is normally refused (This agent can't resume. …). Run now is refused without pausing it, and the Agents page normally says why straight away in a Could not start run notice.

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 → Access → Database access (most specific). Its Role default option names the level the member's roles give them today, for example Role default (Editor), and stores no level of its own, so the connection keeps following the role.
2. Role default — Database permission on the role's Member defaults tab (above). Where group roles add settings, a role bound to one of the member's groups can raise it, never lower it; see Binding a role to a group.
3. Organization default in Organization → Member defaults → Default database access, where the tiers read Read-only, Approve edits and Full control.

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 section of Organization holds all of them. Freeze agent changes stops creating and editing agents for the whole org (runs continue); the six limits under Count and frequency and Cost are the ceilings; and the same section publishes reusable org agent templates that every member can deploy in one click.
3. Per-user controls — from Organization → 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-wide stop 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, and changes Jira issues' status and fields, 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 tab. It saves as soon as you pick it.

The change appears in the audit log as user.role_assigned. Session permissions rehydrate within roughly 30 seconds, and the member's sidebar picks the change up without a reload the next time their Strata tab comes back into view or focus (at most once a minute). To force the change to take effect immediately, use Force sign out (all devices) in the same modal. Changing a role does not apply the new role's starting values: those are used only at a member's first sign-in.

Binding a role to a group

A role is not only assignable as a person's single direct role — it can also be bound to a group, so that every member of that group inherits the role's permissions. This is Strata's group-level RBAC: you shape access for a whole team by binding the right role to their group, rather than editing each person one at a time.

To bind a role, open Organization → Groups, click into a group, and use its Roles section (which needs the Manage roles permission). A group may carry several roles, and a role may be bound to several groups.

The fold is grant-only — a bound role can only widen what members can do, never narrow it. A member's effective access is the union of their one direct role and every group-bound role:

• Admin permissions are OR-ed in.
• Allowed extensions and Allowed AI models are unioned with the member's direct-role lists.
• The result is then intersected with org policy and any per-user deny, exactly as for a direct role.
• Database permission, where group roles add settings (below), can raise the member's level on your organization's shared connections to the highest level among their roles, never lower it. A member's own setting on a connection still replaces it, and Auto-approve database writes never comes from a group.

Separately from access, where group roles add settings, bound roles can also supply a new member's Starting values at their first sign-in, when the member's own role is on Organization default and every bound role that sets a value sets the same one.

Where group roles add settings. Whether a group's roles can raise database access and supply starting values is decided per organization. It is off for now in organizations that already existed when this arrived, and on in organizations created since; there is no setting to change it yet. To see which applies to yours, open a member in Users and read Data & sessions → Where their permissions come from: while it is off, the line under that heading ends Group roles don't change database access in your organization yet. Admin permissions, extensions and models from group roles apply either way.

Two guards apply, both enforced server-side:

• Escalation ceiling. You can only bind a role whose permissions you already hold — the same ceiling that governs creating and assigning roles (below). Binding a role that grants a permission you lack is refused.
• Last-admin guard. Once a group carries an admin-granting role, unbinding that role, deleting the group, or removing its last member is refused if it would leave the organization with no effective admin.

Binding a role that grants elevated permissions also makes the group privileged: changing its membership then requires Manage roles, and automated (SCIM) provisioning can no longer add members to it. See Groups for the full behavior.

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.

A role that is still bound to a group (see Binding a role to a group below) cannot be deleted either. That request returns Cannot delete role — it is still bound to N group(s). Unbind it from those groups first. Unbind it everywhere, then delete.

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 padlocks instead of removing permissions. To keep memory off for everyone, turn Memory off under Organization settings → Member defaults and close its padlock so members cannot turn it back on. To start only one role's new members with memory off, set Memory at start to Off on that role instead; they can still turn it on themselves.
• 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
• Groups — binding a role to a whole team
• Organization
• Per-user agent governance
• Atlassian extensions