# Connect Slack to Claude for the whole company

> Connect Slack to Claude for the whole company: per-person connections, which Slack tools to block per role, and what the audit log keeps.

**TL;DR** To connect Slack to Claude for the whole company, each person connects Claude once to Elaichi's single MCP endpoint and connects their own Slack account, so every call runs as them. Block Slack's posting and deleting tools on the roles that only need to read, using a restriction on each role. Elaichi records every call that runs with the person, the tool, the connection and the client, in one audit log across apps.

## What goes wrong when 200 people connect Slack to Claude themselves

Nothing breaks at first when you connect Slack to Claude for the whole company by letting each of 200 people do it themselves. Each person adds a connector and signs in to Slack. From then on their Claude can do whatever that Slack account can do, including posting to channels. You find out what happened when somebody's AI posts a half-finished summary into #general. Or when a terminated employee's Slack OAuth token is still live three weeks after their last day, because nobody tied the two systems together.

Two terms recur in this piece and are used inconsistently across the industry, so fix them now:

- **Connector**: the integration slot a client exposes (Claude's "Connectors" page, Slack's own MCP server). This is Anthropic's and Slack's word.
- **Connection**: in Elaichi, one specific credential instance one person created by signing in to Slack. A connector is the category; a connection is the row with a token behind it.

The decisions an IT lead actually has to make are smaller than the rollout feels:

1. Whose Slack account does a call run as.
2. Which Slack tools can run at all, for which roles.
3. Where the record of each call goes.

This playbook answers those three, in that order. It then covers offboarding, and the point where Claude's own connector settings are sufficient on their own without any third-party layer.

## Should you connect Slack to Claude for the whole company with one shared account?

Default to one Slack connection per person. In Elaichi, every call through a connection uses the Slack account that connection was authenticated with, regardless of who is calling. A connection shared across a team therefore acts in Slack as its owner, for everybody it is shared with.

That makes the trade-off concrete:

- **Each person connects their own Slack account.** Claude reaches only the channels and conversations that person can already see. The audit entry names them specifically. Their existing Slack permissions are the ceiling: nothing is granted that Slack itself didn't already grant.
- **One connection shared at the use level.** Everyone who can use it reaches whatever the owner's Slack account reaches. This is defensible for a narrow job, such as a connection that only ever posts status updates to one channel. It is wrong as the default for a whole company, because a support agent using a shared connection inherits the owner's full reach, not just the one channel they needed.

A middle shape sits between the two. A connection the owner keeps unshared can be pinned into a **toolbox entry** with specific arguments frozen. That toolbox entry is then shared at the use level instead of the raw connection. The team reaches the owner's account only through that entry, with whatever arguments are frozen on it. Freeze the channel argument on a message-reading tool and the team can query one alerts channel without reaching the rest of the workspace. The model can see that the value is set, and often what it is, but cannot change it. The freeze only holds on calls that route through that specific entry. Anyone who can call the connection directly still has the unfrozen tool. [Locking a tool's arguments](/blog/frozen-parameters-wire-transfer-receiver/) covers the mechanics.

For a company-wide Slack rollout, per-person connections are the correct default. The narrower pattern is covered in [letting IT post to one Slack channel from Claude](/blog/it-team-claude-slack-messaging/).

## What Claude's own Slack connector settings control, and what they do not

On Claude Team and Enterprise plans, an Owner or Primary Owner enables a connector for the organization under Organization settings, Connectors. Each member then authenticates to Slack individually (Anthropic, [connectors article](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities), checked October 2026). Anthropic documents three tool-permission states, Always allow, Needs approval and Blocked, applicable to a whole connector, a category of its tools, or a single tool (same article).

Slack publishes its own MCP server. Slack's documentation states that a workspace's integrated apps can search channels, send messages and take other Slack actions through MCP clients. It states that workspace admins can approve and manage all MCP client integrations. It also states that any MCP client connecting to Slack's server must be backed by a registered Slack app ([Slack MCP server docs](https://docs.slack.dev/ai/slack-mcp-server/), checked October 2026).

