Rolling out ChatGPT in Slack and Microsoft Teams with approvals
This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.
ChatGPT in Slack and Microsoft Teams puts an @ChatGPT agent into channels, threads and direct messages, where it can summarize, draft and act through tools your admin connects. OpenAI launched it for Business and Enterprise workspaces at DevDay on 29 September 2026, and the admin setup guide describes a deployment with shared company access. That shared access is the governance question. The agent acts with the permissions of the company accounts you connect, not with the permissions of the person who typed the mention.
This guide is for engineering and IT leads deciding whether to switch it on, for whom, and with which controls. The same questions apply to any agent that lives in chat, whichever coding tool your team uses underneath.
Who ChatGPT in Slack and Microsoft Teams is for
It fits teams where work already starts in a thread: incident channels, bug reports, launch coordination. Teammates can add context without an individual ChatGPT license, so the person who reports a problem does not need a seat. OpenAI's feature page also describes investigating a bug, reviewing the approach with the team and opening a pull request from the same conversation, when Codex Cloud delegation is enabled.
It is a poorer fit where channels mix internal staff with outside parties. Slack Connect channels shared with another organization are not supported for the coding flow. At launch, @ChatGPT does not include memory or use anyone's ChatGPT memories, so it will not carry conventions from one conversation to the next.
Four owners to name before setup
OpenAI's guide assigns responsibilities before anything is installed. Put a name against each row.
| Owner | Responsibility in the docs | Question they answer |
|---|---|---|
| ChatGPT workspace admin or owner | Connect the platform, create the surface, choose its plugins and workspace connections | What can @ChatGPT reach from this surface? |
| Slack or Teams admin | Approve permissions and install the app; Teams admins also manage audience and consent | Who in the messaging platform can use it? |
| Connection owner | Prepare approved company accounts and verify their resource and action permissions | What can each connected account read and change? |
| Pilot owner | Define the audience and conversations to test, including people who should not have access | Did the boundaries hold in practice? |
A surface defines where @ChatGPT is available and which tools it can use. Slack needs one surface per Slack workspace, including each connected workspace in Enterprise Grid. Setup starts in the OpenAI admin console under Agents.
Shared company access versus personal access
This is the decision that needs the most care. The docs separate two kinds of access:
- Shared company access. Surface plugins use the configured company account's permissions. Members do not each authenticate the shared account, and those permissions may differ from what participants can reach personally.
- Personal access. Where supported, using plugins connected in ChatGPT requires separate authorization. @ChatGPT does not inherit a person's file, app or private-channel access.
The consequence is plain. Anyone who can use the surface can use the tools and data behind its connections. If a connected company account can read every project in your tracker, so can every person in the pilot channel, through the agent. Choose connections as if you were adding the whole audience to that account.
Replies are shared too. A response in a channel is visible to its participants, and a private approval card does not make the channel reply private.
Where approval happens before action
OpenAI says @ChatGPT asks for approval before acting in connected tools. For coding work, the requester sees a private card with Allow and Deny before a task runs. The coding task then runs as the requesting user, so their repository access still applies. The feature page lists audit logs, monitoring, and a central console for agents, spend and plugins.
Those controls help only if someone reads them. Decide in advance:
- Which write or send actions are enabled, and in which destinations.
- Who reviews audit logs, and how often.
- Who can change a surface's connections, and what re-validation follows a change.
- What happens to a surface and its connections when its owner leaves.
A pilot plan with validation checks
The docs recommend validating access boundaries with approved test data before expanding access. A pilot that follows that advice looks like this:
- Create the surface with Selected channels only and add two or three approved channels.
- Test a request in an approved channel, an excluded channel, and a direct message. Channel restrictions do not block direct messages.
- For Teams, test an assigned and an unassigned user.
- Add one read-only company connection. Verify the acting account, what it can reach, and who can see the replies.
- Add write or send actions only after the read-only checks pass, and test them in an approved destination.
- If you already run the older ChatGPT app in Slack, have a Slack admin approve the extra permissions. Existing installations will not stop working immediately at launch.
Repeat the relevant checks after every permission or connection change.
What to measure during the pilot
Count the requests that ended in a useful result without a follow-up correction. Record every case where a reply exposed information the channel should not have seen, even a minor one. Track approval cards that people denied, because each one tells you an action was wrong or unclear. For coding requests, track how many results reached a merged pull request after review. Tool activity alone is adoption data. Our guide to measuring an AI workflow before scaling it explains why.
The review model underneath is the one we teach in Delegate, Review, Own: chat is where you delegate, the approval card and the diff are where you review, and a named person owns what ships.
Before you install anything, write the four owner names and the two pilot channels on one page and get each owner to agree.