Does Slack use customer data to train LLMs?

Slack states in its AI principles that customer data is excluded from LLM training. Slack also says its LLMs run inside Slack's cloud environment and model providers lack access to customer data. Those statements describe managed AI in Slack. A customer-built app that sends content to an external provider uses the customer's architecture and provider terms.

Do Slack permissions apply to native AI answers?

Slack says native search and summarization fetch content using the requesting user's access-control lists. Test that claim in the deployed workspace with named accounts. Channel membership and connected sources determine the available context. App configuration also affects it. Preserve the sources shown to each test user.

Can Slack DLP remove information from an AI summary?

Slack's engineering article says summaries derived from a source message are invalidated when DLP tombstones that message. Support for the Slack AI action and the configured DLP path determine the exact behavior. A controlled test should connect the source message and DLP action to the summary state and audit event in one case record.

Can an external gateway inspect Slackbot and native summaries?

Slackbot and native summaries are inside Slack's managed environment. Search Answers is there too. An external gateway sees a request only when a customer-controlled Slack app or agent deliberately routes its authenticated HTTP call to an external LLM through that gateway. The distinction should be explicit in the architecture diagram.

Slack AI Security: Native Controls and the Custom App Boundary

A Slack prompt can follow two materially different paths. Slackbot and Enterprise Search are inside Slack's environment. Slack also manages summaries and other AI functions. A customer-built app can receive a Slack event and send an authenticated HTTP request to an external LLM. The composer icon may look similar on both paths. The enforcement points are different. I want to map those paths before discussing controls because Slack AI security depends on the component retrieving the context and the location of inference. It also depends on which identity survives the handoff.

TL;DR

AI in Slack uses the requesting user's existing access when retrieving content for native search and summarization.
For supported Slack tools, Slack AI Guardrails include safety instructions, context handling, URL filtering, output validation, provider mitigations, and query checks.
Slack platform controls such as DLP, retention, audit logs, legal holds, and Enterprise Key Management govern workspace data inside Slack.
A separate gateway can govern a custom app's external model call only when its authenticated HTTP LLM traffic is deliberately routed through that gateway.

Native AI uses Slack permissions

Slack's engineering account of secure and private Slack AI says native search and summarization retrieve content under the requesting user's access-control lists. A user receives answers based on messages and files that the same user may already view. That mechanism means Slack's permission graph is part of the inference path.

Test it with two named accounts in one private channel that contains synthetic data. Give the first account access and keep the second outside. Submit the same native search request under both identities, then capture the visible sources. A screenshot with the private channel name blurred for one account and absent for the other gives the reviewer direct evidence of permission-aware retrieval.

Identity is still important in custom apps. A bot token identifies an installed application. The event payload and application state must preserve the employee or agent behind the request if an external policy decision is expected to use that identity.

Slack AI Guardrails protect managed Slack AI

Slack's AI principles and guardrails page describes how Slack AI Guardrails apply across its managed AI. The safeguards include safety instructions, context engineering aimed at reducing prompt-injection risk, URL filtering, output-format validation, model-provider mitigations, and Content Safety Filters that evaluate queries before supported tools such as Slackbot and Search Answers process them.

Place the scope beside each Slack capability in the architecture inventory. Create separate rows for Slackbot and Enterprise Search. Add Agentforce in Slack, summaries, translations, Marketplace agents, and customer-built apps as distinct rows. Identify the operator and data path rather than assigning the same control set to every row.

I think any Slack AI review that treats a Marketplace agent and a custom bot as the same security surface as Slackbot deserves to be sent back. Similar user interfaces obscure different trust boundaries. The review must identify the component that retrieves content and the service that receives the resulting model request.

Slack data controls are part of the design

Slack's security documentation lists encryption in transit and at rest, Slack Enterprise Key Management, audit logs, native DLP, support for third-party DLP, retention, legal holds, and eDiscovery. These controls govern workspace data and administrative events. Their relevance varies by plan and configuration. The path through Slack also changes their relevance.

The engineering article adds useful behavior for native AI outputs. Slack says search answers and conversation summaries are ephemeral where possible. When DLP tombstones a source message, derived summaries are invalidated. That connection matters because generated content can otherwise preserve information after the original record is restricted.

A review should test the full lifecycle with synthetic text. Post the text in a controlled channel and generate the supported summary. Apply the configured DLP action, then inspect the summary again. Preserve Slack audit evidence and the case identifier. This exercise validates Slack's native path. It also establishes what evidence exists before a custom application sends any content outside the workspace.

Custom apps create a separate model route

A customer-built Slack app usually receives an event or command and resolves the user and channel context. It then builds a prompt and calls a model endpoint over HTTP. Each step introduces a policy input. The originating Slack user, workspace, channel, bot installation, requested function, data classification, and model destination all affect the decision.

Map the exact path. Start with the Slack event identifier and signing verification. Resolve the user and channel under Slack's APIs. Record the application identity and model hostname. Add the policy version and decision before the prompt leaves the service.

The post-authentication gap is present when a genuine user invokes an authorized bot but the resulting prompt exceeds that user's approved purpose or model route. Workspace access answers which source material the person may view. Request policy determines which classified content that person may send to a specific LLM for a specific action.

The control matrix needs two columns

Split the review into native and customer-controlled paths.

Native AI in Slack: Slack owns inference infrastructure and AI Guardrails. Workspace administrators configure identity, permissions, retention, DLP, and Enterprise Key Management, along with the audit functions Slack supports.
Custom application processing: the application owner verifies Slack requests, resolves the originating identity, restricts channel access, constructs the prompt, and chooses the destination model.
Routed external inference: security can place an independent policy point on the authenticated HTTP LLM request when the custom application is configured to use it.
Endpoint and credential response: endpoint security, secrets management, Slack administration, and incident response retain their existing responsibilities.

This split prevents a category error. Slack's statements that customer data stays protected inside its managed AI environment do not automatically extend to an external model selected by a customer-built bot. In the other direction, a gateway on the custom app's HTTP route has no visibility into Slackbot or native summaries. Search Answers is also inside Slack.

Zero trust for AI requires a policy decision tied to the authenticated principal and the content of the request. For custom Slack apps, that decision is after the app resolves the Slack identity and before it sends the model call.

A production test uses one synthetic message

Create a private test channel with two accounts that have different permissions. Post a fictional contract clause labeled INTERNAL-TEST. Ask Slack's native AI to summarize the channel under each account. Then invoke the custom app under the authorized account and trace its event ID through the application, request-policy record, and external model response.

The evidence package should contain the workspace and channel identifiers, originating user, app installation, Slack event ID, prompt classification, destination model, policy version, and outcome. Apply the configured DLP action and recheck supported native summary behavior. For the custom path, confirm that a denied request stops before model inference.

Keep the claims bounded. Slack ACLs and native guardrails govern managed AI in Slack. A routed HTTP policy point governs only the custom app traffic that crosses it. Bot-token theft and compromised endpoints require their own controls. Slack administration and Slack's internal infrastructure do too.

DeepInspect

This is the gap DeepInspect closes. DeepInspect is a stateless proxy for routed authenticated HTTP AI traffic between users or agents and LLM endpoints. A customer-built Slack app can send its external model request through DeepInspect after the application validates the Slack event and supplies the originating user or agent identity.

DeepInspect evaluates that identity with prompt classification and destination under versioned policy. It can allow or deny the routed request. It can also redact the request and produce a signed, tamper-evident decision record. Slackbot, native summaries, Search Answers, Slack ACLs, workspace DLP, retention, and endpoint security are outside this interception boundary. Book a technical deep dive at deepinspect.ai.