So the native tooling is real, not a gap in capability. The gap is scope. Anthropic's own documentation specifies that connector permissions govern connectors an organization has added under Organization settings, not connectors a member runs locally on their own machine ([Anthropic, custom roles](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans), checked October 2026). If the same company also runs ChatGPT and Cursor against Slack, the equivalent rules get written three times, in three consoles, by three different people. They drift the first time one of the three is changed without the other two being updated.

**Claude's native settings are the right call when all three are true:** the company uses Claude and nothing else, every person authenticates with their own Slack account, and nobody needs a unified record of Slack calls alongside calls to Jira, Zendesk or a CRM.

## Serving Slack to Claude, ChatGPT and Cursor from one address

Elaichi serves MCP at one endpoint, `https://api.elaichi.ai/mcp`, identical for every organization. Claude, ChatGPT, Cursor and Microsoft Copilot all authenticate to it over OAuth. Which organization, which person, and which tools a client reaches is determined by the grant behind its token, not by the URL. The same address is therefore correct for every client and every org.

In practice: in Claude the address is added as a custom connector; in ChatGPT a workspace admin adds it as a custom MCP app; in Cursor it is a remote server entry with a `url` field. Clients register themselves through OAuth dynamic client registration with PKCE and S256, so there is no client ID or secret for IT to distribute or rotate. Each person connects their client once and approves their own grant on Elaichi's consent screen. That token is re-validated on every request, so disconnecting an app stops it on its next call rather than at some later sync.

Slack access is the second half, and the mechanism is unchanged from the native case. Each person connects Slack with their own Slack sign-in. The resulting credential is stored in Elaichi's separate credential service rather than inside the AI client's own storage. Elaichi's catalog carries two kinds of Slack-adjacent connector: those Elaichi authors and runs itself, which are most of the catalog, and native MCP connectors, where the vendor runs its own MCP server and Elaichi sits in front of it for sign-in, access control and audit.

The rollout is four steps for IT and one for each employee:

