Permissions and Access Control

Connect AI’s data governance allows managing permissions in bulk by using Role-Based Access Control (RBAC). You can grant access to resources directly to individual users or through one or more roles that credentialed users belong to. Roles determine permissions (data and execution access to entities) and privileges (administrative tasks such as billing, settings, and user management). You can further control how users connect to each data source by choosing an authentication pattern: either shared authentication, where all users access a data source through a single service account, or per-user authentication, where each user authenticates with their own credentials.

Users

An Administrator or User Administrator invites new users via email. Users sign in to Connect AI with a username and password (or use their company’s SSO if enabled on the account). Administrators can then assign the appropriate role or roles to the new user. If Just-in-Time (JIT) provisioning is enabled, a user account is created automatically the first time the user signs in through SSO, without a manual invitation. The new user receives a default Query system role and default connection and workspace permissions, which an Administrator or User Administrator can modify later. See Users and Roles and User Provisioning and SSO for details.

Roles

A role is a collection of administrative privileges, as well as permissions to access resources. Roles adhere to the following guidelines:

Any role can be assigned to any user.
Every role has specific permissions.
When a role is assigned to a user, the user gets all the permissions associated with that role. A user with multiple roles has all the permissions associated with each of them. Permissions are additive. A user’s access is the union of every permission from all their assigned roles, so the most permissive grant always applies. Roles never remove or override access granted by another role. For example, if a user has role_1 and role_2, with role_1 having Select permission for a data connection and role_2 having no access to the data connection, role_1 takes precedence, and the user has access to the data connection.

Connect AI contains four predefined system roles: Administrator, Connection Administrator, User Administrator, and Query. The following table defines the scope of each Connect AI system role.

Role	Scope	Log Access
Administrator	Full account access: connections, users, billing, settings	All query logs and all audit events
Connection Administrator	Create/edit/delete connections and workspaces; manage jobs and data warehouse; assign connection & workspace permissions; view users read-only; query all connections	All query logs; connection-domain audit events only
User Administrator	Create/invite/edit/disable users; assign/revoke User Administrator and Query roles; view connections & workspaces read-only; query connections where explicitly granted	User-domain audit events only (invites, user creation, role changes, PAT activity, impersonation, login activity); user’s own query logs only
Query	Query connections where granted permission; authenticate via User Credentials when configured	User’s own query logs only; no audit log access

Permissions

Permissions are more granular levels of access that make up roles. You can assign the following entity permissions:

For the purposes of permissions, an entity is a data connection (for example, Salesforce1) or a workspace (for example, MyWorkspace). Entities are displayed with the connection logo, and workspaces are displayed with a folder icon.

Select: The user can select rows from tables in an entity.
Insert: The user can insert rows into tables of an entity.
Update: The user can update rows in tables of an entity.
Delete: The user can delete rows from tables in an entity.
Execute: The user can execute stored procedures in an entity.

Connect AI offers two paths to assign these permissions: by user (one user across multiple entities) or by entity (one entity across multiple users).

Assign Permissions by User

You can grant entity permissions on a per-user basis from the Edit User page, or to multiple users at once by defining an access role on the Edit Role page. The permissions coexist additively; that is, assigning a user to a role never removes a user’s direct permissions.

Click an individual box in the table to toggle a permission for a single entity, or click the box at the top of a table column to toggle that permission for every entity.

Assign Permissions by Entity

You can also assign permissions on an entity basis via the Edit/Add Connection page or via the Workspace page. For example, in the Permissions tab of the Edit Acumatica Connection page, you can grant permissions on the connection to multiple users at once. All users can select data, but only three users can insert data:

Click an individual box in the table to toggle the permission for a single user, or click the box at the top of a table column to toggle that permission for all users.

Workspace Access and Source Permissions

When a workspace contains an asset that originates from a source connection, access to that asset is governed by the workspace permission rather than the source connection permission. A user who has access to a workspace can access the assets in that workspace regardless of whether they have access to the underlying source connection (either through per-user permissions or through a role). This workspace-scoped access applies even when the workspace is added to a toolkit and exposed to an AI through a custom MCP endpoint. In other words, if a user has been granted access to a workspace, they can access the assets in that workspace through the custom MCP endpoint even if they do not have access to the source connections those assets come from.

Authentication Patterns

Service Account (Shared) Authentication

By default, all users on an account can access data from a data source using a service account, or shared authentication. Use service account authentication for read-only data sources that do not contain user-specific permissions or systems that lack per-user authentication. For example, if you have a connection to Salesforce with a service account (shared authentication), all user accounts can access the data from the Salesforce account created for that Salesforce connection. Query permissions can be customized for each user to restrict available operations, but all users access the same data under these restrictions.

Per-User Authentication

Certain data sources support the ability to force each user on an account to log in to a connection with their own login credentials. Use per-user authentication to comply with regulatory requirements or for data that varies by user. Per-user authentication ensures that users can only access the data from accounts that they need to access. Furthermore, when a connection is configured in this way, it only counts as a single connection slot toward your account maximum. If a data source supports per-user authentication, an Authentication Model section appears under the Authentication section of the connection settings. Select either Shared Authentication or Per-User Authentication.

If this feature is not available for a specific data source and you would like it, contact our support team to request the feature.

The following restrictions apply to this feature:

Only Administrators can toggle a data source between Shared Authentication and Per-User Authentication, but users of all roles can log in to a per-user authentication connection with their own credentials.
Per-user authentication is not supported when using the OData API. To connect a data source to the OData API, you must use shared authentication.
Caching is permitted only with shared authentication, not per-user authentication. See Caching for details.

Getting Started

Data Sources

Explore and Model

Integrations

AI

Security and Governance

Virtual Databases

Operations

Permissions and Access Control

Users

Roles