# Slack MCP access for ChatGPT: a safe company rollout > Two restrictions, one guard you do not configure, and one audit query: Slack MCP access for ChatGPT, rolled out company-wide. **TL;DR** To connect Slack to ChatGPT for the whole company safely, an admin publishes Elaichi once in ChatGPT. Each employee then signs in with their own grant. Two restrictions written on each role do the work the consent screen cannot. One blocks Slack's deleting and administering tools; the other holds the role to what its job needs. Elaichi also strips Slack's sender fields from every posting call, so nothing posts under someone else's name. Every call that runs lands in the audit log under the Assistant category. ## Why Slack in ChatGPT goes wrong before it goes right A Slack mistake is public. One wrong call posts into a channel everyone reads, or deletes a message somebody needed, and it happens in seconds. Setting up Slack MCP access for ChatGPT across a whole company is not the job of wiring up a CRM for four people. The blast radius is the company, not a record. Elaichi serves MCP at one endpoint, POST https://api.elaichi.ai/mcp, and the same address serves every organization. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Which organization and which person a client reaches comes from the OAuth grant behind the token, not from the URL. A grant is the standing permission one person gives one named AI client after signing in and approving Elaichi's consent screen. So the rollout has a fixed shape. An admin publishes Elaichi once inside ChatGPT. Each employee signs in once as themselves. The rules that decide which Slack tools they can run live in Elaichi, written on their role. ## What the ChatGPT admin controls actually cover OpenAI's workspace controls decide whether the Elaichi app exists for your people, and when ChatGPT asks before acting. They do not decide which Slack tool runs. On ChatGPT Business, only admins and owners can enable developer mode and deploy a custom MCP app. The app is created at Workspace settings, Apps, Create. An admin publishes it at Workspace settings, Apps, Drafts, Publish. It then shows in users' Apps settings with the label custom ([OpenAI's developer mode and MCP apps page](https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt), checked October 2026). On Enterprise and Edu, admins can use role-based access control to give developer mode to selected members. Those members then create apps from their own settings (same page, checked October 2026). ChatGPT also carries a permission setting per app: Always ask, Allow read actions, Allow low-risk actions and Allow all actions ([OpenAI's app permissions article](https://help.openai.com/en/articles/20001495-managing-app-permissions-in-chatgpt), checked October 2026). This is where teams get caught. Elaichi never lists a connected tool by name, however few there are; a model finds them with search_tools and runs them with execute_tool. Any per-tool control in any client therefore sees one execute_tool, not "post a Slack message". A read-actions setting on the Elaichi app does not make Slack read-only. If you also run native ChatGPT connectors, the admin side of that is covered in the guide on [restricting ChatGPT Enterprise connectors](/blog/restrict-chatgpt-enterprise-connectors/). ## Slack's own MCP server, or one governed endpoint? If Slack is the only app you want inside ChatGPT, use Slack's own MCP server and skip the rest. Slack hosts it at https://mcp.slack.com/mcp, and workspace admins approve and manage every MCP client integration. A connecting client must be backed by a registered Slack app using confidential OAuth ([Slack's MCP server docs](https://docs.slack.dev/ai/slack-mcp-server/), checked October 2026). One vendor, one admin screen, nothing more to buy. The same logic applies to other vendors' servers, and [running a vendor MCP server through Elaichi](/blog/vendor-mcp-servers-through-elaichi/) is a choice, not a requirement. The argument for one governed endpoint starts at app number two. Elaichi's catalog holds 650+ connectors, [Slack](/connectors/slack/) among them, and the same address serves Claude, ChatGPT and Cursor. One restriction model covers every app rather than one per vendor console. One audit log answers "what did AI do last week" across all of them. One removal ends a leaver's reach everywhere, because removing a member revokes their grants and their clients fail on the next call. If you are still at one app, the honest read is in [when you do not need an MCP gateway yet](/blog/when-you-dont-need-an-mcp-gateway/). ## How do you set up Slack MCP access for ChatGPT? Do the governance before the rollout, because the consent screen cannot hold a client to reading. "Run your connected tools" covers every tier of connected tool, writes and deletes included. The "Delete data and remove access" checkbox governs Elaichi's own data, not Slack's. 1. Connect Slack in Elaichi. Each person connecting their own Slack account keeps their own channel membership. A shared connection runs every caller's call on its owner's Slack account, so pick deliberately. 2. Write the block rule on each role that can run tools. 3. Write the allow rules, if the role should be held to a named set. 4. Publish Elaichi as a custom app in ChatGPT, using the steps in the [ChatGPT connection guide](/blog/connect-elaichi-to-chatgpt/). 5. Have each employee sign in and approve their own grant. 6. Run the audit query a week later and read what actually ran. Restrictions come with the Gold plan. Reading them needs the restriction:view permission and writing them needs restriction:manage, which among the built-in roles only Org Owner and Org Admin hold. ## Restriction 1: block the Slack tools that delete and administer Start with blocks, because a layer with only block rules has no allowlist: everything the rules do not name still passes. That makes a block the light instrument, and the right one for a first rollout. Open the Slack connector in the console and read its tool list. Name every tool that deletes a message or administers the workspace, as connector and tool-name pairs. Elaichi looks each name up in your catalog when you save the rule and refuses a name it cannot find. It stores the tool's operation beside the name. A block rule then matches on the name or the operation, so renaming a tool later does not slip it past the block. Allow rules behave differently, which is the subject of [why blocks match tool names but allows do not](/blog/block-matches-name-allow-matches-operation/). One thing to plan for: restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. For a whole company, write the rule on each role that holds tool:execute. Among the built-in roles that is Org Owner, Org Admin, People Admin, Team Admin and Member. Guest, Billing Admin and Auditor cannot run tools at all. A restriction change reaches every surface in about two minutes. ## Restriction 2: hold a role to the tools its job needs Use an allow rule when a role should reach a short, named list rather than everything minus a few. The trap is scope. Once a role carries any allow rule, every connector and tool that none of its allow rules names is blocked for that role. That holds across your whole catalog, not just Slack. An allow rule naming nothing blocks everything for its target. So a support role allowed a handful of Slack tools also needs whole-connector allow rules for each other app it uses. Those can be separate rules. Allow rules match only the operation Elaichi pinned when you saved them, never the tool's label. Restricted tools are not hidden. A person's search returns the restricted matches by name, flagged, with no schema and no way to call them. The refusal tells them to ask an admin. From the client they can file their own access request. Nobody can approve it from a chat: an admin resolves it in the console under Governance, Access requests, after confirming their identity. Approving creates an access grant for that one person and leaves the role's rules untouched, so nobody else's access changes. If a team only ever posts to one channel, lock the channel argument on a toolbox entry instead of trusting the model. The walkthrough is in [posting to one Slack channel from Claude](/blog/it-team-claude-slack-messaging/). Locked values hold only on calls through that entry, so keep the connection unshared and share the toolbox at use. ## The control you do not have to configure: Slack sender fields Elaichi drops the caller's username, icon_url, icon_emoji and as_user arguments on the five Slack methods that post under a sender name. The drop happens before anything reads them. It applies to every call and every token, even a bot token that still holds Slack's chat:write.customize scope. Nothing reaching Slack through Elaichi can post under another person's name or avatar. The drop is keyed on which Slack wire method the entry resolves to, not on a connector slug. A fork, an organization-owned connector shadowing slack, a custom connector aimed at slack.com, or a renamed resource are all covered the same way. For the same reason, a toolbox or template entry cannot freeze or default those four sender fields; the write is refused. That removes the single most alarming Slack failure from your rules list. It does not remove the ordinary ones, which is what the two restrictions are for. For the general case of locking an argument so a model cannot move it, see [locking AI agent tool arguments](/blog/frozen-parameters-wire-transfer-receiver/). ## Which audit query proves the restrictions hold? In the console audit log, set Category to Assistant, set the date range, and search slack. Connected-tool calls sit in the Assistant category because their action is assistant.toolbox_tool. Filtering to MCP shows client grants, not tool calls. This is the single most common wrong query. Each row's detail panel opens with where the call ran. Then comes who did what to which item through which connection, for example a line beginning "Using ChatGPT,". The panel also carries Connector, Connection, Ran from, What it did (Read data, Changed data or Deleted data), Approval and Outcome. The client name is resolved when you read the log. ChatGPT is one of the clients Elaichi can mark verified from its registered redirect address. A lookalike shows the name it registered for itself, flagged as self-reported. You can export the current view as CSV, up to 10,000 entries, with the filters applied. One honest limit. A call a restriction refuses before execution writes no audit row, so the log proves what ran, not what was stopped. The evidence that the rule existed is the restriction.created and restriction.updated entries, which free-text search will find by action name. Org-wide reading needs the audit:view permission, held by Org Owner, Org Admin and the free Auditor role. Everyone else sees their own events plus events on connections they own or can edit. Elaichi keeps 90 days of audit history, and export to your own Datadog comes with the Black plan, which is launching soon. What a row should contain in the first place is covered in [what an AI agent audit log must capture](/blog/what-an-ai-audit-log-must-capture/). ## What this setup does not do Elaichi has no per-call approval over MCP. The grant is the approval: the person chose those scopes for that named client on Elaichi's own consent screen. Any confirmation an employee sees in ChatGPT is ChatGPT's own prompt, governed by its app permission setting. Prompt injection is not something Elaichi screens for on the path a remote client uses. The in-app Agent checks tool results for it, and that check cannot be moved onto the server a client calls. A tools/call carries a tool name and arguments, never the person's typed request, so there is nothing to judge the call against. That defense belongs to the client. A person can widen their own toolbox choice later under Settings, Connected apps, so consent-time toolbox picking is not an admin control; restrictions are. Removing someone from Elaichi ends their reach through Elaichi, not their Slack account. That account still has to be deprovisioned in Slack or through your identity provider. The same company-wide messaging rollout for [Microsoft Teams in ChatGPT](/blog/connect-microsoft-teams-to-chatgpt-for-our-company/) runs on the same three steps. For the model underneath all of this, roles then restrictions then grants, start with [MCP governance](/blog/mcp-governance/). The [governance use case](/use-cases/governance/) shows the shape of a rollout. The [connector catalog](/connectors/) lists the other apps these same rules reach. ## FAQ ### Can ChatGPT post to Slack as a specific employee through Elaichi? No. Elaichi drops the caller's username, icon_url, icon_emoji and as_user arguments on the five Slack methods that post under a sender name. The drop happens before anything reads them, for every call and every token. That holds even on a bot token that still carries Slack's chat:write.customize scope. A toolbox entry cannot set those fields either; the write is refused. ### Does setting the Elaichi app to read actions in ChatGPT make Slack read-only? No. Elaichi never lists a connected tool by name, so a client's per-tool permission sees one execute_tool rather than individual Slack tools. ChatGPT's own permission options are Always ask, Allow read actions, Allow low-risk actions and Allow all actions ([OpenAI's app permissions article](https://help.openai.com/en/articles/20001495-managing-app-permissions-in-chatgpt), checked October 2026). To hold a role to reads, write the restriction in Elaichi instead. ### How long does a new Slack restriction take to apply? Within about two minutes. Role, team, restriction and access-grant changes are resolved per request and reach every surface once the change has propagated. Some changes are faster. Revoking a grant, removing a member or suspending one stops their AI clients on the next call. So does revoking a share or disconnecting an account. ### Where do Slack tool calls appear in Elaichi's audit log? Under the Assistant category, because a connected-tool call is recorded as assistant.toolbox_tool. Filtering the audit log to MCP shows client grants and OAuth events, not tool calls. Each row carries the person, the tool, the connector, the connection, the MCP client, what the call touched and whether it succeeded. ### Do we still need Slack's own MCP server if we use Elaichi? Not for Slack access through Elaichi, which runs its own Slack connector. Slack hosts its own MCP server at https://mcp.slack.com/mcp. There, workspace admins approve each MCP client integration, and clients must be backed by a registered Slack app using confidential OAuth ([Slack's MCP server docs](https://docs.slack.dev/ai/slack-mcp-server/), checked October 2026). If Slack is the only app you want inside ChatGPT, that path needs no second vendor. ## Read next - [Let IT post to one Slack channel from Claude](/blog/it-team-claude-slack-messaging/) — IT can post to one Slack channel from Claude when Elaichi freezes the channel argument. Channel reads stay open, and opening DMs is restricted for the role. - [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. - [Connect Elaichi to ChatGPT](/blog/connect-elaichi-to-chatgpt/) — To connect Elaichi to ChatGPT, a workspace admin adds one MCP endpoint as a custom app and each person signs in with OAuth. No API key, no per-user URL.