1. Publish `https://api.elaichi.ai/mcp` to the company, with per-client setup instructions (Elaichi's web app shows this address with a copy button under Connect your AI client).
2. Write the Slack restrictions on each role before anyone connects, not after.
3. Have each person add Elaichi to Claude, approve the consent screen, then add their own Slack connection under Connections.
4. Check Governance, Audit log after the first week to confirm the restrictions are actually firing as written.

For per-client mechanics, see [connect Elaichi to Claude](/blog/connect-elaichi-to-claude/). ChatGPT and Cursor follow the same four-step shape with different menu paths.

## Blocking Slack tools that post or delete, role by role

In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A company-wide posture is written as a rule on each role that should not post, not as one global switch.

For Slack, the common pattern is a block rule on the default Member role. It names every tool that sends a message or removes one, leaving read tools untouched. A block rule carries no implicit allowlist: every tool it doesn't name stays reachable. Blocking `create_a_slack_chat` alone does nothing to `create_a_slack_bot_message`, `update_a_slack_chat_by_id`, `update_a_slack_bot_message_by_id`, `delete_a_slack_chat_by_id` or `delete_a_slack_bot_message_by_id`. Each has to be named. File upload runs through three tools of its own, `slack_files_get_upload_url_external`, `create_a_slack_file` and `slack_files_complete_upload_external`, and each is a separate name on the rule. See [MCP tool allowlist vs blocklist](/blog/allowlist-vs-blocklist-mcp-tools/) before deciding which direction to write the rule.

Three mechanics matter here:

- **Blocks match the operation, not the display label.** Elaichi stores each named tool's underlying operation when a rule is saved, and the block matches by name or by operation. Renaming a tool inside a toolbox does not let it slip past an existing block.
- **A member-level block can only narrow, never loosen, the role.** A member holds exactly one role. A rule aimed at that one member can restrict further than their role allows, but cannot grant something the role denies.
- **A change is not instant.** A role, team, restriction or grant change takes effect about two minutes.

When a restricted tool is called, Claude is not left to guess why. Elaichi refuses in-band and states whether the block comes from the caller's role or their individual account. It adds that an admin can lift it via an access request, without naming the specific rule or who authored it. The caller can file that request from inside the chat, and an admin resolves it in Governance, Access requests. No AI client, including Claude itself, can approve its own access request.

On Slack's message-posting tools, Elaichi strips the sender-spoofing fields `username`, `icon_url`, `icon_emoji` and `as_user` from every call, on every token. A caller cannot post under a different display name or avatar than their own. This closes one impersonation vector. It is not a substitute for blocking the posting tools outright on roles that have no legitimate reason to post.

## What happens to Slack access when somebody leaves

In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. That includes a suspension made through a SCIM deprovision from an identity provider. Reactivating the account later does not restore the old grants: the person has to consent again from scratch.

Their Slack *connections* are a separate decision the removal flow forces IT to make explicitly, rather than leaving as a dangling credential. The offboarding preflight lists every connection the departing member owns and every toolbox entry that pins one of their connections. A shared connection can be transferred to another active member. A private connection nothing else depends on is deleted along with the member. Transfer only rewrites ownership of the Elaichi record. A transferred connection still authenticates to Slack as whichever account was originally signed in when the connection was created. The Slack account itself has to be deprovisioned separately, in Slack or in the identity provider that feeds Slack via SCIM.

Deleting a connection deletes Elaichi's stored credential for it. Elaichi does not call Slack's API to revoke the token on deletion. It stays valid at Slack until it expires on its own schedule or someone revokes it from the Slack admin console directly. Toolbox entries the departing member had pinned stop resolving the moment they're gone, until someone with edit access re-pins them to a different connection. [Offboarding AI access](/blog/offboarding-when-the-agent-holds-access/) covers the full estate beyond Slack.

## What the audit log records when Claude calls Slack

In Elaichi, one entry for each connected-tool call that reaches execution (a call refused earlier writes none). The same entry records the toolbox the call went through, the tool's advertised name and catalog name, its classification, how approval was given, the surface the call came from, the outcome, and the specific object the call touched. Argument values are not recorded, with one exception. The path argument that names the object acted on, such as the channel ID, is kept. An admin can then answer "which channel did this touch" without having full argument payloads sitting in the log.

Two fields do most of the work when reconstructing an incident later:

- **Surface** distinguishes a call made from an AI client (`mcp`) from one made directly in the Elaichi console or via the API. A call from Claude is recorded against the OAuth client's registered id, and the console resolves that id to a display name on read. Only seven clients are shown as independently verified by Elaichi, Claude among them. Any other client's entry displays the name it self-reported at registration, flagged accordingly.
- **Outcome** records whether the call succeeded or failed.

Some events never become log rows at all. A call a restriction withholds writes no entry, a missing-scope refusal writes nothing, and tool listing and search calls are not audited. The log answers "what ran," not "what was attempted and refused." Refusal reasons are surfaced to the caller in-chat but are not separately queryable audit entries.

Access to the log itself is role-gated. Every member can read *some* of it. With `audit:view`, held by Org Owner, Org Admin and Auditor by default, a member reads every event in the organization. Without it, a member reads only their own events plus events on connections they personally own or can edit. Elaichi retains 90 days of audit history natively. Forwarding to an external log service is a Black-plan feature, with Datadog as the supported destination. See [sending audit logs to Datadog](/blog/elaichi-datadog-audit-logs/) for the field mapping.

The structural reason to route Slack through one plane rather than three vendor consoles is this single log. One organization has one audit log across every connector. A Slack post and a Zendesk ticket update sit in the same queryable list, instead of three separate exports that have to be reconciled by hand. [What an AI agent audit log must capture](/blog/what-an-ai-audit-log-must-capture/) is a vendor-neutral checklist to run against any tool making this claim, including this one.

## When you should not do any of this

Suppose the company uses Claude only, has on the order of twenty people, and every one of them connects their own Slack account. Anthropic's native connector settings plus Slack's own workspace-level app approval are then a reasonable stopping point. You get per-person identity, admin approval of the connector at the org level, and per-tool permission states (Always allow, Needs approval, Blocked). You add no vendor and no second console to maintain.

The case for a control plane starts at a specific inflection point. The second AI client arrives and needs the same Slack policy enforced. Or someone asks for every AI action taken across Slack, Jira and a CRM in one list, and the honest answer is "that requires three exports and a spreadsheet." Below that point, a third-party layer is overhead, not protection.

For the general version of this tradeoff, not specific to Slack, [Claude and ChatGPT Enterprise connectors vs an MCP gateway](/blog/elaichi-vs-native-ai-connectors/) makes the comparison directly. [The first-week governance checklist](/blog/first-week-governance-checklist/) sets the order to do things in. The [Slack connector](/connectors/slack/) itself sits in Elaichi's [connector catalog](/connectors/).

## FAQ

### Does each employee need their own Slack account connected, or can IT share one?

Both work, and they behave differently. In Elaichi, every call through a connection uses the Slack account that connection was made with, whoever is calling, so a connection shared with a team acts in Slack as its owner. For a company-wide rollout, have each person connect their own Slack account, so Claude reaches only what that person can already see and the audit entry names them. A single shared connection suits a narrow job, such as posting status to one channel, where one fixed identity is the point.

### Can I stop Claude from posting to Slack channels for most of the company?

Yes, with a restriction in Elaichi. A restriction targets a role or one member, not a team or the whole organization, so a company-wide posture is written as a rule on each role that should not post. A block rule naming Slack's posting and deleting tools, such as create_a_slack_chat, create_a_slack_bot_message, delete_a_slack_chat_by_id and delete_a_slack_bot_message_by_id, leaves every other tool reachable, so each tool you want blocked has to be named. Blocks match the operation a tool performs as well as its name, so renaming a tool does not get past the rule, and a change takes effect about two minutes.

### What does Elaichi record when Claude calls a Slack tool?

In Elaichi, one entry for each connected-tool call that reaches execution (a call refused earlier writes none). The entry also records the tool's advertised and catalog names, the tool's classification, how approval was given, the surface the call came from, whether it succeeded or failed, and what the call touched. Calls refused before execution, such as a tool a restriction withholds, write no entry, so the log answers what ran rather than what was attempted. Elaichi keeps 90 days of audit history.

### What happens to a Slack connection when the employee who created it leaves?

In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. Their connections are handled during offboarding: a shared connection can be transferred to another active member, and a private one that nothing else depends on is deleted. A transfer rewrites only who owns the connection, so it still acts in Slack as the account that was signed in when it was connected. Deleting the connection deletes Elaichi's stored credential, and the token stays valid at Slack until it expires or is revoked there.

### Do Claude, ChatGPT and Cursor each need a different Elaichi address for Slack?

No. Elaichi serves MCP at one endpoint, https://api.elaichi.ai/mcp, the same address for every organization and every client. Which organization, person and tools a client reaches comes from the OAuth grant behind its token, not from the URL. Each person still connects their client once and approves their own grant, and lists or disconnects those grants under Settings, Connected apps.

## Read next

- [Microsoft Teams MCP access for ChatGPT: a playbook](/blog/connect-microsoft-teams-to-chatgpt-for-our-company/) — Microsoft Teams MCP access for ChatGPT: pick the route, set restrictions on the Microsoft apps around it, then prove them in the audit log.
- [Notion MCP access for Claude, per person](/blog/connect-notion-to-claude-without-private-pages/) — Set up Notion MCP access for Claude so each person reaches only the pages they can already open, with write tools blocked for read-only roles.
- [Salesforce MCP access for Claude, per rep](/blog/connect-salesforce-to-claude-per-rep/) — Give each rep Salesforce MCP access for Claude under their own login, block the delete tools, and cut access off cleanly when they leave.