AI agents are powerful, but they require access to company data to be effective. This creates a natural tension: how do you unlock the value of AI without compromising security, privacy, and trust?

Our goal is to build the right platform experience to enable powerful AI use cases without sacrificing data privacy and security. After our initial announcement about our Real-Time Search API, we heard from our developers and partners who were concerned about data control and ability to build AI apps for their own organizations. We’ve incorporated that feedback into how we are building RTS and evolving our platform.

And with this post, we’re continuing that conversation. We want to be transparent about our approach and get your input along the way, as we build a platform that provides both utility and security. 🧰 🤝 🔐

Secure from the start

Building a secure application isn’t about a final checklist; it’s a set of practices you integrate from the very first step. Here are the core principles for building trusted apps on Slack.

Secure Your Secrets

It’s tempting to drop a token right into your code to get things working, but secrets should never be part of your codebase. A better approach is to manage secrets based on your development environment:

• For Development: Use local environment variables (.env files) to store your app’s tokens and keys. Crucially, ensure your .gitignore file includes .env to prevent committing credentials to your repository.
• For Production: Use a dedicated secrets management solution. Services like GitHub Actions Secrets, AWS Secrets Manager, or HashiCorp Vault are the industry standard for securely injecting credentials at build or runtime.

Once your app’s credentials are secure, the next step is to ensure it only has access to the data it absolutely needs.

Embrace the principle of least privilege

An app should only have the minimum permissions required to do its job. In Slack, this means being thoughtful about the scopes you request in your app’s manifest.json file. We recommend creating a clear, documented scope policy for your organization:

• Always Allowed: Low-risk scopes for core functionality, like commands and chat:write.
• Requires Approval: Scopes that access more sensitive data, like channels:history or users:read, which should trigger a manual review.
• Restricted: High-risk scopes like admin that are reserved for only the most trusted internal applications.

Defining these policies is a critical step for governance, and you can make them the default for all new development by using custom templates.

Standardize with custom templates

To enforce these practices at scale, you can create standardized app templates. The Slack CLI supports creating apps from any GitHub repository, allowing you to build a starter template with your security policies baked in from the start:

slack create my-new-app --template=your-org/secure-app-template

This ensures every new app begins with your pre-approved minimal scopes, secret management guidelines in the README, and any other security guardrails you establish.

Automate deployments with CI/CD

A consistent deployment process reduces manual errors. Use deploy hooks in your .slack/hooks.json file to run scripts when you deploy your app. This hook can push your code to your hosting provider, ensuring your app’s manifest settings are updated in Slack before the new code goes live. By integrating the slack deploy command into a GitHub Action, you create a clear, consistent CI/CD process for every Slack app in your organization.

Implementing these developer-focused practices creates a strong foundation, making it easier for administrators to manage the application ecosystem at scale.

Governance at scale: Administrator controls

Security is a partnership between developers and administrators. Slack provides a full suite of tools for admins to govern the app ecosystem with confidence.

Require app approvals

The most critical first step for any administrator is to require approval for all new app installations. This creates a central checkpoint to enforce security policies and prevent unvetted apps from being installed.

Curate your app ecosystem

Once approvals are required, admins can proactively manage the app landscape. You can pre-approve trusted, low-risk apps, allowing members to install them without friction. You can also restrict apps that don’t meet your security standards, preventing them from being installed or requested.

Automate the approval workflow

To manage requests efficiently, you can rate permission scopes based on risk level (“Low,” “Medium,” “High”). This allows you to create rules that automatically approve apps requesting only low-risk scopes, while flagging those with higher-risk scopes for manual review.

Audit your workspace with automation

The Slack CLI can be combined with simple scripts to perform bulk operations, like auditing the scopes of every installed app in your workspace. This allows you to programmatically find apps that may be out of compliance with your policies and gives you continuous visibility into your workspace.

These administrative controls provide the necessary oversight to maintain a secure environment, which is complemented by new, secure-by-design data APIs at the platform level.

Slack’s New Data Connectivity API & MCP Initiatives

Instead of leaving the burden on you to aggregate context from Slack data and process it for use by LLMs, our new Real-time Search API (RTS) is designed to bring compute to the data, securely. We’re also releasing two Model Context Protocol (MCP) servers in the near future. One for taking action on your behalf directly in Slack, and one for assisting with the Slack app development and management lifecycles.

