# Slack MCP Channel Allowlists: Stopping Agents Posting to #general > Source: > Published: 2026-06-16 13:35:19+00:00 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.` expressions and support nested fields. If the schema gives you `{ channel: { id: "C01234ABCDE", name: "general" } }` , your path is `args.channel.id` or `args.channel.name` depending on which form your tool expects. There is no separate matcher for the tool name itself — use Hide to drop tools entirely. A wrong-channel post is not recoverable. You cannot un-notify two hundred people. Channel allowlists move the failure mode from "agent reaches the wrong audience" to "agent's call is rejected before it leaves the proxy." The blast radius of a single bad inference is bounded by your policy, not by your hope that the agent will pick the right channel. Every deny is logged in the proxy feed with the rule pointer that fired — `/tools/post_message/require/args.channel-in` or `/tools/post_message/deny_if/args.channel-in` — plus the grant, tool, outcome, message, and top-level argument keys. PolicyLayer evaluates the channel value at request time but does not retain argument values in the proxy log. You can prove to a security reviewer that the gate exists, was hit, and held. This is the [deterministic half of the agent stack](https://policylayer.com/blog/deterministic-ai-agent-policies): not a prompt asking the agent to behave, an evaluator refusing to forward the call.