How Slack Keeps MCP Secure

The enterprise AI landscape is changing fast. Here’s what your security team needs to know about how Slack built MCP with trust at the foundation, not bolted on after the fact.

What is MCP, and why does it matter for your enterprise?

Model Context Protocol (MCP) is an open standard that lets AI agents connect to external tools and data sources without custom, one-off integrations. Think of it as USB for AI. One standardized interface that any tool can plug into.

For enterprises running Slack, this means Slackbot can now act as a central AI orchestrator of work. It can retrieve a Figma design, check a Jira ticket, pull up a DocuSign contract for signature, or query Salesforce CRM data, all in a single conversation, without users ever leaving Slack.

That kind of reach raises the question every CIO should ask first: how does this work securely at enterprise scale?

The short answer is that the MCP Client is built on the security infrastructure Slack already runs. There is no new trust model to evaluate. It’s an extension of the same app framework, admin controls, and data governance your organization relies on today, including the compliance certifications that governance rests on.

The architecture: how the MCP Client works in Slack

The Slackbot MCP Client uses remote HTTP/SSE transport only. Slackbot connects to MCP servers hosted on external infrastructure over HTTPS. It never spawns local processes with access to user devices or file systems. That’s a deliberate design decision, and it eliminates an entire class of local-access security risks before they can exist.

Every MCP server enters your Slack environment through three gates:

• The developer registers. A partner or internal developer declares MCP server endpoints in their Slack app manifest, alongside a new mcp:connect OAuth scope.
• An admin approves. The app goes through Slack’s standard App Directory review and admin approval process. Admins see exactly which MCP server domains are being requested before approving. No server enters a workspace without explicit admin sign-off.
• The user connects. Once an app is approved, users see its MCP connectors in Slackbot. Connecting triggers an OAuth flow, and the resulting token is stored in Slack’s credential infrastructure.

One detail matters more than it sounds like it should: MCP servers are not a new top-level entity in Slack. They’re a capability of a Slack app. All of the distribution, marketplace review, admin approval, permissions, and lifecycle management your team already knows carries forward. No new playbook required.

That same existing posture carries the compliance side too. Because the MCP Client is an extension of the existing Slack platform, it operates under Slack’s existing certification portfolio, the same frameworks your security team has already evaluated:

• SOC 2 Type II and ISO 27001 cover the audited infrastructure MCP runs on, including access management, availability, and confidentiality.
• GDPR and HIPAA are covered under your existing Slack DPA and BAA. No addendum or separate agreement needed.
• FedRAMP is available via Slack Government for public sector customers.

Full documentation is available at the Slack Trust Center (slack.com/trust).

Authentication: three models, all built for enterprise

Slack supports three authentication strategies for MCP server connections, each suited to a different deployment scenario.

• OAuth 2.0 with PKCE is the primary model for third-party MCP servers. Slack brokers a standard OAuth 2.0 flow with the external service and issues per-user tokens that admins can centrally revoke. PKCE support means even desktop clients authenticate without exposing tokens to interception.
• Slack identity-based auth serves internal or Slack-first MCP servers. Slack sends signed requests with user context embedded, and the MCP server verifies the signature and maps it to its own user model. There’s no separate OAuth flow, and existing user mappings are preserved.
• Static headers are available for internal and testing use only. These are workspace-scoped tokens without per-user identity, and they’re not recommended for production deployments that handle sensitive data.

Across all three models, every MCP call is made as the authenticated Slack user. Permissions, field-level security, sharing rules, and profile policies all apply at the source system, exactly as they would if that user opened the tool directly.

Admin controls: your organization stays in charge

Admins have granular control over the entire MCP surface in their workspace:

• Off by default. No server is available to users until an admin explicitly enables it through the standard app approval workflow.
• Domain-level visibility. Admins see exactly which MCP server domains an app requests before approving. Adding a new server from a different domain requires re-approval.
• Connector management. Users can view, connect to, and disconnect from individual MCP servers in Slackbot. Admins retain org-level override controls.
• Write tools sit behind a human. The initial release activates read-only tools. Write and delete tools will require explicit, per-action user confirmation before Slackbot proceeds. That friction is deliberate. It keeps humans accountable for consequential actions.
• App-level ACLs are GA. Admins can control the access to MCP server via App level ACLs. Coming soon – granular access control lists will let admins scope MCP server access by user, group, or role rather than all-or-nothing.

 

Data privacy and safety

AI in Slack, including Slackbot’s MCP-powered capabilities, operates under one consistent set of data principles. Customer data is never used to train LLMs, and prompts and outputs are not logged or visible to LLM providers. Existing permissions are respected at the time of generation, Slack personnel have zero internal access to your data, outputs are retained only as long as needed, and you keep ownership of your output data. Enterprise Key Management, International Data Residency, Discovery API requirements, legal holds, and your DLP and retention policies all extend automatically to AI-generated content, including MCP activity. Every AI action generates an audit log capturing the acting user, the action taken, and the relevant context.

On top of that governance layer, Slack runs a multi-layered safety framework on every AI interaction, also covering all MCP-powered Slackbot interactions. These safety measures include context engineering to reduce prompt injection risks, special handling for AI-generated URLs to prevent phishing attacks, output format validation, and real time content safety filters for risk-based blocking of malicious or harmful inputs.

Slack as the governance layer for your entire AI stack

The value here isn’t just how Slack secures Slackbot. It’s what Slack Enterprise+ enables across your whole AI tooling landscape. When users interact with AI tools through Slack, your existing enterprise controls become the universal governance layer:

• DLP policies govern the prompts and outputs shared by AI tools and agents, including Slackbot interactions.
• Audit logs capture Slackbot usage and third-party AI usage whenever MCP tools interact with Slack data or take actions in Slack.
• Full data export and search query export give compliance and security teams visibility into Slackbot conversations and the exact prompts teams are running.

Instead of configuring separate governance in every AI tool your organization adopts, Slack becomes the single place where those controls are enforced consistently. For a security team managing a growing portfolio of agentic tools, that’s a real architectural advantage.

 

Bottom line for the CIO

MCP in Slack isn’t a new security surface. It’s an extension of the security model you already operate, backed by the certifications already covered above. The admin approval gates, OAuth-based authentication, per-user permission enforcement, audit logging, DLP integration, and data residency controls all carry forward.

What’s new is the capability. Your organization’s AI assistant can now reach across every tool in your stack and take real action on behalf of your people, without leaving the secure environment you’ve already invested in building.

The question isn’t whether MCP is secure enough for your enterprise. It’s whether your enterprise is ready to work the way your people already want to.

Additional resources

• Slack Trust Center — slack.com/trust
• Guide to the Slack MCP server — slack.com/help