Connect Slack to Claude, ChatGPT and Cursor with Governed Access

Twenty-three. That is how many tools the Slack connector puts on the table, a small enough number to look like a solved problem. It is not. Slack is where a company argues with itself: the escalation channel, the incident thread, the deal room, the announcement somebody will quote back at you a year later. All twenty-three tools reach all of that through one credential. One posts. One deletes. Several read entire channel histories. One returns the workspace access logs. A security engineer reading that list does not count twenty-three features, they count twenty-three ways for an agent to act with an employee's name attached.

The tension sits inside the number. Twenty-three is too few to govern by handing people a shorter menu, because the short menu still contains history reads and still contains a delete. Subsetting is not the lever here. Resolution is: deciding, for each person and each team, which tools appear at all, what arguments they are allowed to carry, and whose Slack access the call is measured against when it actually runs.

Who inside the company actually reaches into Slack

Six groups touch Slack every day and each means something different by the word.

Support lives in escalation channels and the replies underneath them. Their unit of work is the thread: what the customer said, what the on-call engineer answered, whether anyone closed the loop. Engineering occupies incident channels, where the same data shape carries different sensitivity, because an incident thread routinely contains hostnames, stack traces and a blunt internal assessment nobody wants repeated outside the room. Sales runs deal rooms and shared customer channels, and their messages are commercial: a price under discussion, a competitor named, a renewal wobbling. Marketing works in announcement channels and mostly wants to post rather than read. People Ops queries users instead of messages, asking who is in the workspace, who was deactivated, which account belongs to which email address. IT Admin wants billable info and access logs, meaning seat counts and sign-in origins rather than anything anyone said.

Four record types sit underneath all six: messages, channels, conversations and users. That is exactly the difficulty. A tool that reads conversation history serves Support, Engineering and Sales identically at the protocol level while meaning three quite different exposures in practice. Slack's native permission model is channel membership, which is coarse by design: if you are in the channel, you read the channel and everything in it. An agent pointed at Slack inherits that reach wholesale unless something narrower stands in front of it. Each department needs a different shape of reach over the same four record types, not a different workspace.

Registering the application, then making the connection

Slack authorises over OAuth, and this connector is bring-your-own-application. Before anybody in your organisation can connect Slack at all, the organisation registers its own OAuth application with Slack. That is a prerequisite rather than an optional hardening step, and it requires the connector:manage permission, so it belongs to an administrator rather than to the first enthusiastic person who opens the product. You register once, for the whole company.

Then the connection. Go to Connections, choose Add connection, pick Slack, decide Share with before you commit, then press Connect. Slack's authorisation window opens at that point. Whatever the approver grants there bounds the connection permanently. Nothing inside Elaichi widens it later, and every control in the product is subtraction from that ceiling.

Which turns the identity of the approver into the first governance decision you make. If a workspace administrator authorises with their full reach, every tool call resolving through that connection can in principle touch everything that administrator can touch, including private channels they happen to sit in. If a deliberately narrow account authorises instead, the ceiling is lower and stays lower. When it completes you land on Connection added.

Sharing is the other half of the same decision. A connection is shared with a member, a team, or everyone, at View, Use, or Edit. View lets somebody see it without running anything through it. Edit hands over its settings and its sharing. Use is the grade that does the real work in a Slack rollout: somebody can run tools against a connection they cannot open, cannot edit, cannot transfer and will never find listed, which lets a whole department operate through a connection exactly one person holds. That delegation is re-checked against the holder every time it resolves, so the day the holder loses their own Slack access, everyone borrowing it loses theirs in the same motion.

Which tools anybody should see, split by read and by write

Sort the twenty-three by what they do to the workspace, not by which team asked for them.

