{"slug": "slack-mcp-channel-allowlists-stopping-agents-posting-to-general", "title": "Slack MCP Channel Allowlists: Stopping Agents Posting to #general", "summary": "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.", "body_md": "It is 11:47 on a Tuesday. An agent finishes a long-running task, decides the team should know, and calls `post_message`\n\nwith `channel: \"#general\"`\n\n. 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.\n\nRate 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`\n\nin the first place.\n\nA typical Slack MCP server exposes a generous surface. `post_message`\n\n, `add_reaction`\n\n, `update_message`\n\n, `delete_message`\n\n, `list_channels`\n\n, `get_history`\n\n, and — depending on the implementation — `archive_channel`\n\n, `delete_channel`\n\n, `kick_user`\n\n, `invite_user`\n\n. 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.\n\nRate 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`\n\ncalls 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).\n\nBut rate limits are blind to arguments. They count calls, not destinations. One `post_message`\n\nto `#general`\n\ncosts the same against the budget as one `post_message`\n\nto `#bot-test`\n\n. 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.\n\nPolicyLayer'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.\n\nThe 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`\n\n.\n\n```\n{\n  \"version\": \"1\",\n  \"default\": \"allow\",\n  \"hide\": [\n    \"delete_channel\",\n    \"archive_channel\",\n    \"kick_user\",\n    \"delete_message\"\n  ],\n  \"tools\": {\n    \"post_message\": {\n      \"require\": [\n        {\n          \"conditions\": [\n            { \"path\": \"args.channel\", \"op\": \"in\", \"value\": [\"#bot-test\", \"#agent-output\"] }\n          ],\n          \"on_deny\": \"Posting is limited to bot output channels.\"\n        }\n      ],\n      \"deny_if\": [\n        {\n          \"conditions\": [\n            { \"path\": \"args.channel\", \"op\": \"in\", \"value\": [\"#general\", \"#announcements\", \"#exec\"] }\n          ],\n          \"on_deny\": \"Posting to broadcast channels is not permitted.\"\n        }\n      ]\n    },\n    \"update_message\": {\n      \"require\": [\n        {\n          \"conditions\": [\n            { \"path\": \"args.channel\", \"op\": \"in\", \"value\": [\"#bot-test\", \"#agent-output\"] }\n          ],\n          \"on_deny\": \"Message updates are limited to bot output channels.\"\n        }\n      ]\n    }\n  }\n}\n```\n\nTwo things to notice. First, **Require** is the workhorse. A `Require`\n\nclause fails closed: if `args.channel`\n\nis missing, not a string, or not in the allowlist, the call is denied before it ever reaches Slack. The `in`\n\noperator does an exact set membership check, so `\"#general-engineering\"`\n\nwill not match `\"#general\"`\n\n.\n\nSecond, **Deny if** is not redundant. It is there because allowlists drift. Someone adds `#new-bot-output`\n\nto 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.\n\n**Hide** does something different. It strips the named tools from the `tools/list`\n\nresponse that PolicyLayer returns to the agent during the MCP handshake. From the agent's perspective `delete_channel`\n\ndoes 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`\n\n; for that you use Require and Deny if.\n\nThe full set of operators available to Require and Deny if conditions is `eq`\n\n, `neq`\n\n, `lt`\n\n, `lte`\n\n, `gt`\n\n, `gte`\n\n, `in`\n\n, `not_in`\n\n, `exists`\n\n, `regex`\n\n(Go stdlib syntax), and `contains`\n\n. For channel allowlists `in`\n\nand `not_in`\n\ncover the common cases; `regex`\n\nis useful if your team uses a channel naming convention like `bot-*`\n\nand you want to allowlist the pattern rather than enumerate every channel.\n\nSlack MCP servers do not share a single schema. The community implementations vary. Some use `channel`\n\nas a top-level string. Some use `channel_id`\n\nand expect the Slack-internal `C01234ABCDE`\n\nform rather than the human-readable `#name`\n\n. Some nest the destination inside an object as `channel.id`\n\nor `target.channel`\n\n. At least one calls it `slack_channel`\n\n.\n\nAuthoring a rule against the wrong path has different failure modes depending on the section. In `require`\n\n, a missing path fails closed and denies the call. In `deny_if`\n\n, a missing path means the deny rule does not match. Before you write the policy, run `tools/list`\n\nagainst 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.\n\nPolicyLayer condition paths are `args.<path>`\n\nexpressions and support nested fields. If the schema gives you `{ channel: { id: \"C01234ABCDE\", name: \"general\" } }`\n\n, your path is `args.channel.id`\n\nor `args.channel.name`\n\ndepending on which form your tool expects. There is no separate matcher for the tool name itself — use Hide to drop tools entirely.\n\nA 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.\n\nEvery deny is logged in the proxy feed with the rule pointer that fired — `/tools/post_message/require/args.channel-in`\n\nor `/tools/post_message/deny_if/args.channel-in`\n\n— 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.", "url": "https://wpnews.pro/news/slack-mcp-channel-allowlists-stopping-agents-posting-to-general", "canonical_source": "https://dev.to/policylayer/slack-mcp-channel-allowlists-stopping-agents-posting-to-general-od2", "published_at": "2026-06-16 13:35:19+00:00", "updated_at": "2026-06-16 13:47:40.958220+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "developer-tools"], "entities": ["PolicyLayer", "Slack"], "alternates": {"html": "https://wpnews.pro/news/slack-mcp-channel-allowlists-stopping-agents-posting-to-general", "markdown": "https://wpnews.pro/news/slack-mcp-channel-allowlists-stopping-agents-posting-to-general.md", "text": "https://wpnews.pro/news/slack-mcp-channel-allowlists-stopping-agents-posting-to-general.txt", "jsonld": "https://wpnews.pro/news/slack-mcp-channel-allowlists-stopping-agents-posting-to-general.jsonld"}}