Slack MCP Channel Allowlists: Stopping Agents Posting to #general

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.

The Problem: Rate Limits Don't Scope Targets

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.

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.

Channel Allowlists with Require and Deny if

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.

A Note on Argument Names

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.<path> 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.

Why This Matters

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: not a prompt asking the agent to behave, an evaluator refusing to forward the call.