User Groups

User Groups let you manage permissions for teams in your organization. By organizing users into groups, you can efficiently manage security policies and access controls across integrations, models, DLP, and platform features.

Note

You must be an Administrator to create and manage user groups.

Access Control Rules

User groups follow two core principles:

1. Organization settings are the baseline — Group settings cannot override organization-level restrictions. If the organization disables something, no group can re-enable it.
2. Permissions are additive across groups — When a user belongs to multiple groups, they receive the combined permissions of all their groups. If one group grants access and another restricts it, access is granted.

Administrators are exempt from all user group restrictions and always have full access.

Permission Areas

User groups control five areas:

Area	What it governs
Integration access	Which integrations users can connect and use
Model and provider access	Which AI models users can access
DLP enablement and configuration	Whether DLP filters apply and how they are configured
Tool action access	Which specific tool actions are available per integration
Feature permissions	Platform capabilities like agent creation, file upload, and API key access

Creating a User Group

1. Navigate to Settings (gear icon) > User Groups.
2. Click Create User Group. A new group with an auto-generated name is created and opened.
3. On the Members tab, add members via the dropdown selector or comma-separated email addresses.
4. On the Permissions, Integration + Tool, and Model access + DLP tabs, configure the group’s policies.

Managing Group Members

From the Members tab of a user group, administrators can:

• Add individual members via the dropdown selector
• Add multiple members by entering comma-separated email addresses
• Remove members from the group

Integration Access

Organization-level integration settings are the ceiling. If an organization disables an integration, no users can access it regardless of group membership.

How Group Memberships Affect Access

When a user belongs to multiple groups, they get access to all integrations from all their groups.

Example:

• Organization has access disabled for Jira
• User A belongs to “IT” and “Analytics” groups
• IT group has access to Slack, but access is disabled for Google Drive
• Analytics group has access to Google Drive and ServiceNow
• Result: User A gets access to Slack, Google Drive, and ServiceNow

For fine-grained control over specific tool actions within an integration, see Tool Action Access Controls.

Model and Provider Access

Organization-level model settings are the ceiling. If an organization disables a model or provider, no users can access it regardless of group membership.

How Group Memberships Affect Access

When a user belongs to multiple groups, they get access to all models from all their groups.

Example:

• Organization has access disabled for Claude 3.5 Sonnet
• User A belongs to “Research” and “Engineering” groups
• Research group has access enabled for GPT-4, but access disabled for Claude 3 Opus
• Engineering group has access enabled for Claude 3 Opus, but access disabled for Llama 3
• Result: User A gets access to GPT-4 and Claude 3 Opus

For managing which models are available organization-wide, see Security Controls — Model Access.

DLP Enablement and Configuration

Data Loss Prevention (DLP) filters redact sensitive data before it reaches AI models. DLP settings operate at two levels: enablement (whether DLP is active for a model) and configuration (which patterns are redacted).

DLP Enablement

Organization level:

• If DLP is enabled for a provider, then DLP can be enabled for individual models under that provider.
• If DLP is disabled for a provider, none of its models can have DLP enabled.

User group level:

• If the organization has disabled DLP for a model or provider, user groups cannot enable it.
• If the organization has enabled DLP and any of the user’s groups has DLP enabled for that model, DLP is active for that user.

DLP Configuration Cascade

DLP configuration follows an override hierarchy. More specific settings override broader ones:

Organization level:

1. A model-specific custom DLP configuration overrides both the provider configuration and the organization’s base configuration.
2. A provider-specific custom DLP configuration overrides the organization’s base configuration.

User group level:

1. A model-specific custom DLP configuration for a user group overrides both the provider configuration and the group’s base configuration.
2. A provider-specific custom DLP configuration for a user group overrides the group’s base configuration.
3. The user group’s final configuration is always combined with the organization’s configuration, applying the most restrictive rule from each. This also holds when a user belongs to multiple groups.

Example:

• Organization has custom DLP configuration for GPT-4 (only “NRP” redacted)
• User A belongs to “Research” and “Engineering” groups
• Research group has custom DLP configuration for Azure (GPT-4’s provider, only “Location” redacted)
• Engineering group has no custom DLP configuration, but its base DLP configuration redacts “IP Address”
• Organization, Research group, and Engineering group all have DLP enabled for GPT-4
• Result: When User A uses GPT-4, the following patterns are redacted: NRP (from organization), Location (from Research group), IP Address (from Engineering group)

For more on DLP filter types and custom patterns, see Security Controls — DLP Filters.

Tool Action Access

User groups can control which specific tool actions are available per integration, beyond simple integration-level enable/disable. This includes restricting agents to read-only operations, scoping access by team, and enforcing least privilege.

For the full configuration guide, examples, and troubleshooting, see Tool Action Access Controls.

Feature Permissions

Feature permissions control platform capabilities for group members. These are configured on the Permissions tab of a user group.

Admins are exempt from all feature permission restrictions and always have full access regardless of group membership.

Permission	Default	Description
Ask Mode Only	Off	Restricts members to Ask mode only — disables Actions mode. Enforced on both the frontend and backend (including the Responses API).
Allow Agent Creation	On	Controls whether members can create, duplicate, or save agents.
Chat Messaging	On	Controls whether members can send chat messages. When disabled, members cannot start new conversations, send follow-up messages, or type in the prompt bar. Members can still browse and run shared agents — the only messages that can be sent are those predefined via an agent step.
File Upload	On	Controls whether members can upload files.
Personal API Key Access	Off	Controls whether members can create personal API keys and whether those keys are valid at runtime. Model and provider access restrictions from user groups still apply to API requests. Ask Mode Only is still enforced on the Responses API. Does not affect admin-created API keys.
Show Agents Tab	On	Controls whether the Agents tab is visible in the sidebar.

How Group Memberships Affect Feature Permissions

When a user belongs to multiple groups, the most permissive setting wins:

• Ask Mode Only — The user is only restricted if all their groups enforce it. If any group has it off, the user can use Actions mode.
• Allow Agent Creation — The user can create agents if any of their groups allows it.
• Chat Messaging — The user can send chat messages if any of their groups allows it. API key access is not restricted by this permission.
• File Upload — The user can upload files if any of their groups allows it.
• Personal API Key Access — The user can create and use personal API keys if any of their groups enables it. Admin-created API keys are always valid regardless of this setting.
• Show Agents Tab — The user sees the Agents tab if any of their groups shows it.

Example:

• User A belongs to “Restricted” and “Power Users” groups
• Restricted group has Ask Mode Only enabled and Allow Agent Creation disabled
• Power Users group has Ask Mode Only disabled and Allow Agent Creation enabled
• Result: User A can use Actions mode and create agents, because the Power Users group grants both permissions

Caution

Disabling Personal API Key Access takes effect immediately. Any existing API keys created by affected members will stop working on the next API request. Before toggling this setting off, ensure affected users are aware that their active API integrations will break. This does not affect API keys created by admins on behalf of users.

Next Steps

• Security Controls to manage model access, DLP filters, and audit logging
• Tool Action Access Controls for fine-grained integration and tool permissions
• Governance and Controls for an overview of Kindo’s governance framework