The reads divide further into message reads and metadata reads, and that difference matters more than the shared label suggests. list_all_slack_conversations enumerates channels, which is close to harmless. list_all_slack_conversation_history and list_all_slack_conversation_replies return what people actually wrote, which is not. list_all_slack_search is the widest of the lot, because one query crosses every channel the credential can see and surfaces content the caller would never have thought to open. Treat search as its own category when you decide who gets it. The metadata reads are a different animal: list_all_slack_users and get_single_slack_user_by_id answer directory questions, list_all_slack_lookup_by_email resolves an address to an account, and list_all_slack_me confirms whose credential is in play. list_all_slack_team_access_logs, list_all_slack_team_billable_info and get_single_slack_team_billable_info_by_id are administrative telemetry about the workspace rather than anything said inside it, and they belong to IT Admin.

The writes are fewer and each is a deliberate grant. create_a_slack_chat posts a message. update_a_slack_chat_by_id edits one that already exists, including one it did not write. create_a_slack_conversations_open opens a direct conversation, which is how an agent starts talking to a human who never asked it to. create_a_slack_file puts a file into the workspace. slack_conversations_join deserves singling out, because joining a channel is the one write that quietly enlarges what every subsequent read can see.

Then delete_a_slack_chat_by_id, which removes a message. That has no undo and leaves a visible gap in a conversation other people rely on. The defensible default is that it appears in no toolbox, and that if some workflow genuinely needs it, it lives in one toolbox owned by the team that can be paged about the consequences.

Composing a toolbox for each team

Build the definition once, then bind it. A template holds tool entries and their overrides and no connections. A toolbox is connection-bound, and a toolbox is what an MCP client actually talks to. Stamping a template produces a toolbox and attaches connections to its entries; anything left unattached shows as needs connection, which is a useful rollout signal rather than an error. Entry lists cap at 200, which the Slack catalogue comes nowhere near, so the cap only matters once a toolbox mixes Slack with several other products.

For Support: a template carrying list_all_slack_conversations, list_all_slack_conversation_history and list_all_slack_conversation_replies, plus create_a_slack_chat so a summary can go back into the thread it came from. Stamp it, bind the Slack connection, share the result with the Support team at Use. Ask it to summarise the last fifty messages in an escalation channel and it has precisely what it needs.

Engineering gets the same reads plus slack_conversations_join, so an incident agent can pull itself into a channel created twenty seconds ago. Marketing gets create_a_slack_chat with the channel pinned as a frozen parameter and list_all_slack_conversations to confirm the post landed. People Ops gets list_all_slack_users, get_single_slack_user_by_id and list_all_slack_lookup_by_email, and no message tool of any kind. IT Admin gets list_all_slack_team_access_logs and the billable info pair. Sales EMEA gets the Support read set bound to the same connection and shared with its own team.

Stamping copies. Editing a template afterwards does not reach back into toolboxes already produced from it, so when Support's definition changes, the Support toolbox needs a fresh stamp.

Governing Slack from the role outward

Start at roles: a role is what a person carries into every screen and every call. Eight are predefined: Org Owner, Org Admin, People Admin, Team Admin and Member consume a billable seat, while Guest, Billing Admin and Auditor do not. A member holds exactly one. Custom roles are always billable. Underneath sit 38 permissions in 13 groups, of which connector:create carries a high-trust flag, because a custom connector can be aimed at any destination and no restriction constrains it afterwards.

Auditor is the role to notice first here. It is free, so a security engineer can hold a permanent read-only seat over what is happening without consuming a paid one and without acquiring administrative power to get it.

Restrictions layer on top. Each is an allow-list or a block-list across connectors and individual tools, and each targets either a role or one named member. There is no organisation-wide restriction, so a blanket rule is expressed against the Member role. A member-level restriction replaces the role's rather than combining with it, which is why authoring one sits behind its own permission: it is an override, not an addition. Rules are enforced at four points, at connect time, when tools are listed, when one is called, and on the outbound request, and they are evaluated against the original catalogue tool name, so renaming an entry to something friendlier cannot slip past them. An allow rule naming nothing denies everything, which is the tightest statement the system can make.

