Stopping the Slack MCP Server from Posting to External Slack Connect Channels
Narrow what the agent's Slack token can reach, then enforce a policy on every message-posting tool call that identifies the destination channel before the post executes. Treat externally shared channels as unauthorized by default, and apply allow, redact, block or escalate for human approval. Keep a record of each decision so you can show that external posting was prevented.
Enforce a destination-aware policy on each tool call
- 1
1. Intercept
Capture the tool call before it reaches the MCP server.
- 2
2. Classify the action
Identify whether the tool writes a message or only reads.
- 3
3. Resolve the destination
Look up the target channel and determine whether it is shared with an external organization.
- 4
4. Evaluate content
Check the message body against rules for sensitive internal data.
- 5
5. Decide
Return allow, redact, block or escalate for human approval.
- 6
6. Record
Write the decision and its context before returning a result to the agent.
Evidence that shows external posting was prevented
- Timestamp of each tool call and decision
- Client ID of the agent or app that made the call
- Request and response status, including blocked or held
- Endpoint identifier: the tool and the destination channel
- Policy outcome and the rule that applied (allow, redact, block, escalate)
- For escalations: approver identity, decision and decision time
Narrow the exposure with Slack-side controls first
Limit scopes
Grant only the posting and reading capabilities the use case needs. If the agent only reads, remove write capability.
Use a dedicated app identity
Avoid reusing a personal credential. A separate identity can be reviewed, rotated and revoked independently.
Control channel membership
Keep the agent's identity out of channels it has no business posting in, especially shared ones.
Review Slack Connect admin settings
Confirm who can create or accept external connections and whether that matches your policy.
Require app approval
Route new or changed app permissions through an admin review step.
How an MCP-connected agent reaches external channels
An MCP server exposes Slack actions to an agent as tools. When the agent calls a message-posting tool, the server runs it with the Slack token it holds. If that token can reach a channel, the call succeeds. A Slack Connect channel shared with another organization is, from the token's point of view, one more channel it can reach.
Three conditions combine to create the exposure. The token has posting capability, the token can reach a channel shared outside the organization, and nothing evaluates the destination at the moment of the call. The agent selects both the channel and the content. Content can include internal data pulled from earlier tool results or retrieved documents, which is how an unintended disclosure to an outside organization occurs.
Slack-side configuration can remove the first two conditions in part. Only enforcement at the tool call addresses the third.
Where native controls stop
Slack admin settings, app scopes and channel membership act at the workspace or token level. They decide whether the token may post in a channel. They do not evaluate an individual tool call's destination, its content, or what the agent is trying to accomplish.
This creates a tradeoff. If people legitimately use a Slack Connect channel with a partner, removing the agent from it is simple, but a token that retains broad reach cannot distinguish a harmless internal notification from a post carrying internal data to an outside channel. Tightening settings further can also disrupt internal automation that shares the same token.
That gap is the reason to add a decision point in the execution path, evaluated per call rather than per token.
Choosing the outcome: allow, redact, block, escalate
Internal channels that match policy are allowed, so existing automation continues. Test this explicitly after any restriction, since broken internal workflows are the usual reason teams loosen controls.
For externally shared channels, block is the sensible default. Redact fits a narrower case: an authorized external channel where the post is permitted but certain values must not leave. Escalate for human approval fits channels that are occasionally legitimate but too consequential to automate. It requires a defined approver role, a held call that does not execute until a decision is made, and a retained record of who decided. If the destination cannot be resolved, treat the call as unauthorized and block it.
Trussed enforces policy in the execution path across agents, tools and MCP servers, at the level of individual tool calls, with allow, redact, block, rate limit and escalate for human approval as outcomes. Policy is enforced at runtime, not reviewed after the fact. Trussed can be deployed self-managed in the customer cloud, which keeps message content and decision records within your own environment.
Layers that limit external posting
Label: Token and scopes
Description: Give the agent only the Slack capabilities its use case needs.
Label: Channel reach
Description: Limit membership and review Slack Connect admin settings.
Label: Tool-call policy
Description: Resolve the destination and decide before each post executes.
Label: Decision records
Description: Retain evidence of what was allowed, redacted, blocked or escalated.
Enforce policy on Slack tool calls where they execute
See how Trussed enforces policy on MCP tool calls in the execution path and produces audit-ready evidence for each decision.
See How Evidence Is ProducedHow does your AI governance program compare?
See where your program has gaps in less than 2 minutes.