Permissions in the PARAG connector
PREREQUISITES: This capability is available in Sitefinity Cloud with version Sitefinity 15.4.8628.
This article applies to AI capabilities powered by the Progress® Agentic RAG connector (PARAG) - such as AI Search and AI Assistant widgets.
When Sitefinity content is indexed in PARAG, the connector maps Sitefinity's permission model to PARAG's access_groups security mechanism. This ensures that AI-powered search results respect the same access rules that govern content visibility in Sitefinity CMS.
For a general overview of how permissions work in Sitefinity CMS, see Permissions.
IMPORTANT: When making third-party calls to the knowledge box, make sure the
securityfield in the request body is populated with an access group. This ensures that the security lookup phase is performed, and content permissions are respected.
How permissions are mapped
The PARAG connector respects only the permissions for general CRUD operations defined in Sitefinity CMS:
| Sitefinity permission | Enforced by PARAG |
|---|---|
| View | Yes |
| Create | Yes |
| Modify | Yes |
| Delete | Yes |
| Change owner | No |
| Change permissions | No |
| Unlock | No |
In the NucliaDB API, permissions are represented through the security.access_groups property of each resource. The principal IDs in Sitefinity CMS (users and roles) are mapped to access group identifiers sent to PARAG.
Publicly visible items
When a content item has no access restrictions, that is, at least one of the CRUD permissions is granted to Everyone, the connector sends an empty access_groups array to PARAG. This signals that the resource is publicly accessible and is returned to all users in search queries.
IMPORTANT: If any single CRUD permission is set to Everyone, the item is considered publicly visible, even if the other CRUD permissions are restricted to specific roles such as Administrator only.
Role-based access groups
When a content item has permissions restricted to specific roles, the connector collects the principal IDs of all roles that have any CRUD permission granted and sends them to PARAG as access_groups.
EXAMPLE: If the View permission on an item is granted to both the Backend users role and the Administrators role, PARAG sends both role identifiers as access groups for that resource.
All PARAG search and ask API calls support a security parameter that accepts the access_groups of the currently authenticated user, allowing PARAG to filter results so that only resources matching the specified groups are returned.
Permission synchronization
Permissions are synchronized to PARAG automatically through scheduled tasks. You do not need to manually trigger an update.
Permission inheritance
Child items inherit permissions from their parent by default. When you change permissions on a parent item, child items that are set to inherit are also updated automatically. Child items with manually overridden permissions are not affected by parent permission changes.
Search filtering by permissions
All PARAG search operations are always filtered by the View permission.
Search results only include resources that the current user is authorized to view, based on the access groups sent with the search request.
Module Builder field-level permissions
If you use Allow permissions per field in Module Builder and any field-level view restrictions are active, the item is treated as not publicly visible, even if the item-level View permission includes Everyone.
In this case, the connector sends the applicable access groups to PARAG. Users who do not belong to the required access groups will not see the item in search results.
Known limitations
The following behaviors and limitations apply to the Progress Agentic RAG permissions integration:
Administrators always see all items
Administrator users always have access to all indexed content in PARAG search results, regardless of the access groups configured on individual resources.
Deny permissions are not enforced
Sitefinity's ability to explicitly Deny a permission to a user or role is not respected by the PARAG connector. Deny permissions are not propagated to PARAG. Only Allow permissions are taken into account when constructing access groups.
NOTE: This differs from the standard Sitefinity behavior where an explicit Deny always overrides an explicit Allow. When using AI Search capabilities, do not rely on Deny permissions to restrict content visibility.
Owner role is ignored
The Owner role in Sitefinity is not taken into account in PARAG. Content ownership does not grant any special search visibility.
Suggestions do not support permission filtering
Suggestions do not support permission filtering. Do not rely on AI suggestions as a secure content discovery mechanism when strict permission enforcement is required.
Change owner, Change permissions, and Unlock are not respected
Only the View, Create, Modify, and Delete permission types are mapped to access groups. Actions such as Change owner, Change permissions, and Unlock have no effect on what is indexed or visible in PARAG.