Access Control lets organization admins define permission groups that restrict what each set of users can do — which AI model providers they can use, which workflow blocks they can place, and which platform features are visible to them. Permission groups are scoped to the organization. The organization's default group governs everyone org-wide; every other group targets a specific set of workspaces and, by default, governs all members of those workspaces (including external members) — or only specific members once you add them. A user is governed by exactly one group in any given workspace. Restrictions are enforced both in the workflow executor and in Chat, based on the organization that owns the workflow's workspace.
How it works
Each group belongs to a specific organization and has a name, an optional description, a workspace scope, an optional member list, and a configuration that defines what its members can and cannot do. Personal or grandfathered workspaces that do not belong to an organization have no permission groups.
Agent Serve resolves the governing group for a user in a workspace deterministically:
- a non-default group targeting that workspace that the user is an explicit member of takes precedence; otherwise
- a non-default group targeting that workspace that applies to the user's workspace role (Read, Write, or Admin) applies; otherwise
- a non-default group targeting that workspace that has no members and no roles (so it governs all members of the workspace, including external members) applies; otherwise
- the organization's default group applies (if one is set); otherwise
- no restrictions apply.
Assignment-time checks keep this unambiguous: a workspace has at most one all-members group and at most one group per role, and a user is an explicit member of at most one group per workspace.
Permission groups govern every role, workspace admins included. No workspace role is exempt, and a group can target the Admin role on purpose. Organization owners and admins keep the member directory whatever their group, as the Member Directory row describes.
When a user runs a workflow or uses Chat, Agent Serve reads the resolved group's configuration and applies it:
- In the executor: If a workflow uses a disallowed block type or model provider, execution halts immediately with an error. This applies to both manual runs and scheduled or API-triggered deployments.
- In Chat: Disallowed blocks are filtered out of the block list so they cannot be added to a workflow. Disallowed tool types (MCP, custom tools, skills) are not filtered during generation — Agent Serve is told about the restriction but may still produce a step that uses one. Such a run fails at execution with an error naming the restriction.
Setup
1. Open Permission groups settings
Go to Settings → Organization → Permission groups from any workspace in your organization. Permission groups are defined once at the organization level and apply to every workspace under it. Only organization owners and admins can manage them.
2. Create a permission group
Click + Create and enter a name (required) and optional description. A group either targets a specific set of workspaces (pick them from the multi-select) or is the organization default group. A workspace-scoped group applies to all members of its workspaces by default, including external members — you can narrow it to specific people later. Marking the group as the default makes it govern every workspace in the organization and every member not covered by another group (including external members); only one group per organization can be the default, and the default always applies to all workspaces.
3. Configure permissions
Click Details on a group to open its configuration. It has four tabs — General, Model Providers, Blocks, and Platform. Name, description, and the permission settings are buffered until you save; the workspace scope, the default-group switch, and member changes are applied immediately, so Discard does not undo them.
Throughout the editor, a checked box means allowed. Clearing a checkbox is what applies a restriction.
General
Holds the group's Name and Description, the Default group switch, the Workspaces the group governs, and its Members.
A workspace-scoped group with no members applies to everyone in its workspaces (including external members). Add members here — searching your organization by name or email — to restrict the group to only those people; removing every member returns it to governing everyone. The default group ignores members and governs every workspace in the organization.
Applies to lists the workspace roles: Read role, Write role, and Admin role. With no role selected, the group applies to every member of its workspaces. Select one or more roles to apply it only to members with those roles, for example a stricter group for Read members. Members you add by name take precedence over roles. External members hold no workspace role, so a role-targeted group never governs them. The default group has no Applies to setting.
Model Providers
Controls which AI model providers members of this group can use.
The list shows all providers available in Agent Serve.
- All checked (default): All providers are allowed.
- Subset checked: Only the selected providers are allowed. Any workflow block or agent using a provider not on the list will fail at execution time.
Expand a provider row to reach its model denylist. Clearing individual models blocks exactly those models while leaving the rest of the provider available — useful when a provider is sanctioned but a specific model is not.
Blocks
Controls which workflow blocks members can place and execute.
Blocks are split into two sections: Core Blocks (Agent, API, Condition, Function, etc.) and Tools (all integration blocks).
- All checked (default): All blocks are allowed.
- Subset checked: Only the selected blocks are allowed. Workflows that already contain a disallowed block will fail when run — they are not automatically modified.
Expand an integration block to reach its tool denylist. Clearing individual tools blocks those operations while leaving the rest of the integration usable — for example, allowing a member to read from a service but not to delete in it.
The start_trigger block (the entry point of every workflow) is always allowed and cannot be restricted.
Platform
Controls the modules, actions, and credentials available to group members. Every row refuses at the API, not only in the UI — clearing a box revokes the access; it does not merely hide a tab.
Start from preset fills the Platform tab with a ready-made set of module access, which you can change before saving. Presets are templates: nothing records which one a group started from.
| Preset | Module access |
|---|---|
| Field user | Chat and Apps. No Relays, Dashboards, Monitors, or Workbooks, and no building. |
| Viewer | Dashboards and Apps, without building. No Chat, Relays, Monitors, or Workbooks. |
| Analyst | Chat, Dashboards, Monitors, Workbooks, and Apps, with dashboard building and data management. No Relays, and no building workflows, the semantic model, or apps. |
| Builder | Every module, including building. |
| Admin | Every module, including building, and clears every other restriction on the tab too. |
Every preset except Admin changes only the module rows below and leaves the group's other restrictions as they were. Default models and confirmation thresholds are kept by every preset.
Modules
| Feature | What clearing it withholds |
|---|---|
| Chat and Relays | Revokes Chat and Relays together. Members cannot ask Agent Serve to build or edit anything. Kept for groups created before Chat and Relays had their own rows. |
| Agent Serve Mailer | Revokes the Agent Serve Mailer inbox. Members cannot read or send mail. |
| Sandboxes | Revokes the Sandboxes module. Members cannot view, create, or change a workspace sandbox. |
| Live | Revokes Agent Serve Live. Members cannot use Live in calls or open the Live admin portal. |
| Chat | Revokes Chat. Members cannot start or continue a conversation with Agent Serve. |
| Relays | Revokes Relays. Members cannot read, brief, or approve a Relay, or open its inbox. |
| Dashboards | Revokes Dashboards. Members cannot open, query, or subscribe to any dashboard or metric. |
| Dashboard Building | Prevents creating or editing dashboards and panels, leaving existing ones viewable. Clearing Dashboards withholds this too. |
| Workflow Building | Prevents creating, editing, test-running, or deploying workflows, leaving deployed workflows running. It also withholds API, MCP server, and chat deployment. |
| Data Management | Prevents managing data sources, datasets, row security, and table columns. |
| Model Management | Prevents changing the semantic model, metric definitions, scorecards, or rules, including model drafts and publishing. |
| Monitors | Revokes Monitors. Members cannot read, create, or change a monitor or its alerts. |
| Workbooks | Revokes Workbooks. Members cannot open a workbook, run its queries, or ask AI to write SQL. |
| Apps | Revokes Apps. Members cannot open an installed app or reach data through one. |
| App Building | Prevents uploading, publishing, installing, or configuring apps, leaving installed apps usable. It also withholds the browser IDE. Clearing Apps withholds this too. |
Module rows govern what a person reaches. A workflow run is governed by the Blocks and Model Providers tabs and the Tools rows instead, so withholding Tables does not break a workflow with a Table block. See Unattended runs for whose group gates a run nobody started by hand.
Knowledge Base
| Feature | What clearing it withholds |
|---|---|
| Knowledge Base | Revokes the Knowledge Base module. Members cannot open, search, or query any knowledge base. |
| Knowledge Base Creation | Prevents creating knowledge bases, leaving existing ones queryable. |
| Knowledge Base Uploads | Prevents uploading local documents, leaving sanctioned connectors as the only source. |
| Knowledge Base Export | Prevents downloading a whole knowledge base as an archive. |
The Knowledge Base row also carries a connector allowlist — Connectors knowledge bases may sync from. Leave it untouched to allow every connector, or select a subset to limit which external sources a knowledge base may sync.
Tables
| Feature | What clearing it withholds |
|---|---|
| Tables | Revokes the Tables module. Members cannot read or write any table. |
| Table Creation | Prevents creating tables, leaving existing ones usable. |
| Table Export | Prevents downloading a whole table as CSV or JSON. |
Files
| Feature | What clearing it withholds |
|---|---|
| Files | Revokes the Files module. Members cannot list, upload, or download workspace files. |
| Public Sharing | Revokes public file sharing. Members cannot create a share link. |
| Bulk Download | Prevents downloading folders as an archive. |
The Public Sharing row also carries an auth-mode allowlist — Auth modes public file-share links may use (Anyone with link, Password, Email, SSO). Select a subset to force share links onto stronger authentication.
Deployment
| Feature | What clearing it withholds |
|---|---|
| Public API | Revokes public API access. Calls to a deployed workflow are refused. |
| API Deployment | Prevents deploying a workflow as an API endpoint. |
| MCP Server | Prevents exposing a workflow as an MCP server. |
| Chat Deployment | Prevents publishing a workflow as a chat. |
| Webhook Triggers | Prevents making a workflow reachable from an inbound webhook. |
The Chat Deployment row also carries an auth-mode allowlist — Auth modes chat deployments may use (Public, Password, Email, SSO).
Tools
| Feature | What clearing it withholds |
|---|---|
| MCP Tools | Blocks agents from calling MCP tools. |
| Custom Tools | Blocks agents from calling user-defined custom tools. |
| Skills | Blocks agents from loading skills. |
| Tool Auto-Approval | Prevents auto-approving tool calls, so every call must be confirmed. |
Logs
| Feature | What clearing it withholds |
|---|---|
| Trace Spans | Withholds per-block trace spans from logs and from the API. |
| Log Export | Prevents downloading execution logs as a CSV. |
| Execution Cost | Withholds execution cost. Logs and member exports omit cost and token spend; organization-level data drains, configurable by org admins only, are not projected. |
Collaboration
| Feature | What clearing it withholds |
|---|---|
| Invitations | Prevents inviting anyone to a workspace or to the organization. |
| Workspace Creation | Prevents creating new workspaces. A new one is not covered by any workspace-scoped group until you add it, though the organization's default group still governs it. |
| Member Directory | Withholds the member directory. Members cannot see the names or email addresses of other members. Organization owners and admins keep access — the roster routes exempt those roles. |
Credentials & Access
| Feature | What clearing it withholds |
|---|---|
| Integrations | Revokes integration connections. Members cannot view, add, or remove an OAuth connection. |
| Secrets | Revokes secrets. Members cannot read, add, or change a workspace environment variable. |
| API Keys | Revokes workspace API keys. Members cannot list, create, or revoke one. |
| Personal API Keys | Prevents members from using a personal API key against this workspace. |
| Personal Credentials | Prevents connecting personal credentials, leaving only workspace-shared ones. |
| CLI Access | Prevents approving a CLI login or using Agent Serve CLI OAuth tokens for the public API. Existing API keys retain their own restrictions. |
| OAuth App Access | Prevents OAuth apps from accessing the group's workspaces. The organization default group also governs authorization, token issuance and refresh, and account-level billing and audit reads. |
Models
| Feature | What clearing it withholds |
|---|---|
| Models Without Zero Data Retention | Prevents running Chat on a model that has no zero-data-retention endpoint; every model request is pinned to zero-data-retention endpoints. Image, video, and audio models have none, so this also withholds media generation. |
| Media Generation | Prevents generating images, video, music, and speech, in Chat and in workflow blocks. |
Rows read from the organization default group
Four rows — Workspace Creation, Member Directory, Models Without Zero Data Retention, and Media Generation — are read only from the organization's default group, because the policy they set covers the whole organization. On any other group the editor renders them inert, tags them Organization, and skips them in Select All. Set them on the default group.
Six more rows — Integrations, API Keys, Invitations, Personal API Keys, CLI Access, and OAuth App Access — apply on the group in front of you for anything scoped to one of its workspaces. Account-level actions use the organization's default group, including minting a personal key, sending an organization-wide invitation, approving a CLI login, and authorizing or refreshing an OAuth app.
4. Choose who it applies to
A user is governed by one group per workspace, so adding a user is rejected when it would conflict with another of their groups on a shared workspace (skipped rather than added in bulk). The default group ignores members entirely — it always governs everyone not covered by a workspace group.
A workspace also has at most one all-members group. Adding a workspace to a group, or removing a group's last member, is rejected when doing so would violate that — memberships and scopes are never silently moved.
Manage which workspaces a group governs from the Workspaces list on the same General tab. A non-default group is created targeting at least one workspace, but you can later remove all of them — a group with no workspaces simply governs nothing until you add one back.
External workspace members (people who have access to a workspace but belong to a different organization) can't be added as named members, but a workspace-scoped group with no members — and the organization default group — still governs them.
Enforcement
Workflow execution
Restrictions are enforced at the point of execution, not at save time. If a group's configuration changes after a workflow is built:
- Block restrictions: Any workflow run that reaches a disallowed block halts immediately with an error. The workflow is not modified — only execution is blocked.
- Model provider restrictions: Any block or agent that uses a disallowed provider halts immediately with an error.
- Tool restrictions (MCP, custom tools, skills): Agents that use a disallowed tool type halt immediately with an error.
This applies regardless of how the workflow is triggered — manually, via API, via schedule, or via webhook.
Unattended runs
A run nobody started by hand — a schedule, a webhook, or a call with a workspace API key — has no person behind it. Agent Serve gates its blocks, tools, and models against the permission group of the member who deployed the version that runs: the person who decided it should run unattended. A member who is denied a tool cannot reach it by putting a workflow on a schedule.
Billing is unchanged: the workspace's billing owner still pays for the run. Only the gate moves to the deployer.
If the deployer no longer has access to the workspace — removed, or suspended — the run stops with an error saying so, and the stop is recorded in the audit log. Redeploy the workflow as a current member to resume scheduled, webhook, and API runs. Versions deployed before deployers were recorded keep the previous behavior.
Chat
When a user opens Chat, their permission group is read before any block or tool suggestions are made:
- Blocks not in the allowed list are filtered out of the block picker entirely — they do not appear as options.
- Generation is not gated for these three tool kinds, so Agent Serve can still produce a step that uses one. The restriction is enforced when the run reaches it: execution fails with an error naming it.
Common Questions
Self-hosted setup
Self-hosted deployments use environment variables instead of the billing/plan check.
Environment variables
ACCESS_CONTROL_ENABLED=true
NEXT_PUBLIC_ACCESS_CONTROL_ENABLED=trueYou can also set a server-level block allowlist using the ALLOWED_INTEGRATIONS environment variable. This is applied as an additional constraint on top of any permission group configuration — a block must be allowed by both the environment allowlist and the user's group to be usable.
# Only these block types are available across the entire instance
ALLOWED_INTEGRATIONS=slack,gmail,agent,function,conditionOnce enabled, permission groups are managed through Settings → Organization → Permission groups the same way as Agent Serve Cloud.
See how modules are used
Before you withhold a module, check how it is used. Settings → Organization → Insights → Modules shows, for the last 30 days, the credits spent in each module, a daily trend, and how many people were active in it in the last 7 and 30 days. See Insights.