How to Block Sensitive Slack Channels from AI Agents with an MCP Gateway Rule
Your engineering team already runs AI agents on MCP, and now other departments want the same. Then Slack comes up, and the questions start. Can an agent read the leadership channel? Will it remember what it read and repeat it during an unrelated task? Can access be limited per channel, or only per server and tool?
Slack’s scopes and MCP tool settings can’t answer those questions, because they stop at the conversation type or the tool, not the channel. MCP Manager’s gateway can. A custom rule engine, a webhook you build and host, inspects Slack tool calls and results and passes, rewrites, or blocks each one before it reaches the AI client. That lets you block specific Slack channels from AI agents without disabling the Slack MCP server entirely.
This guide covers how the setup works, how to build and test it, and why rules need to be in place before the first user connects.
Key Takeaways
- Slack’s MCP server acts with each user’s own token, so an agent can read whatever that user can read within the scopes the Slack app requests.
- Slack scopes and MCP tool controls stop at the conversation type or the tool, not the channel.
- An MCP gateway sits between the AI client and Slack, so every tool call and result can be inspected before either side receives it.
- MCP Manager’s gateway can hand those calls to a custom rule engine, an HTTPS webhook that returns pass, modify, or block. It can do so on the request leg (the call heading to Slack), the response leg (the result heading back), or both.
- The engine is code that you build and host, which gives full control over the policy but means your team owns the code.
- For Slack messages, channel-level control takes two rules. One blocks requests that name a disallowed channel, and one strips disallowed channels from search results.
- An MCP gateway with no rules applies no content-level policy, so rules must be built, applied, and tested before the first user connects.
Why RBAC Alone Doesn’t Work for MCP Connectors
Slack authorizes people, and an MCP connection inherits that authorization wholesale. That leaves gaps at the channel level, for several reasons.
Agents Inherit the Full Reach of the Connected User
Slack’s MCP server runs on a per-user token minted when each person approves the app, so every tool call carries that person’s access, limited only by the scopes the app requests. A person opens one channel at a time. An AI agent answering one prompt can run a search across every channel, private channel, and DM those scopes cover.
One Prompt Can Pull From Channels Nobody Intended
A prompt like “summarize what the team discussed about the Henderson account” can return hits from several places:
- A leadership channel the user joined for one thread
- An HR channel discussing compensation
- A support channel where someone pasted a customer’s email address
The user legitimately belongs to all of them. None of them belongs in the answer.
Injected Instructions Ride Along with Channel Content
A person reads a message on purpose. An agent reads whatever a prompt sends it to, and the text of a message is content the model processes. A message that contains instructions, whether pasted by accident or planted deliberately, can steer an agent that has other tools connected.
Slack’s own documentation advises care when using other MCP servers alongside the Slack MCP server, because each has its own security characteristics. Keeping an agent out of channels it has no reason to read shrinks what such content can reach.
Memory Carries Restricted Content Into Unrelated Tasks
AI clients add a second exposure path: persistence. Claude can generate memory from chat history and search past chats in new conversations, and for Team and Enterprise plans the organization-wide memory setting is on by default. Once restricted content lands in a conversation, it is beyond any gateway’s reach and may resurface during an unrelated task. Enforcement has to happen before the tool result reaches the client.
Slack Scopes Stop at the Conversation Type
Slack’s permission model can’t express a per-channel boundary. Its MCP user scopes are granted per conversation type, such as channels:history for public channels and groups:history for private ones. You can keep an agent out of every private channel, but not out of #exec-staff alone.
The Binary Problem with Native MCP Server Controls
Native server controls decide whether a tool is available, not what the tool is allowed to touch. A server can be switched on or off, and a gateway can trim its tools: MCP Manager’s feature provisioning hides individual tools. The 2026-07-28 MCP specification adds Mcp-Method and Mcp-Name headers, so gateways can authorize on the tool name without parsing the body.
The channel, however, is not part of the tool name. It sits in the payload, in params.arguments on the request and in the result on the response. Allowing a “read channel” tool therefore allows it for every channel the token can read. A policy like “allow channels A, B, and C but block D, E, and F” can only be enforced by inspecting each JSON-RPC body.
That leaves two bad options. The Slack MCP server can be blocked, which gives up the productivity gains. Or it can be enabled, which means agents reach everything the connected user can see.
A custom rule engine adds a third option: enable the server, and enforce per-channel policy at the gateway before any data reaches the AI client.
Want to see how an MCP gateway controls what AI agents can reach? Book a demo with MCP Manager and explore gateway rules, provisioning, and logs with the team.
What a Custom Rule Engine Is and How the Gateway Calls It
A custom rule engine is an HTTPS webhook you build and host. You register it in MCP Manager and attach it to a gateway rule. Each rule fires on the request leg, the response leg, or both. On every tool call that reaches that point, the MCP gateway sends the message to your webhook in an HTTP POST request and acts on the verdict before forwarding.
To build one step by step, follow the tutorial for your first custom rule engine.
How the Gateway Routes Slack Traffic Through a Rule Engine
Your AI client (Claude, ChatGPT, Cursor, or an agent you build) connects to an MCP Manager gateway, which forwards tool calls to the Slack MCP server under each user’s brokered identity. When a tool call or result reaches a rule’s detection hook, the gateway sends it to your engine and waits for a verdict. The gateway applies that verdict inline, so the client only receives what your engine allowed.
Custom engines share a rule framework with the built-in regex and Microsoft Presidio methods and the Amazon Bedrock and Lakera Guard templates. Unlike in-process regex, a custom engine adds an external round trip per call, bounded by a timeout and a failure mode. Rules apply to tools/call traffic only, not to prompts or resources.
What Your Endpoint Receives and Returns
The gateway sends two objects. metadata identifies the call, including userEmail, gatewayGuid, serverGuid, toolName, direction, requestId, and a sessionId that matches your logs. body is the JSON-RPC message: arguments under body.params.arguments on the request leg, returned content under body.result on the response leg.
Your endpoint returns HTTP 200 with one of four verdicts:
- Pass: the message continues unchanged.
- Block: the gateway returns a JSON-RPC error instead.
- Modify: the gateway forwards your rewritten JSON-RPC response.
- Error: the rule’s failure mode decides. Custom engines default to Block.
Each verdict can carry a comment, written to the rule_engine_comment log column. A useful comment states what was decided and why, for example Blocked: channel C0123456789 is not on the allowlist on the request leg, or Removed search results from 2 channels outside the allowlist on the response leg. In the logs, these comments show which rule acted and on what.
Securing Your Rule Engine
Your engine should only accept calls from MCP Manager. To make sure of that, add a secret to the engine’s settings, such as a bearer token, which MCP Manager sends with every call and your service checks before doing anything else. As a second layer, allow only MCP Manager’s published static outbound IP address in your firewall, so requests from anywhere else never arrive.
By default, your engine sees the message and the calling user’s ID and email, but not that user’s Slack access token. Turn on header forwarding only if the engine needs to call Slack as that user, for example to look up a channel. It passes the user’s access tokens to your engine, so it should be enabled only for a service you fully control.
One Endpoint or Many?
Start with one engine and route internally. Rules have no per-server or per-tool selector, so an engine sees every tools/call on its gateway and should pass anything whose serverGuid and toolName it wasn’t written for. Each engine on a hook adds its own external round trip.
Separate engines are easier to debug in isolation, so split later if complexity demands it. Until then, write the channel ID, tool, and policy into every comment so the logs show which branch fired.
Step-by-step: Building Slack Channel Controls
Channel-level control requires two rules on opposite legs of the tool call. One inspects requests (what the agent asks Slack for). The other inspects responses (what Slack sends back).
Before You Start
The Slack MCP server only accepts a registered Slack app. Slack allows MCP for apps published in the Slack Marketplace and for internal apps built for one organization. Unlisted apps are rejected. The app also needs the user scopes its tools require, and workspace admins approve and manage MCP client apps. MCP Manager connects with the app’s client ID and client secret. The Connect Slack guide covers the full setup.
Step 1: Identify the Channels You Want to Block
Collect channel IDs, not names, because IDs survive renames. In Slack, open the channel, select View channel details, and copy the ID at the bottom of the panel.
Then choose a list type:
- An allowlist fails closed: new channels, DMs, and group DMs stay unreachable until approved.
- A blocklist fails open: it is easier to maintain when a few channels in a large workspace are sensitive, but every new sensitive channel is exposed until someone adds it.
For regulated content, start with an allowlist. New channels, DMs, and group DMs then stay unreachable until someone approves them.
Step 2: Build the Request-Direction Rule
This rule fires before a tools/call reaches Slack. Tools that act on one conversation, such as reading a channel or thread, sending a message, or adding a reaction, take that conversation as an argument. The engine reads it from body.params.arguments, checks it against the list, and returns block if the channel isn’t allowed. The call never reaches Slack.
Three details keep the rule reliable:
- Tool names: Names and arguments come from Slack’s own tool list, in the server’s tools/list response or the live tool preview under feature provisioning. Examples and older articles go stale when Slack updates its server, and a rule built on remembered names stops matching without any error.
- Missing channel argument: A call that should name a channel but doesn’t is blocked, since an unverifiable call defeats the purpose of the rule.
- Read versus write: Blocking the tools that post or create content in a channel, while leaving the read tools open, gives an agent read-only access to that channel. The tools involved should be confirmed in the live tool list.
A blocked call returns a JSON-RPC error to the client. For a clearer message, the engine can return a modify verdict with a custom error body, for example “This channel can’t be accessed through this assistant.”
Step 3: Build the Response-Direction Rule
Search bypasses the request rule. Slack’s search tools take a query, not a channel, and return matches from every conversation the token can read. A search for “Henderson account” might return five channels, two of them restricted.
The response-direction rule drops matches from disallowed channels and returns a modify verdict, so the agent still gets the legitimate results. The channel allowlist recipe shows example handlers for both legs. They are a starting point, and their payload shapes need to be matched to what the Slack MCP server returns.
Four details decide whether the rule holds up:
- Real payloads first: Capture a few real search results first, through an admin-only gateway or a test workspace since no rule is in place yet, and open them in the logs. Result shapes differ from tool to tool, so the parser should follow what Slack actually returns, not an assumed format.
- Channel references: Channels can appear as IDs, names, or permalinks. The engine should recognize every form found in the real payloads.
- Unparseable results: A result that can’t be parsed is blocked, because passing it unchecked would let restricted matches through. Blocking everything unparseable can break search entirely, which is why the parser comes first.
- Removed matches: Restricted matches are dropped silently by default, and any count or pagination fields are rewritten to match the filtered list. A placeholder such as “some results were withheld” stops an agent from retrying around the gap, but it also confirms that restricted matches exist. The right choice depends on the threat model.
Important: The request-direction and response-direction rules cover Slack’s message tools only. Tools for files, canvases, lists, and channel search can still expose restricted content or its existence, so hide them through feature provisioning or handle them in the engine as well.
Step 4: Deploy Your Endpoint
The rule engine is an ordinary web service, so it can run wherever the team already hosts services: a container, a serverless function, or a virtual machine. MCP Manager only needs to be able to reach it, which sets four requirements:
- A public HTTPS URL with a certificate from a public certificate authority. Self-signed certificates and private or internal addresses are rejected.
- A response within 30 seconds. In practice, the engine sits in the path of every tool call, so it should answer in well under a second.
- HTTP 200 for every verdict, including block. A block is a normal outcome, not an error, and a non-2xx status is treated as an engine failure.
- Safe handling of repeats. After a timeout or a 5xx error, MCP Manager retries up to three attempts in total, so the same message can arrive more than once and must produce the same result.
Tip: A coding agent can draft most of the rule engine. The MCP Manager docs are available to agents through a docs MCP server, and the webhook contract is published as TypeScript types that can be handed over as is. In one proof of concept, an engineering team gave its coding agent the docs plus access to live payloads, and the agent refined the parser from there. Review the result like any other code before it enforces policy.
Step 5: Register the Rule in MCP Manager
Open Rule Engines, click Add, and choose the Custom provider. Enter the endpoint URL, set the default direction, and add your authentication header. Then open the gateway’s Rules tab, add a rule, and select your engine as the detection method. Choosing Both as the detection hook creates one rule per leg; leave the failure mode at Block.
Important: Registering an engine does not apply it. Until a rule on the gateway’s Rules tab references the engine, its traffic is unfiltered.
Step 6: Test Before Rolling Out
Create a team with two or three administrators and provision the MCP gateway only to them. Send prompts that should pass and prompts that should be blocked, including a search that crosses restricted channels. Confirm the verdicts in the logs, where blocks appear as policy_enforced_abort and rewrites as policy_enforced_mutation. Only then provision the gateway to broader teams.
Custom rule engines are available on MCP Manager’s Enterprise plan. Find the right package for your team.
If a Gateway Has No Rules, Can an AI Agent See Everything?
Yes, for every tool the gateway exposes, in any MCP client. Without rules, nothing inspects channels, so the agent reaches anything the connected user’s Slack token and the app’s scopes permit. Feature provisioning still limits which tools are available, but not what they touch. This is also why a registered rule engine that no gateway rule references filters nothing (see Step 5).
When Can Data First Move?
Not during setup. Adding the Slack server only registers it, adding an identity only stores a credential, and a gateway exposes nothing until a client connects. Data first moves when a provisioned user connects a client and authorizes. A gateway listed in Claude’s connector list is not yet usable: users outside a provisioned team see a message that they have no access.
What Is the Safe Order for Rolling Out the Slack MCP Server?
To block Slack channels from AI agents, the gateway rules must be in place before any user connects. This order keeps the Slack MCP server unreachable until the rules are applied and tested:
- Add the Slack MCP server and identities.
- Create the gateway and assign the server.
- Apply the channel rules to the gateway.
- Provision the gateway to a pilot team.
- Test against real tool calls.
- Widen access.
What to Plan for When You Build the Rule Engine Yourself
Unlike the managed Google Drive Folder Blocker, a Slack channel rule is code the team writes, hosts, and maintains. Three things need an owner from the start.
- Maintenance: When Slack adds or changes tools, the parser needs a matching update.
- Operations: The engine sits in the path of every Slack call, so it needs monitoring and a sensible failure mode.
- Review: Security teams will ask how the rules are shown to cover every path. A rule the team built itself needs its own test cases and log evidence, while an engine that a vendor maintains and validates is an easier case to make.
Teams with an engineer who can own a small service can start right away, and a rule engine is just a detection method on a gateway rule, so it can be swapped later if a managed option appears.
Typical Use Cases for Slack Channel Blocking
Blocking Slack channels from AI agents fits a few recurring situations. The three scenarios below show how channel-level rules on the Slack MCP server work in practice.
Keeping Leadership Channels Out of Reach
Leadership’s concern is specific: with Slack connected, an agent could read C-level channels and repeat what it read during an unrelated task. An allowlist rule solves this at the channel level. Only the channels a department needs are readable. Everything else, including leadership and HR channels, is blocked on the request leg and filtered out of search results on the response leg.
Protecting Customer Data in Support Channels
Support channels collect customer email addresses and account details pasted into messages. Two rules cover this together:
- A channel rule blocks the support channels agents do not need.
- A Presidio rule set to Replace follows it and turns detected entities in the open channels into typed tags such as <EMAIL_ADDRESS>.
Microsoft Presidio is less reliable for names in free-form text, so regex rules should be added for structured identifiers. The channel rule controls where the agent reads, and the PII rule limits what it sees there. Business-confidential content in an allowed channel, such as pricing plans or deal terms, contains no personal data, so the PII rule does not catch it. Channels with that kind of content belong on the blocklist, or should be left off the allowlist.
Rolling Out Department by Department
A common sequence is engineering first, since those teams already use MCP and can tolerate rough edges. Product and business teams follow. Each department gets its own gateway, because the gateway is the smallest unit of governance. Engineering might get broad Slack access with PII filtering, product a narrower allowlist, and business teams only the channels their function needs. A gateway also works as a distribution profile: one URL gives a department every server it needs.
Conclusion: Governance Is What Makes the Slack MCP Server Usable
Blocking Slack channels from AI agents is what closes the gap between “we want Slack in our AI clients” and “we can’t allow it”. The gap is channel-level control. Slack’s scopes and MCP’s tool-level controls don’t provide it, because the channel lives in the payload.
A custom rule engine on MCP Manager’s gateway closes it with two rules: block requests that name disallowed channels, and strip disallowed channels from search results. The same engine extends to Confluence and Jira and stacks with managed engines and PII detection.
If your organization is blocking the Slack MCP server because you can’t control which channels agents reach, book a demo with MCP Manager and scope the rule that unblocks it.
FAQ
Can I block specific Slack channels from AI agents without disabling the entire Slack MCP server?
Yes. Attach a custom rule engine to the MCP gateway serving Slack. A request-leg rule blocks calls to disallowed channels, a response-leg rule strips them from search results, and everything else passes.
What’s the difference between the Google Drive Folder Blocker and Slack channel blocking?
The Folder Blocker is a managed engine: MCP Manager hosts the logic, and you supply folder IDs without code. Slack channel blocking runs on a webhook you write and host. Both are applied as a rule on the gateway’s Rules tab.
How long does it take to build a custom Slack channel rule?
It depends on how many tools you cover and how their payloads are shaped. The code is one HTTPS service implementing a four-verdict contract plus a parser per tool, which a coding agent can draft from MCP Manager’s docs. Most of the effort goes into testing against real payloads.
Why do I need two rules for Slack channel control?
Because of search. Single-channel tools carry the channel ID in their arguments, so a request-leg rule can block them. Search tools return matches from many channels, so only a response-leg rule can remove the disallowed ones.
Does a gateway with no rules give AI access to everything?
Yes, for every tool the MCP gateway exposes. The agent reaches anything the connected user’s Slack token and the app’s scopes permit. Apply and test rules with a pilot team before provisioning the gateway more widely.
Can I use the same custom rule engine for Slack, Confluence, and Jira?
Yes. Every envelope includes serverGuid and toolName, so one service routes each call to the right policy. For Atlassian, also handle the execute tools that wrap deferred operations.
Does blocking Slack channels with an MCP gateway rule change anyone’s access in Slack itself?
No. The rule only applies to what AI agents can reach through the gateway. People keep the same channel memberships and permissions in Slack, and nothing changes in the Slack client.
Can users connect Slack to an AI client directly and bypass the gateway?
Gateway rules only apply to traffic that goes through the gateway. Slack’s MCP server is also available in clients such as Claude and Cursor, and workspace admins approve and manage MCP client apps on the Slack side. The MCP Enterprise Lockdown Checklist covers how to route an organization’s MCP traffic through governed gateways.
Is a managed Slack channel blocker available?
Not today. Slack channel blocking runs on a custom rule engine. Teams that would like a managed option can raise it with their MCP Manager contact or when booking a demo.
Can I combine custom rules with PII detection on the same gateway?
Yes. One gateway can run a custom Slack channel engine, Presidio or regex PII rules, and the Google Drive Folder Blocker. Rules run in order within each hook, and a block stops processing, so place block rules first.
