Human Approval for AI Agent Messages in Slack and Teams

Why this is an execution-path problem

A client-facing message cannot be retracted once the client has seen it. Review after posting is therefore a detection step, not a control. A prompt instruction such as "ask before sending" is also not a control, because the model can ignore it and nothing outside the model checks it.

The control has to sit where the message leaves the agent: the tool call that sends it. This follows the policy enforcement point model in NIST SP 800-207, where requests are directed to a point that evaluates and authorizes them before they reach the resource. That standard addresses network access, not Slack, Teams or AI agents, so treat it as an architectural analogy. For the human step, NIST SP 800-53 Rev. 5 says that when a fully automated flow control decision is not possible, human review may be used in place of or as a complement to automated policy filtering. A client-facing send is a reasonable case for that complement.

Two design rules follow. First, keep drafting and sending as separate permissions, and do not give the agent the posting credential directly. If the agent holds a bot token or webhook URL, it can bypass any approval logic you build. Second, enforce on every send path the agent can reach, including bot tokens, webhooks and tool calls made through MCP servers. NIST overlay material names MCP as a protocol through which agents access data sources and take actions, so an MCP send tool needs the same enforcement as a direct API call.

Classifying client-facing destinations

Slack and Teams differ in their messaging APIs, permission models and interactive approval mechanisms. Shared channels and external guests blur the line between internal and client-facing communication. A channel name or a naming convention is not a reliable signal.

Resolve the destination from platform data at the moment of the call. Establish which organization or tenant owns the conversation, whether participants from outside your organization are present, and whether the target is a channel, a thread, or a direct message. Compare those attributes against an explicit allowlist of your own workspaces and tenants. Anything that is outside the allowlist, includes external participants, or cannot be resolved should be treated as client-facing. Ambiguity should raise the review requirement, not lower it.

Re-check classification at release time. Membership can change between the hold and the approval, and an approval granted for an internal channel should not carry over to a destination that has since gained an external guest. Bind each approval to the specific destination and the exact content reviewed.

Map each client-facing destination to an accountable principal, such as the account owner. SP 800-53 treats the scope of human review as organization-defined, so document which destinations require review and who owns each one.

Outcomes, routing and failure handling

Define each outcome before building the interface.

Approve: post exactly the content the reviewer saw. Compare a hash of the approved text to the text at release, so nothing changes in between.

Edit: treat the edited text as new content. Re-run policy and payload inspection on it, retain the original draft alongside it, and record who made the change. The edit should not silently inherit the original approval.

Reject: block the call and return a structured reason to the agent. Apply the same hold to any retry, so the agent cannot get a reworded version through by calling again.

Failure cases need the same rigor. Use default-deny: if the reviewer does not respond before a defined expiry, the message is not sent. Never convert a timeout into an approval. Define a delegate for each principal in advance, and escalate to that delegate when the primary reviewer is unavailable. Expire stale approvals, and fail closed if the approval service or the destination lookup is unreachable. Authenticate the reviewer from the platform identity of the person who acted on the approval message, and do not accept approvals from the agent's own session.

The tradeoff is latency. Review adds delay to client communication, so reserve the hold for client-facing destinations and let internal messages pass under policy without human review.

Application-level approval or enforcement in the execution path

Approval logic inside a single bot application is workable when one agent, one workspace and one send path are involved. It becomes fragile when several agents, several MCP servers or several credentials can post to clients. Each path then needs its own copy of the logic, and the evidence is scattered across applications in different formats.

Policy enforcement in the execution path is a better fit when you need one rule applied to every send path, when the agent must never hold the posting credential, and when the evidence must be consistent enough to hand to an auditor. It also keeps the decision outside the model and outside application code that an agent change could alter.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. Its actions include allow, redact, block, rate limit and escalate for human approval. This maps directly to the hold, escalate and release steps above. Enforcement generates audit-ready evidence, and self-managed deployment in the customer cloud is available with configurable retention and data residency. The scope is the individual call, not a whole workflow, so principal review of a client message is configured per send action.

Whichever way you build it, test the pattern before relying on it. Attempt a send through every path the agent can reach, including a direct webhook and an MCP tool, and confirm that none of them posts to a client destination without a recorded approval.