How to Require Approval Before an AI Agent Sends a Slack Message Through MCP

Decide which Slack tool calls need approval

Start with an inventory of every tool the Slack MCP server exposes, then identify which ones create or change visible content: posting to a channel, replying in a thread, sending a direct message, or editing or deleting a message. Read-only tools carry a different risk profile and usually belong in a separate policy.

NIST's control targets high-stakes calls. It does not call for approval of every call, and a policy that interrupts every send will be ignored or switched off. Classify first, then write rules. A reasonable split routes sends to an internal, low-sensitivity channel under automatic evaluation, and holds sends that cross a trust boundary for a person.

Policy conditions are the arguments and context of each call. Four are most useful. Channel: is the destination public, private, shared, or external-facing? Recipient: is it a single user, a group, or someone outside the organization? Content: does the text contain sensitive data, credentials, or links the agent was handed by an untrusted source? Agent identity: which agent, acting for which user, with what delegated scope? Which of these fields can be evaluated depends on the arguments the server's tools actually accept, so confirm that per tool.

Each rule should resolve to one of four outcomes: allow, redact, block, or escalate. Redact fits a message that is acceptable once a secret or identifier is removed. Block fits a destination that is never valid for the agent. Escalate fits anything that needs a human judgment about audience or context.

Two supporting controls strengthen the approval. Validate tool-call arguments against a strict schema so the agent cannot add unexpected fields. Issue short-lived, scoped credentials so an approved call cannot be replayed for a different purpose.

Client-side confirmation compared with runtime policy enforcement

Many MCP clients can ask a user to confirm a tool call. That is a useful usability feature. As an enterprise control it should be judged against the criteria below, because the confirmation lives in whichever client the user happens to run.

• Where it runs: Client-side: inside the client application the user chooses. Runtime enforcement: in the execution path between client and server, for every client.
• Outside the agent's control: Client-side: depends on how each client is configured and whether prompts can be pre-approved. Runtime enforcement: the agent cannot approve or skip the step.
• Policy conditions: Client-side: typically a per-tool confirmation. Runtime enforcement: rules on channel, recipient, content, and agent identity.
• Possible outcomes: Client-side: approve or reject. Runtime enforcement: allow, redact, block, or escalate to a named authority.
• Evidence: Client-side: varies by client. Runtime enforcement: a consistent record of who approved what, produced at decision time.
• Consistency across agents: Client-side: one behavior per client. Runtime enforcement: one policy applied across clients and agents.

Where Trussed fits

Trussed enforces policy in the execution path across models, agents, tools, and MCP servers, at the level of individual interactions and tool calls. For a Slack MCP deployment, that means a message-sending call can be allowed, redacted, blocked, or escalated for human approval at runtime, not reviewed after the fact. Enforcement generates audit-ready evidence of what the policy permitted and what happened, which supports a regulated enterprise that must show an auditor how an agent's actions were controlled.

The design in this guide does not depend on any single product. The requirements stay the same: an enforcement point outside the agent, policy conditions tied to destination, content, and identity, a defined approve, deny, and timeout flow, and an evidence record for every decision.