Permission groups restrict what people can use in an organization's workspaces. Set a provider or block allowlist, deny individual models or tool operations, or limit platform actions such as exports and deployments. Workspace membership and roles still determine which resources a person can access; a group does not grant access.
Organization owners and admins manage groups under Settings → Organization → Permission groups. Billing-enabled deployments require Enterprise. Billing-disabled deployments use the feature configuration described under Self-hosted setup. Workspaces without an organization have no permission groups.
Create and configure a group
- Open Settings → Organization → Permission groups and click Create group.
- Enter a name and optional description. Select at least one workspace, or make the group the Default group for the organization.
- Open the group's row. Configure its General, Model Providers, Blocks, and Platform tabs.
- Click Save to save its name, description, and permission configuration.
Changes to workspace scope, the default-group switch, and membership take effect immediately. Discard only discards the buffered name, description, and permission changes.
In the provider, block, and platform permission lists, a checked box allows the item. Clear it to restrict the item. The Project Issues project checklist is an exception: checked projects are restricted.
General
The General tab sets the name, description, workspaces, members, and default-group status. Sim selects a single governing group for each person and workspace:
- A non-default group targeting that workspace with the person as an explicit member.
- Otherwise, a non-default group targeting that workspace in inheritance membership mode with no named members. It governs all workspace members, including external members.
- Otherwise, the organization's default group, if configured.
- Otherwise, no permission-group restrictions.
The default is a fallback. Its restrictions are not combined with a selected workspace group. Only one group can be the organization default; it applies across the organization's workspaces and ignores a named-member list.
An ordinary workspace group starts by governing all members of its selected workspaces. Adding named members narrows it to those people. Removing its last member can make it govern everyone again. SCIM explicit-membership groups behave differently: an empty explicit group governs nobody. See SCIM provisioning.
Assignment checks allow at most one all-members group per workspace and at most one explicit group per person on a shared workspace. Conflicting individual assignments are rejected; conflicting people in bulk additions are skipped. Scope changes or removing the last inheritance-mode member can also be rejected if they would create a conflict. Sim does not silently move memberships between groups.
A non-default group needs a workspace when created, but you can later remove all its workspaces. It then governs nobody until you add a workspace. External workspace members cannot be selected as named organization members; the workspace's all-members group or organization default can still govern them.
Model Providers
All providers are allowed by default. Select a subset to allow only those providers. Expand a provider to deny individual models while leaving its other models available.
The Agent default chooses the initial model for new Agent blocks. Choose an allowed model, or Platform default to use Sim's default. This setting does not itself restrict models or rewrite existing blocks.
Blocks
Core Blocks contains blocks such as Agent, API, and Function; Tools contains integration blocks. All are allowed by default. Select a subset to restrict block types, then expand an integration to deny individual operations—for example, allow reads while refusing deletes.
The start_trigger entry block is always allowed. Existing workflows are not rewritten when a restriction changes. A run fails if it reaches a blocked type, provider, model, or tool operation.
Platform
Most platform restrictions refuse the protected operation at the server as well as limiting its UI. Trace Spans and Execution Cost instead control which fields an otherwise authorized log read or export returns.
Additional lists narrow selected capabilities:
- Knowledge Base has a connector allowlist. Leave it unrestricted to allow all connectors, or select permitted sources.
- Public Sharing has an auth-mode allowlist: Anyone with link, Password, Email, and SSO.
- Chat Deployment has an auth-mode allowlist: Public, Password, Email, and SSO.
- Project Issues restricts issue access for the checked projects. Governed teammates must have workspace access to every active environment in a selected project.
Restricting Tool Auto-Approval prevents remembering approval for future calls. It does not undo approval of the current call or force confirmation for tools that do not require it. Future calls that require confirmation prompt again.
Organization-level permissions
Workspace Creation and Member Directory read only the organization default, because those actions have no workspace scope. Other groups show them as inactive with an Organization tag, and Select All skips them. A newly created workspace uses the organization default until you add it to a workspace group.
Integrations, API Keys, Invitations, Personal API Keys, CLI Access, and OAuth App Access use the selected workspace group for workspace operations. Account-level operations use the organization default: minting a personal key, sending organization invitations, approving CLI login, authorizing or refreshing OAuth, and account-level billing or audit reads.
How enforcement applies
A human's governing group applies to session, personal API-key, OAuth, and delegated operations. Workflow restrictions are checked during execution, including deployments invoked by API, schedule, or webhook, using the operation's authorized identity. They do not replace workspace roles, credential access, or OAuth scopes.
A workspace API key acts as the workspace. It has workspace-role and operation policies but no human user's permission group; Sim does not apply the key creator's group as a substitute. A human's permission to create or manage that key is still governed.
Chat filters restricted blocks from its available block catalog. Generated steps can still reference a restricted MCP tool, custom tool, or skill; execution rejects the restricted operation when reached. After changing a group, verify both the person's available UI and a representative authorized run. For an existing workflow that fails, remove the restricted item or change the governing policy.
Self-hosted setup
On billing-disabled deployments, enable permission groups through the enterprise feature configuration or explicitly set:
ACCESS_CONTROL_ENABLED=true
NEXT_PUBLIC_ACCESS_CONTROL_ENABLED=trueThe enterprise master configuration can enable the feature; an explicit feature value takes precedence. Billing-enabled self-hosted deployments still require Enterprise. See self-hosted enterprise setup.
ALLOWED_INTEGRATIONS adds an instance-wide block allowlist. A block must satisfy both that list and the applicable group policy; start_trigger remains available.
ALLOWED_INTEGRATIONS=slack,gmail,agent,function,condition