Slack MCP Channel Allowlists: Stopping Agents Posting to #general A developer at PolicyLayer describes a solution to prevent AI agents from posting to sensitive Slack channels like #general. The approach uses channel allowlists and denylists in an MCP server policy, rather than rate limits, to block single erroneous calls. The policy also hides destructive tools like delete_channel from the agent's available tools. It is 11:47 on a Tuesday. An agent finishes a long-running task, decides the team should know, and calls post message with channel: " general" . The message is half a sentence, a stray code block, and a JSON dump of an internal error. Two hundred people see it before anyone can delete it. Rate limits would not have helped. The agent was within its budget. The first call was the one you wanted to stop, and rate limiting is a tool for the hundredth call, not the first. The fix is not throttling. The fix is a Slack MCP channel allowlist: the agent should never have been allowed to address general in the first place. A typical Slack MCP server exposes a generous surface. post message , add reaction , update message , delete message , list channels , get history , and — depending on the implementation — archive channel , delete channel , kick user , invite user . From the agent's point of view this is a flat menu of capabilities. From your point of view it is a list of ways a misfiring loop can become a company-wide incident. Rate limits are the right answer for one specific failure mode: an agent that gets stuck and calls the same tool a thousand times in a minute. A per-grant cap of, say, 20 post message calls per hour will turn that runaway loop into a small annoyance instead of a flood. That is genuinely useful, and we have written about it before https://policylayer.com/blog/secure-slack-mcp-server . But rate limits are blind to arguments. They count calls, not destinations. One post message to general costs the same against the budget as one post message to bot-test . If the damaging case is a single wrong call — and for company-wide channels it almost always is — counting calls cannot save you. You need a different primitive: one that inspects what is inside the call and refuses based on its contents. PolicyLayer's evaluator has four primitives: Require , Deny if , Limits , and Hide . The first two operate on the request arguments. The fourth removes tools from the handshake entirely. For Slack channel scoping you want all three. The shape of the policy is: positively allowlist the channels the agent is permitted to write to, then add a denylist as a belt-and-braces backup, then hide the destructive tools so the agent never sees them in tools/list . { "version": "1", "default": "allow", "hide": "delete channel", "archive channel", "kick user", "delete message" , "tools": { "post message": { "require": { "conditions": { "path": "args.channel", "op": "in", "value": " bot-test", " agent-output" } , "on deny": "Posting is limited to bot output channels." } , "deny if": { "conditions": { "path": "args.channel", "op": "in", "value": " general", " announcements", " exec" } , "on deny": "Posting to broadcast channels is not permitted." } }, "update message": { "require": { "conditions": { "path": "args.channel", "op": "in", "value": " bot-test", " agent-output" } , "on deny": "Message updates are limited to bot output channels." } } } } Two things to notice. First, Require is the workhorse. A Require clause fails closed: if args.channel is missing, not a string, or not in the allowlist, the call is denied before it ever reaches Slack. The in operator does an exact set membership check, so " general-engineering" will not match " general" . Second, Deny if is not redundant. It is there because allowlists drift. Someone adds new-bot-output to the allowlist for a new workflow, the list grows, the broadcast channels stay off it — and then someone refactors the policy and accidentally widens the allowlist. The Deny if clause is the second lock on the same door. If the channel is ever one of your no-go destinations, the call dies regardless of what the allowlist says. Order in the evaluator is: Deny if runs after Require, and a single hit denies. Hide does something different. It strips the named tools from the tools/list response that PolicyLayer returns to the agent during the MCP handshake. From the agent's perspective delete channel does not exist on this server. It cannot be hallucinated into a tool call because it never appears in the menu. This is whole-tool gating only — you cannot hide one variant of post message ; for that you use Require and Deny if. The full set of operators available to Require and Deny if conditions is eq , neq , lt , lte , gt , gte , in , not in , exists , regex Go stdlib syntax , and contains . For channel allowlists in and not in cover the common cases; regex is useful if your team uses a channel naming convention like bot- and you want to allowlist the pattern rather than enumerate every channel. Slack MCP servers do not share a single schema. The community implementations vary. Some use channel as a top-level string. Some use channel id and expect the Slack-internal C01234ABCDE form rather than the human-readable name . Some nest the destination inside an object as channel.id or target.channel . At least one calls it slack channel . Authoring a rule against the wrong path has different failure modes depending on the section. In require , a missing path fails closed and denies the call. In deny if , a missing path means the deny rule does not match. Before you write the policy, run tools/list against your MCP server once and read the schema for the tools you are gating. The argument name and shape are in the JSON Schema for each tool. PolicyLayer condition paths are args.