Concretely: block delete_a_slack_chat_by_id for the Member role, and block list_all_slack_search for roles whose work never requires crossing channels.

State the timing exactly. Every call is re-evaluated, but role and restriction changes read a snapshot that can be up to roughly a minute stale, two at worst. Revoking a share, disconnecting the account, or removing the member takes effect on the next request with no such lag. To stop something immediately, revoke or disconnect rather than editing a rule.

One endpoint for the organisation, resolved per person

There is a single endpoint for the whole organisation, copied out of the Connect your AI client dialog. Setup in each client is manual.

What differs is the person. When somebody signs in at that endpoint, their agent's reach is worked out against their own access rather than against everything the Slack connection could theoretically do. Two people pasting an identical endpoint into an identical client see different tool lists and get different answers to the same prompt, which is the property that makes one endpoint safe to publish on somebody's first day.

Clients ask for consent by scope: Read, Create and change, Delete, and Run tools, with only Read on to begin with. Grant the others deliberately.

There is also a ceiling on advertised tools. Past 30, counting the platform's own operations alongside your connected products, individual names disappear and clients receive search_tools and execute_tool instead. Slack's twenty-three sit under that line alone but cross it as soon as a second product joins. The search behind it ranks lexically rather than semantically, so entry names should read like the words somebody would type.

Connect Slack to Claude

Copy the organisation endpoint from the Connect your AI client dialog. In Claude, open Settings, then Connectors, then Add custom connector, and paste it. On Claude Team and Enterprise only an Owner may add it, so on those plans the rollout is one person adding it centrally rather than every employee doing it themselves. Sign in when prompted and grant only the consent scopes the work needs, remembering Read is the only one on initially. Claude then lists whatever that individual's toolboxes, shares and role resolve to at that moment. A Support user sees the escalation read set. A People Ops user sees directory tools and no messages.

Connect Slack to ChatGPT

In ChatGPT, open Settings and go to Apps, switch developer mode on, choose Create, paste the organisation endpoint, then run Scan tools. This path exists on Business, Enterprise and Edu plans and works on the web client only, so nobody should attempt it from a phone. Consent is requested by scope, with Read on and Create and change, Delete, and Run tools left off until somebody enables them. Because scanning happens at setup, a person later added to a team or granted a new toolbox may need to scan again before the additional Slack tools appear.

Connect Slack to Cursor

Cursor reads configuration from a file rather than a settings screen. Add an entry under mcpServers pointing at the organisation endpoint, either in ~/.cursor/mcp.json for everything that developer works on, or in a repository's own .cursor/mcp.json when the Slack access should travel with one project. This is per-machine, so an engineer with a laptop and a workstation configures it twice and a new machine starts with nothing. Sign-in still resolves to the individual, so the file carries no credential worth protecting and is safe to commit at the repository level if the team wants incident-channel tools available to everyone working there.

Day two, and the things that break

A revoked token or a changed workspace setting surfaces as failing calls rather than a tidy alert, and Reconnect is the repair: it mends the existing connection, so every toolbox entry bound to it keeps working and nobody re-stamps anything.

Offboarding is the case that justifies the whole arrangement. Removing the member cuts their reach off at the next request, without the snapshot lag that role edits carry. If that person held the Slack connection, transfer it before the removal, because everyone using it at the Use grade is borrowing their access.

Access requests handle the middle ground without permanent grants. A Sales lead who needs a customer channel read for one week asks for it rather than being moved to a wider role nobody remembers to take back.

Route the record somewhere a human reads. The audit log covers tool calls, memberships, roles, teams, connections and transfers, toolboxes, shares, restrictions, SSO and SCIM changes, and sign-ins. It is append-only by construction, nothing in the product rewrites or removes a row, and it records the identifier of the Slack record a call created or changed. Arguments and results are deliberately absent, because a message body is customer data and does not belong in a log. It is eventually consistent, so allow a moment before a row appears. Forward it to Datadog, and send notifications to Slack or email.