Before diving into the new APIs, I want to take a second to directly address our recent policy updates. To better protect all customers from bulk data exfiltration by unvetted third-party applications, we updated rate limits for certain APIs on apps distributed outside the official Slack Marketplace. Apps on the Slack Marketplace must meet rigorous security requirements to protect your data, but apps not on the Slack Marketplace don’t go through this process so we can’t ensure their data security posture.

However, I also want to make one thing crystal clear: Customers building custom applications for internal use have no restrictions on accessing their Slack data, as has always been the case. These changes are about ensuring a secure and responsible ecosystem while guaranteeing you always have full control of your data. 💜

The Real-time Search API (RTS)

The RTS API allows an app to search Slack messages and files in real-time. Its primary benefit is that your data is accessed where it lives. There is no need for data duplication or bulk exports, reducing your risk. The API is also permission-based, respecting user-level access rights, so an agent can only find what the user running the query is allowed to see.

We’re opening up the API to a small group of partners while we stress test and refine this functionality.

MCP & Slack

MCP provides a standardized way for AI agents to interact with Slack. To support the full lifecycle of an application, we are developing two distinct MCP servers: one to assist developers and admins with building and managing apps, and another to help end-users get work done with those apps.

#### For Builders & Admins 
This server is designed to enable AI-driven development and administration workflows by integrating directly with Slack’s platform resources and the CLI. It meets developers and admins in the tools they already use, like Cursor, Claude Code, and GitHub Copilot. This server doesn’t require the user to be authenticated for every action; instead, the server calls the underlying Slack CLI on the user’s behalf, which allows the server to rely on existing secure infrastructure.

#### For End-Users 
This server enables AI-driven workflows for Slack users by allowing AI apps to take action on the user’s behalf. For example, an AI app could create a canvas from deep research results gathered from other tools. It’s designed to meet users where they are, in applications like Claude Desktop, ChatGPT, and Glean. This server requires the user to be authenticated to perform actions in Slack.

While these platform-level APIs provide secure access to data, managing the context derived from that data efficiently is equally critical.

A practical approach to context management

While we build more advanced context capabilities into the platform, you need a production-ready pattern today. The biggest bottleneck for agents is rebuilding context on every message, which is slow and expensive.

The N+1 context problem

As a conversation thread grows, fetching the entire history on every new message to maintain context is inefficient. This leads to high latency and racks up API and token costs, especially in long-running, complex discussions.

Reducing compute and latency with persistent context objects

Instead of rebuilding, you can maintain a running summary, or “context object,” that is updated with each new message. This object is stored and retrieved using the thread’s timestamp (thread_ts) as its unique key. This approach, common in production AI systems, turns an expensive “read-all” operation into a lightweight “read-one, write-one” pattern. With each event, your app retrieves the context object, processes only the new message to update the summary, and stores it back.

Optimizing for token limits

This pattern also helps manage LLM token limits. You can build a prompt that prioritizes the most critical information—like key decisions and action items—and then fills the remaining space with recent message summaries or extracted entities. This ensures your agent always has the most important context, even if the full history is too large. This approach dramatically reduces API calls, delivers faster response times, and lowers token costs.

This pattern not only solves a critical problem today but also aligns perfectly with the future direction of our platform, as we’ll see in the roadmap.

What’s next on the roadmap

Our commitment to data privacy and security is never-ending. Here’s a sneak peek into some of the work we are doing now to deepen the Slack Platform security controls.

We’re working on an Admin app installation refresh and a complete revamp of the app settings dashboard. These projects will make it easier for administrators to manage and govern the apps in their organization at scale. We’re also addressing your feedback on transparency with projects like a Rate Limit Dashboard, giving you clear visibility into your app’s API usage. Finally, the Thread & Channel Metadata & Data Stores we’re building are designed with security at their core, ensuring that as you gain more powerful ways to manage context, you also have the controls to do so safely.

These roadmap items, coming sometime early next year, represent our ongoing investment in making the Slack platform both more powerful and more secure for everyone.

Building the future on a foundation of trust

We’ve covered Slack’s multi-layered approach to security: secure developer practices, powerful admin governance, and secure-by-design APIs. These tools and guardrails provide the foundation you need to build the next generation of AI-powered apps on Slack to meet privacy and security standards in this AI era.

Stay tuned for our next post, where we’ll take these principles and apply them to the complete development journey, from initial idea to a fully functional app.