Enterprise Search: The Architecture Behind the Privacy Promises
Slack's name is a backronym: "Searchable Log of all Communication and Knowledge." With the addition of enterprise search, that log now extends beyond Slack itself. Users can surface permissioned content from connected applications like Google Drive and GitHub directly in Slack search and AI Answers, with more integrations planned.
The engineering team built this feature on the same security pillars that anchor Slack AI:
- External source data is never persisted in Slack's databases.
- External data and permissions stay synchronized with the source system.
- Both users and admins must explicitly grant Slack access, and can revoke it anytime.
- Only the minimal OAuth scopes needed to satisfy search queries are requested.
Built on Slack AI's Security Foundation
Enterprise search inherits its core architecture from Slack AI. Closed-source LLMs run in a dedicated escrow VPC on AWS, ensuring model providers never see customer data and that data never leaves Slack's trust boundary. Rather than training models on customer content, Slack uses Retrieval Augmented Generation (RAG): only the content required for a given task is supplied to the LLM at runtime, and nothing is retained afterward.
Authorization is enforced through the requesting user's Access Control List (ACL), so the LLM only processes data the user can already view in Slack. Generated Search Answer summaries follow the same path—they're displayed to the user and immediately discarded, never written to a database.
A Federated, Real-Time Approach
The central design decision for enterprise search was to avoid indexing external content entirely. Instead of storing copies of Google Drive files or GitHub issues in Slack's databases, the system fetches results in real time via public search APIs from partners, built on Slack's app platform. The client may cache data between reloads for performance, but no external content is persisted server-side.
Freshness Through Real-Time Queries
Because external data is fetched live in response to each query, staleness is structurally impossible—there's nothing stored to become outdated. This real-time model also handles permission changes naturally: if a user loses access to a file in the external system, the next query simply won't return it.
OAuth is the mechanism that ties these pieces together. When a user authorizes Slack to access an external system, the OAuth token scopes define exactly what Slack can do—typically read-only operations. This guarantees enterprise search can never take an action the user didn't approve, and every action it performs is a subset of what the user could do themselves.
Consent and Scope Transparency
Access control operates at two levels. Slack admins must first opt in each external source for use across their organization's search results and Search Answers, and can revoke that access at any time. Individual users then grant their own access before any external source is integrated into their personal search experience—and they can revoke it just as easily.
When Slack requests access to an external source, it asks only for the read scopes necessary to return search results. Both admins and end users see exactly which scopes will be requested before they enable an integration, so there are no surprises about what Slack can do with a connected account.
