Can IT post to just one Slack channel from Claude?
Yes. IT can read Slack and post to exactly one Slack channel from Claude, once Elaichi freezes the channel on the send-message tool. Your IT team answers most tickets in Slack threads: a laptop will not enroll, a screenshot follows, and the thread becomes the record. With Claude connected, an agent reads the thread and posts a summary to the help desk channel, and nowhere else.
Before anyone connects an account, decide three things: which reads are allowed, where the agent may post, and which Slack tools nobody's agent should call at all. Elaichi's Slack connector lists every tool those rules can name.
MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi serves Slack's tools from one organization-wide endpoint, POST /mcp, standard MCP over Streamable HTTP behind OAuth (the authorization framework the client signs in through). In Claude Team and Enterprise, an owner adds that address once under Organization settings > Connectors. Each member then connects it under Customize > Connectors and signs in with their own grant. On Pro and Max, each person adds it under Customize > Connectors (Claude's help center, as of October 2026). The address is the same for everyone; the grant, the role and the rules are what vary.
Which Slack tools should IT allow first?
The reads the team needs plus one write, and nothing else. For a help desk, the reads are list_all_slack_conversations, list_all_slack_conversation_history, list_all_slack_conversation_replies and list_all_slack_search. The write is create_a_slack_chat, which sends a message.
A restriction in Elaichi is a rule about which connectors and which individual tools a target may reach. Put these tools in an allow rule on the IT role. Once that role holds an allow rule, every connector no allow rule on the role names is denied for the role, not only Slack's other tools. Allow rules on the same role add up, so give the role an allow rule for each other app it uses, naming the whole connector where that is enough, or the team loses those apps. The catch: the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. It is the strictest rule you can express, and it is easy to create by accident while drafting one.
Allow rules match on the pinned operation only. When you write a rule against a connector and tool, Elaichi pins the canonical resource and method against the catalog at write time. Whoever edits the connector documentation controls the advertised tool name, but not the operation pinned underneath it. Governance binds the operation, never the label.
Elaichi marks reads with MCP's read-only hint and deletes with the destructive hint, and gives a plain write, such as editing a message, neither. The MCP specification tells clients to treat annotations as untrusted unless they come from a trusted server (MCP specification). A hint tells a client what a tool does. The rule decides whether IT can call it.
How does a frozen channel stop Claude posting elsewhere?
It removes the choice. Freeze the channel argument on create_a_slack_chat, and Claude can post to that channel and no other. A frozen parameter is a fixed argument value attached to a toolbox entry, where a toolbox entry is one tool tied to one connected account.
Freezing has two effects, and both matter here. The frozen key is removed from the schema Claude is shown, so there is no channel for the model to fill in. The frozen value is then merged over the caller's arguments at execution, so passing the key anyway cannot un-freeze it. The order runs entry defaults, then caller and model arguments, then frozen parameters.
That is what makes a pinned channel hold up against an instruction pasted into a ticket. The model is not being asked to respect a channel policy; it has no channel argument to change. It also closes the direct-message route through the send tool. A DM is a conversation with its own channel ID, and the frozen value replaces whatever ID the model tries to pass.
The lock belongs to the toolbox entry, so it holds only for calls made through that entry. Put the reads and the send tool in one toolbox, share it with IT, and leave the Slack connection itself unshared. A member with use on the connection could reach the unfrozen create_a_slack_chat directly. Every post through the toolbox goes out as the connection owner's Slack account. Slack shows that account, and Elaichi's audit trail records which member made the call.
How do you keep Claude from DMing everyone or deactivating users?
Block the DM tool, and know that deactivation is not on the Slack connector at all. Elaichi's Slack connector opens direct messages with create_a_slack_conversations_open, which opens or resumes a direct message or a group DM. It has no tool that deactivates a Slack user.
Write a block rule on the IT role for create_a_slack_conversations_open, and add update_a_slack_chat_by_id and delete_a_slack_chat_by_id, which edit and delete messages. The allow rule already leaves all three out. The blocks are the backstop: within each layer, blocks always beat allows, so they hold even if someone later widens the allow rule. A block also matches on the tool name or the pinned operation, so it survives a rename. The reasoning is in how block and allow rules match differently.
Deactivation usually lives in the identity provider. If IT also connects Okta, okta_users_deactivate and okta_users_suspend are the tools to block on the same IT role. OAuth scopes limit the blast radius as well. They ladder from mcp:read through mcp:write to mcp:destructive, and a tool classified forbidden is reachable under no scope at all. The block rule is what keeps a named tool out of one team's hands.
Bulk direct messaging is a different risk and gets the same treatment. Nothing about it is destructive, so the scope ladder will not stop it. A block rule will.
The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. On the endpoint itself, the controls are RBAC per operation, the forbidden classification, redacted output, the scopes on the OAuth grant, and the audit trail. Plan the Slack rollout on the assumption that the rules are the control, not on the endpoint reasoning about intent.
Should the Slack rule sit on the IT role or on a person?
On the role. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. An unrestricted Slack connection is therefore open to everyone it is shared with who can execute tools.
A role keeps the policy attached to the persona rather than to a list of names, and every member carries exactly one role, enforced by a unique index. Use a user-targeted rule only to narrow one person. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule. If a senior engineer needs one extra tool, they file an access request and an admin approves it in the console. The approval creates a grant for that one person, and the role rules stay as they were.
Timing matters mid-rollout. A role or restriction change takes effect within about two minutes. Grant revocation, member removal and suspension are effective on the next call. If somebody has to lose Slack access now, revoke the grant or suspend the member rather than editing a rule and watching.
Elaichi checks the rule at every place a member can reach a connector or tool, including listing, connecting, advertising, executing, the final outbound-request check and opening a stored tool file. A restricted Slack tool is withheld from the tool list and cannot be called. Search names it, flagged restricted, with no schema.
Do multi-step incident tools get the same checks?
Yes. An incident summary is rarely one call: read the channel, pull the Jira ticket, post the write-up. A synthetic tool packages that as a directed acyclic graph of steps, each calling a connected account's tool with templated arguments over inputs and prior outputs. Cycles are rejected at save, and independent steps run in parallel.
Nothing is skipped. Every step goes through the same restriction check as any other call, evaluated for the person running the tool. A synthetic tool that reaches for a restricted tool meets the restriction at that check. The audit trail holds one row for the whole run, with counts only. The individual step calls are not written as separate rows.
What does the audit trail show after Claude posts?
One entry for each call that reaches execution, whatever happened there. A call refused earlier, such as one for a tool the role withholds, writes none. The trail records one entry for each connected-tool call that reaches execution (a call refused earlier writes none). The connection on every entry is the account the call reached, not the one the caller intended. With two Slack workspaces connected, the log says which one got the message.
Each record carries the operation and tool, the connection, the classification and whether the call was approved, along with its outcome and an error code when it failed. The actor_kind field is recorded, not inferred later from a user agent, and ai_assistant marks only the Elaichi Agent. A call from Claude is recorded under the member who signed in, with surface mcp and the OAuth client named, and Claude is marked verified. So "whose Claude posted that" is answered by the record itself.
Here is the trade-off to plan around. The trail logs the one path argument that names the object, as the target id, and nothing else about the arguments. It will not show the message text or the channel ID passed in. That is why the channel belongs in a frozen parameter rather than in a convention the team agrees to follow. The configuration proves the destination, and the log proves the call ran against a named Slack account.
The trail is newest-first, cursor-paginated and filterable by free text, category, actor, action kind and time. It is eventually consistent, so a row may take a moment to appear. A departed member shows as "Former member" rather than vanishing. Audit events and application logs share one record shape, so one query answers "what happened" without correlating two systems by eye. Error text from a Slack response goes back to the caller and is never written to the trail. The trail inside Elaichi is on Gold. Beyond the in-app trail, export to your own Datadog comes with the Black plan, which is launching soon. Elaichi accepts Splunk HEC and Microsoft Sentinel as destinations but delivers events only to Datadog.
Give the person who reviews all of this an Auditor seat. Auditor is read-only, sits off the role chain and is free, so a compliance reviewer does not use a license. Auditor also lacks tool:execute, which gates the whole endpoint ahead of every scope, so an Auditor cannot call a Slack tool while reading about one.
Why not use Slack's own MCP server for IT?
Slack's own server is the shorter path if Slack is the only app IT's agent touches. With it, "your integrated apps can search channels, send messages, and perform other Slack actions through MCP clients" (Slack's MCP docs). The same page, checked October 2026, says "Workspace admins can approve and manage all MCP client integrations". Its endpoint is https://mcp.slack.com/mcp, and "MCP clients must be backed by a registered Slack app". Slack's server runs under Slack's own permission model and admin approval, with no second vendor.
Elaichi's case rests on what spans apps. One address serves Slack, Jira and Okta, in Claude, ChatGPT and Cursor alike. One set of rules on the IT role covers all three, and a frozen argument holds a send to one channel. Slack's page lists what its tools can do but does not describe fixing a tool's channel. One audit trail spans every connected app, and one removal ends a leaver's access through Elaichi to all of them at once. Their Slack, Jira and Okta accounts are a separate step.
What happens when the engineer who connected Slack leaves?
Their access ends on the next call, and the connections they own are resolved before the removal completes. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. The grant's revoked timestamp is re-read from the organization store on every call, with no cache.
Offboarding then runs a preflight that lists every connection the departing member owns, private and shared alike. A private connection that a shared toolbox still relies on blocks the removal until you transfer it to an active member. A private connection nothing else depends on cannot be transferred and is deleted with the member. A shared Slack connection the team still depends on is left untouched unless the admin deletes it; transfer it to a member who is staying, which leaves every grant on it exactly as it was. A connection is never handed to the organization, to a team, or to the admin running the removal. Contractors make this routine, and the short version for them is in what to do about contractor AI access today.
When is this more setup than IT needs?
If three people use Claude, all three are admins, and the only Slack account connected is a bot with read scopes, restrictions are overhead. The honest version of that argument, including the signals that you have crossed over, is in when you don't need an MCP gateway yet.
The crossover usually arrives with the first non-admin. Once a contractor or a junior analyst holds a grant, allow-all stops being a decision and becomes a default nobody made.
In what order should IT set this up?
Connect the Slack account first, write the allow rule second, build the toolbox with the channel frozen third, add the blocks fourth, and share the toolbox, not the connection, last. Then make one deliberate test post and read its entry in the audit trail. Sharing before the rules exist leaves a window where allow-all applies to a live account.
A sales version of the same sequence, run against Salesforce in ChatGPT, is in the Salesforce rollout playbook. For what else IT can reach from the same address, browse the connector catalog, and for how other functions set this up, see the use-cases directory. More posts in this series sit under team playbooks.
