Atolio resolves group memberships and nested role hierarchies directly from your identity provider, applying them accurately at query time rather than flattening or approximating them. This means permissions behave exactly as they do in your source systems: a user's access in Atolio reflects their actual access in Confluence, Google Drive, Slack, or wherever the content lives. If a user is removed from a Confluence space or a Google Drive folder is re-restricted, that change is reflected in Atolio search results within the next permission sync cycle.
‍
Administrative roles within Atolio (connector configuration, user management, and audit log access) are managed through Atolio's own RBAC layer, integrated with your SSO provider. Admin privileges are scoped to specific functions and do not grant access to indexed content beyond what the admin user is otherwise authorized to see in source systems.

Atolio integrates with your primary identity provider to resolve user identities accurately across all connected source systems, ensuring permission enforcement is correct even when the same person has different accounts or email aliases across tools. Supported identity providers include Okta, Microsoft Entra ID, Google Workspace, and Keycloak – widely deployed in government and enterprise environments given its robust security features and flexibility. Integration is established during deployment via SCIM for directory sync and SAML or OIDC for authentication. The IdP is the authoritative source for user identity and group membership.
‍
Identity reconciliation addresses the common enterprise problem of fragmented identities: the same person often carries separate accounts in Salesforce, GitHub, and Jira with no obvious common identifier. Atolio's reconciliation layer maps these accounts to a single canonical identity using email matching, display name normalization, and connector-specific mapping rules configured during implementation.
‍
Accurate identity reconciliation is required for both permission enforcement and Collaboration Graph accuracy. Misconfigured mappings can result in over-permissioning or under-permissioning. Atolio's implementation team validates all identity mappings before the system goes live.

Atolio syncs permissions continuously and in near-real time, not only at index time. Permission changes in connected source systems are propagated to the Atolio index on a rolling basis, configurable per connector. Most connectors detect permission changes by monitoring change logs, webhook events, or polling source APIs on a scheduled interval. When a change is detected, the affected document's ACL is updated in the Atolio index without a full re-index of the document's content. A user removed from a Confluence space sees that change reflected in Atolio results within the configured sync window.

Yes. Atolio gives administrators granular control to exclude specific content from being indexed, at the source level, content-type level, or document level. Exclusion options include: entire sources or sub-containers (a Slack channel, a SharePoint site, a Jira project), content types by MIME type or file extension, and content matching specific labels or metadata fields in the source system, such as a Confluence label marking a page as draft-only or a Google Drive sensitivity label indicating PII.
‍
Atolio supports sensitivity label integration for organizations using Microsoft Purview or Google Workspace label governance. Documents with specific sensitivity classifications are automatically excluded from the index based on those labels, without manual curation.
‍
Exclusion rules are enforced at ingestion. Content matching an exclusion rule is never written to the index and is not searchable by any user. This is distinct from permission-based suppression, where content is indexed but only returned to authorized users.

‍Atolio does not grant search access to content beyond what each user is already authorized to see in the source system. Search is a discovery surface, not an access escalation mechanism. The core safeguard is permission enforcement at the index layer: if a document is restricted in Confluence, it is restricted in Atolio. Users cannot retrieve content through search that they could not retrieve by going directly to the source.
‍
For organizations with strict data classification requirements, sensitivity label integration and content exclusion controls let security teams define a clear perimeter around what enters the index at all. Content that should not be broadly discoverable, even by technically authorized users, can be excluded from ingestion entirely.
‍
Beyond technical enforcement, source-level scoping lets administrators restrict which connected sources are visible to which user populations. A Finance-only data source can be configured so only Finance group members see it in search, regardless of their broader Atolio access.