Skip to main content
Version: 2026-08-05

Permissions & Default Permissions

The platform uses a permission system to control which features each user can see and use. Permissions are grouped by area (agents, chat, system settings, etc.) and assigned to user groups.

How Permissions Apply​

Each user inherits permissions from the user groups they belong to. The union of all granted permissions across their groups determines what they can do. See User Management for how to manage groups and group membership.

The chat UI, settings pages, and tool cards check these permissions and hide or disable features the user can't access.

Default Permissions for New Users​

When a new user is created (e.g. via SSO sign-in), they start with a configurable default permission set. Administrators can edit this default from the User Groups settings.

Editing Defaults​

  1. Navigate to Settings → User Groups — requires the groups.read and groups.create permissions
  2. Click Default permissions at the top of the page (shield icon, next to + Create Group)
  3. Toggle individual permissions on or off, grouped by category
  4. Save to apply, or Reset to system defaults to discard customisation

Default Permissions dialog

The dialog header confirms the current state — "Currently using system defaults" if you haven't customised it, otherwise it indicates the tenant has its own defaults set.

Existing users are not affected — the default permission set only applies to users who sign up after the change. To update existing users, modify their group memberships in User Management (requires users.read and users.create).

Permission Categories​

The Default Permissions dialog organises grants into categories that mirror the platform's feature areas. Each category contains toggleable permissions; the exact set varies by deployment.

  • Agents — View Agents, Edit Agents, Create Agents, Delete Agents, Manage All Agents
  • Users — View Users, Edit Users, Create Users, Delete Users
  • Groups — View User Groups, Edit User Groups, Create User Groups, Delete User Groups
  • Tools — Per-tool toggles such as Use Chat, Use Transcripts, Use Bullseye, Use ROI Calculator, Use Sentiment Analysis, Use Retail Analytics, Use n8n Integration, Use linkedInConnections Integration
  • Scheduled tasks — Configure manual email recipients (scheduled_tasks.recipient_emails) allows users to add and manage manually entered distribution-list addresses for scheduled-task results. It does not affect user-group recipients.

Additional category groups (system settings, audit logs, personal prompts, MCP visibility, etc.) appear when their underlying features are present in the deployment.

Manual Scheduled-Task Recipients​

scheduled_tasks.recipient_emails is opt-in and is not part of the system default permission set. Grant it to an appropriate user group in Settings -> User Groups when members need to send scheduled-task results to manually entered email addresses.

Without this permission, users can continue to configure user-group recipients, but the manual-recipient controls are hidden. The scheduled-task API also rejects attempts to add non-empty manual recipient lists with a 403 response, so the restriction applies to direct API clients as well as the user interface.

Group-Scoped Resources​

Some access is controlled by group membership on the resource rather than by a permission toggle. In these cases there is no permission to grant — you add the group to the resource:

ResourceWhere access is set
AI modelsThe model's User Groups in Model Settings
Knowledge basesThe knowledge base's Access tab
AgentsThe agent's Access tab
Landing page cardsThe card's Visibility in Landing Page Cards

The convention is consistent: leaving the group list empty means available to everyone, and adding groups restricts to those groups. An empty list is not "nobody".

caution

Because these are set per resource, adding a user to a group can widen their access to models, knowledge bases and agents immediately — including for future scheduled-task runs. Review group membership changes with that in mind.

Permission Inheritance​

When evaluating whether a user can do something, the platform checks:

  1. Permissions granted by the user's group memberships
  2. Tenant-wide default permissions (only at user creation time)
  3. Resource-level visibility (e.g. an agent set to private overrides group permissions)