Perplexity Enterprise Security: SSO, Sharing Controls, SCIM, and the Request Gap
Perplexity Enterprise gives administrators controls for SSO, SCIM provisioning, public sharing, file downloads, repository changes, attachments, connectors, and incognito retention. These controls govern account access and workspace behavior. A security review should also identify which HTTP AI routes the enterprise controls, because a valid workspace member can still submit sensitive content unless a request-level policy evaluates the principal, payload, and destination before model access.
Perplexity Enterprise gives an administrator a concrete set of security switches: SSO and domain verification, SCIM provisioning, file-download controls, repository permissions, attachment restrictions, public-sharing settings, and connector access. Organization-wide incognito mode adds another switch. Those controls govern who enters the workspace and what members can do around its edges. I want to map the Enterprise Security Hub to the request carrying a query, because a valid member can still send sensitive content through an allowed feature.
TL;DR
- Perplexity Enterprise SSO connects one identity provider to verified organization domains, and invited users can then authenticate through that provider.
- SCIM can provision members and admins from IdP groups for qualifying organizations, with role mapping controlled upstream.
- Security Hub settings restrict public sharing, file downloads, repository changes, and attachments. They also govern connector availability and search-history retention.
- These workspace controls need a separate authorization layer for routed HTTP AI requests, using principal, content classification, destination, and policy version.
SSO establishes the workspace identity
Perplexity's SSO setup guide requires admins to enable SSO, add an organization domain, publish a DNS TXT record containing the verification token, connect an identity provider, and test the flow with an administrator account. Only invited users can sign in through SSO. The current product permits one identity provider per organization, with support handling cases that need more.
That sequence solves two material problems. Domain verification prevents an administrator from claiming a company namespace without DNS control. Federated authentication lets the existing IdP enforce MFA and session controls rather than creating another password store. It also keeps account disablement in the IdP.
The resulting assertion says that a person authenticated as an invited organization member. It does not decide which data that member may submit in a particular query. A finance analyst and a support representative can both hold valid sessions while carrying different entitlements to customer information. Identity is the input to authorization, and the query is where that authorization becomes specific.
A review should preserve the IdP event ID, Perplexity login event, organization membership, and session identifier so an incident team can connect the federated login to later activity. The post-authentication gap begins when that connection exists but the content of a model request receives no policy decision.
SCIM moves lifecycle control to the identity provider
Perplexity supports SCIM-based user management for Enterprise organizations with 50 seats or more, or with at least one Enterprise Max user. The documented setup recommends creating separate IdP groups for admins and members, verifying domains, connecting SCIM, and mapping each group to its Perplexity role.
Once synced, SCIM-managed users cannot be edited in the Perplexity interface. Role changes and removal happen upstream. Perplexity currently distinguishes admin and member groups rather than importing arbitrary groups such as engineering or legal into its own authorization model. Users already belonging to other organizations are excluded from the sync.
That boundary matters because SCIM improves control when people join or leave. It also keeps role changes and assignment in the IdP. Two coarse workspace roles still cannot express that a legal user may search one contract repository while an engineer may query a source-code connector. Fine-grained data permission continues to depend on source-system access and application policy.
The setup guide also documents a sharp failure mode: incorrect group-to-role mapping can remove admin access after synchronization. Test with a backup administrator and record the mappings before making SCIM the only management path. Run deprovisioning drills as a separate check.
Sharing controls close several obvious exits
The Security Hub distinguishes public sharing from organization sharing. A public link is available to anyone who has it. An organization link checks membership before granting access and returns a 404 response to an unauthorized visitor. Admins can disable public sharing for Threads and Pages. The same setting covers Spaces.
One detail deserves a ticket of its own: turning public sharing off does not change content that was already shared publicly. Existing public Threads or Pages keep their links. A rollout therefore needs an inventory and cleanup pass, not just a toggle change. Search for old public links and assign an owner to each one. Revoke the links that no longer have a business purpose.
File controls add another layer by letting admins restrict downloads of files referenced in answers or stored in the organization repository. They can reserve repository changes and thread attachments for administrators. Enterprise Organization Permissions also covers invitations and public content settings in one admin-only panel.
These are meaningful controls around data movement. They govern platform features after a file or thread enters the workspace. The request carrying a pasted paragraph still needs inspection before it reaches a model.
Connector permission is an allowlist, not a per-query entitlement
Perplexity admins can enable or disable connectors across the organization. The documented set includes cloud file services such as Google Drive, OneDrive, SharePoint, Dropbox, and Box, plus application connectors for Gmail, Google Calendar, Outlook, Linear, Notion, GitHub, Asana, Slack, Jira, and Confluence. A default-permissions setting controls how newly launched connectors are treated.
Disabling an unused connector removes an entire access path and should be the default during rollout. An enabled connector then relies on its own authorization and the permissions of the connected account. The Perplexity workspace setting says that the organization permits this integration. It does not say that every member may retrieve every object for every query.
A useful review uses three test users with different source permissions. Ask each one the same question and inspect which files are retrieved and which citations appear. Then inspect how access changes after removal from the source group. The screen should show one query beside three distinct evidence sets. If the connector caches content or permissions, measure the delay between source revocation and changed search results.
Connector governance belongs beside data-owner approval and source-system ACL testing. Request-level policy adds another check on what retrieved content may be sent to a selected model route.
Retention settings change history, not every evidence obligation
Perplexity's data-retention and privacy guide states that Enterprise data is not used to train or fine-tune its models and that agreements with third-party model providers prevent training on Perplexity data. Uploaded files are automatically deleted after seven days. Threads and organization-level data remain until deletion is specifically requested. User data also remains until deletion is specifically requested.
Admins can disable search history, enforcing incognito mode for the organization. The Security Hub says incognito Threads, including attachments, are retained for 24 hours and cannot be shared during that period. They also stay out of history.
Retention settings reduce persistence inside Perplexity. They do not erase evidence held in a webhook receiver, SIEM, connector source, browser cache, or downstream application. Audit requirements may also demand a record that outlives the content itself. Security and privacy teams should define separate retention schedules for query content, generated answers, audit metadata, and policy decisions.
I would treat organization-wide incognito mode as a privacy setting with an investigation tradeoff, then test that tradeoff before an incident. A 24-hour clock is a poor moment to discover that the evidence team starts work on Monday morning.
The query remains a separate authorization event
Take a fully compliant setup: verified domain, SSO with MFA, SCIM-managed membership, public sharing disabled, file downloads restricted, and only approved connectors enabled. A valid member can still type unreleased earnings text into a query or ask an agent to summarize a customer file they are entitled to read but prohibited from sending to an external model.
The workspace controls all work as designed. The missing decision sits on the HTTP request carrying the query and retrieved context. Enterprise policy needs the verified principal, application or agent identity, data classification, intended model route, business purpose when supplied, and policy version. Before the endpoint receives the payload, it records whether the request was allowed or blocked. It also records any redaction.
This is materially different from Perplexity Enterprise DLP, which focuses on content controls. Provider activity evidence also serves a separate purpose from request authorization. Security architecture has to place account governance beside data controls. Decision records also need their own place because these controls are not interchangeable. Signed audit logs for AI requests explains the independent evidence required at that decision point.
The enforcement boundary must stay explicit because a proxy can inspect Perplexity API traffic or other HTTP model calls that the enterprise routes through it. Direct use of Perplexity's hosted browser interface may bypass that route. Browser policy and endpoint controls own that path. SaaS administration remains responsible for the hosted workspace.
DeepInspect
This is the gap DeepInspect closes for HTTP AI traffic routed through its stateless proxy. It evaluates the application-supplied principal and role, classifies prompt content, checks the destination against a versioned policy, and makes an inline decision before the model receives the request. The request may be allowed or blocked, with redaction available when policy requires it.
Perplexity's SSO, SCIM, sharing settings, file restrictions, connector controls, and retention options keep governing the Enterprise workspace. DeepInspect adds identity-bound authorization and a signed per-decision record on controlled API routes. Direct Perplexity browser sessions remain with SaaS administration and browser owners. Endpoint owners also retain responsibility for that path, which keeps the enforcement claim inside the traffic DeepInspect can actually see. Book a technical deep dive at deepinspect.ai.