Per-Agent Channel Allowlists on the Slack MCP Server

Why shared credentials and app scopes are not enough

A Slack app is installed with a set of scopes and a token. Those grants belong to the app. They say nothing about which agent is calling through it. When several AI agents share one Slack MCP server, they typically share the same credentials and the same tool list, so each agent can reach every channel the token can reach. A support-summarization agent and a release-announcement agent end up with identical reach.

MCP server configuration usually has the same limitation. It tends to decide which tools are exposed, not which agent may pass which channel identifier to which tool. Tightening the app scopes narrows access for all agents at once, which breaks the agent that legitimately needs more.

NIST SP 800-228 describes two levels of authorization for an API endpoint: service authorization and end-user-to-resource authorization. Applied by analogy, the shared server credential is the service-level grant. The per-agent channel check is the second level, and it has to be made separately, at the moment of each tool call. That mapping is a design inference, not something the publication says about Slack or MCP.

Build the allowlist: identity first, then structure

Identification comes before any mapping. NIST's NCCoE concept paper on software and AI agent identity and authorization names identification of AI and software systems as a focus area, and it ties that to managing the range of actions an agent may take. In practice, give each agent its own credential or signed token that carries an agent identifier, and have the interception point validate it. Whatever mechanism you choose, never trust an agent name that the agent supplies as a tool argument. The identity must come from something the agent cannot edit.

Then define each agent's policy as an object that pairs the identity with permitted operations and resources. NIST SP 800-204B describes service-level authorization policies built from a policy object that grants positive or negative permission. NIST SP 800-207A gives an example that permits only the GET verb on one path. The Slack equivalent is one tool on one set of channels.

For each agent, record the following:

• Agent identifier and the named owner accountable for its scope.
• Read tools permitted, such as channel history, with a list of channel IDs.
• Post tools permitted, with a separate, usually shorter, list of channel IDs.
• Whether channel listing is permitted, and what the agent may see in the result.
• Default outcome, set to deny for any tool, channel, or agent not listed.
• Review date and the change ticket that last modified the entry.

Treat read and write differently, and decide the outcomes

Read and post carry different risks. Reading exposes data to the agent and, through its output, to whoever the agent serves. Posting sends content out and may be visible to many people immediately. Keep the lists separate, so an agent that may read a channel is not assumed to be allowed to post there.

Use channel IDs rather than channel names in policy, since names can be changed. Inventory every tool your server exposes and identify the argument in each that names a channel. A tool that takes no channel argument, or that can search across channels, needs its own rule because a per-channel check on arguments will not see it.

Then define what each outcome means. Allow passes the call unchanged when the agent, tool, and channel all match. Block refuses the call and returns a clear error when the channel or tool is not on the agent's list, which applies to every unlisted case under default deny. Redact applies where part of the call or response is out of scope but the rest is acceptable, for example removing channels the agent may not see from a channel listing. For high-impact posts you may also route the call for human approval before it executes. Keep the rule set small enough that a reviewer can predict each outcome.

Evidence each decision should produce, and where Trussed fits

An enforcement decision record should let a reviewer answer one question without reconstruction: did this agent stay within its allowlist? At minimum, capture the agent identifier, tool name, target channel ID, outcome (allow, redact, or block), the policy entry and version that produced it, and a timestamp. Record allowed calls as well as blocked ones, since the allowed calls demonstrate the boundary was applied. NIST's working material on AI profiles points to visibility into actions taken, data generated, and outcomes, along with delegation controls that maintain accountability, which is the same need.

Also decide who owns retention and where records are stored, and keep the policy entries themselves under review so a record can be tied to the scope in force at that time.

Trussed enforces policy in the execution path for MCP server tool calls, with allow, redact, and block outcomes applied to individual calls at runtime, not reviewed after the fact. That enforcement generates audit-ready evidence as it runs. Trussed can be self-managed in the customer cloud, with configurable retention and data residency. The design above is useful with any enforcement point that can see the agent identity, the tool, and its arguments.