Signature checks
Slack request signing can be verified before the payload reaches the agent loop.
Slack AI · gateway adapter
A Slack AI agent should not bypass governance.
Muster's Slack adapter maps Slack events into the shared gateway envelope, verifies signing secrets when configured, requires sender pairing, and records memory and token receipts for every run.
Slack setup path
Bot token, signing secret, pairing, then governed replies.
$ muster gateway init $ muster channels setup slack $ muster gateway start --port 7460 $ muster pairing approve <code>
Pairing required
Unknown senders receive a pairing challenge instead of direct agent access.
Token ledger
Slack turns are still normal Muster runs with usage and replay-waste visibility.
Tool policy
Commands and MCP tools remain behind explicit policy and setup checks.
Draft streaming
The gateway contains Slack draft posting and update support for smoother channel replies.
In practice
A Slack bot is the easiest way to accidentally remove every control you built.
Most agent deployments start in a terminal, where the person running the agent is the person who configured it. Slack changes that in one step. Suddenly anyone in the workspace can address the agent, including guests, including people from other teams, including an integration posting on behalf of someone who has left. If the Slack path does not enforce the same rules as the CLI path, the Slack path becomes the way around them.
The adapter is a mapping, not a second agent
Muster's Slack adapter converts Slack events into the same SurfaceMessage envelope every other surface produces — terminal, web, Telegram, Google Chat, Teams, Discord, WhatsApp. That envelope carries who sent the request, which scope is active, which provider route applies, and what tool policy is in force. There is no separate Slack agent with its own permissions to keep in sync, because there is no second agent.
Two gates before the model sees anything
The first gate is cryptographic. When a signing secret is configured, Slack's request signature is verified before the payload reaches the agent loop, so a forged webhook does not get a turn. The second gate is human. An unknown sender receives a pairing challenge rather than direct access, and an operator approves the code. That is deliberately a small amount of friction placed at exactly the point where a new person gains the ability to spend your tokens and call your tools.
Scope follows the sender
Once paired, a Slack sender maps into memory lanes rather than a shared history: tenant, workspace, user, role, and session. What one person's conversation taught the agent does not automatically become available in someone else's channel, which is the failure people usually discover only after it has already happened. Retrieval is filtered by which lanes the current run is entitled to see, and there are tests whose entire job is to try to make one scope leak into another.
Slack turns still cost money, visibly
A Slack turn is a normal Muster run: usage in and out, estimated cost, and a replay-waste flag land in the local ledger. This matters more in chat than in a terminal, because chat threads get long and a naive harness resends the whole thread every time. Across five benchmark scenarios and 170 turns, replay-everything sends 875.8k tokens where Muster sends 355.2k — and the longest thread in that set shows the largest gap, at 62.7%.
Commands and MCP tools stay behind the same explicit policy and setup checks they have everywhere else, and the gateway supports draft posting and updates so replies can stream into a channel rather than landing as one delayed block.
Govern the MCP tools it can call -> How memory scoping works -> Gateway docs ->