# Microsoft Teams MCP access for ChatGPT: a playbook

> Microsoft Teams MCP access for ChatGPT: pick the route, set restrictions on the Microsoft apps around it, then prove them in the audit log.

**TL;DR** There are two routes. OpenAI's own documentation lists Microsoft Teams among administrator-managed sync sources, which is a read path. ChatGPT's wider MCP support is in beta on Business, Enterprise and Edu (checked October 2026). Elaichi covers the second half of the job: one endpoint at https://api.elaichi.ai/mcp that ChatGPT signs into. It adds role restrictions on the Microsoft apps around Teams, and one audit log that shows which person ran which tool through which connection.

A request lands in IT: sales wants to ask ChatGPT about a Teams thread from last week. Microsoft Teams MCP access for ChatGPT has two different answers, and which one applies depends on what the team will do next. Reading what was said is one job. Posting into a channel, or reaching the files and sites behind the thread, is a different job with a different failure mode.

This playbook covers both. It gives the route OpenAI documents and the restrictions that stop the obvious failure once the request grows past Teams. It ends with the audit query a reviewer will ask you for.

## Is there an official OpenAI Microsoft Teams integration?

OpenAI documents Microsoft Teams in two places, and neither one gives a department a write path across Teams.

First, OpenAI's administrator-managed sync page says sync sources may include Google Drive, SharePoint and Microsoft Teams, where those options are available for the workspace and its region ([OpenAI](https://help.openai.com/en/articles/10847137-administrator-managed-apps-with-sync-in-chatgpt), checked October 2026). Sync is reading. It brings content in so people can search and ask about it.

Second, Microsoft Teams appears on OpenAI's list of legacy connectors for the Responses API, used through `connector_id` ([OpenAI](https://developers.openai.com/api/docs/guides/tools-connectors-mcp), checked October 2026). That is a developer surface, not something an admin turns on for a sales team.

For anything beyond those, ChatGPT's wider MCP support, including modify and write actions, is rolling out in beta to the Business, Enterprise and Edu plans ([OpenAI](https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt), checked October 2026). On Business, only admins and owners can enable developer mode and deploy a custom MCP app (same page, checked October 2026). OpenAI also says source permissions still apply whichever way an app authorizes access ([OpenAI](https://help.openai.com/en/articles/11509118-admin-controls-security-and-compliance-for-plugins-and-apps), checked October 2026).

## How do you set up Microsoft Teams MCP access for ChatGPT?

Do these five things in this sequence. The order matters, because the restrictions are cheap to write before anyone is using the thing and awkward afterwards.

**1. Separate reading from acting.** Write down the three questions the team actually asks. If all three start with "what did" or "who said", you want a read path. If one of them is "post the summary in the channel", you are designing a write path and the rest of this playbook is the work.

**2. Use OpenAI's own sync for Teams content where it is offered.** Administrator-managed sync may include Microsoft Teams, subject to workspace and region availability ([OpenAI](https://help.openai.com/en/articles/10847137-administrator-managed-apps-with-sync-in-chatgpt), checked October 2026). It needs no second vendor, and it is the honest answer when Teams is the only thing anyone asked for.

**3. Connect ChatGPT once to Elaichi for everything around Teams.** Elaichi serves MCP (Model Context Protocol, the standard AI clients use to call tools) at one address, https://api.elaichi.ai/mcp, the same string for every organization. ChatGPT, Claude and Cursor all sign into that one address with OAuth, and each person approves their own grant. The step-by-step for the ChatGPT side is in [the ChatGPT setup walkthrough](/blog/connect-elaichi-to-chatgpt/).

**4. Check the catalog for the Microsoft apps the team will ask for next.** Elaichi's catalog holds 650+ connectors. Most of them Elaichi authors and runs itself. The rest are native MCP connectors, where the vendor builds and runs the server and Elaichi handles sign-in, access and audit. Browse [the connector catalog](/connectors/) for what you need. Where a connector is not in the catalog, an Org Owner or Org Admin on Gold can add a remote MCP server as the organization's own connector. That puts it under the same restrictions, scopes and audit log. The path is covered in [bringing a vendor's MCP server under your own rules](/blog/vendor-mcp-servers-through-elaichi/).

**5. Write the restrictions, then tell the team.** The next three sections are the ones that matter for a Microsoft stack.

## Restriction one: block the tools that change who can see what

The failure nobody predicts is not a deleted file. It is a sharing change. In Elaichi's [sharepoint connector](/connectors/sharepoint/), five of the 97 tools change who can see what. They are `create_a_sharepoint_site_permission`, `create_a_sharepoint_list_item_permission`, `update_a_sharepoint_drive_item_permission_by_id`, `delete_a_sharepoint_drive_item_permission_by_id` and `sharepoint_drive_item_invite_send`, which sends a sharing invitation.

A block rule naming those five keeps them away from the role. A block rule matches by tool name or by the operation Elaichi pinned when the rule was saved. Renaming a tool cannot slip it past a block. Allow rules behave differently. Read [why blocks match names and allows do not](/blog/block-matches-name-allow-matches-operation/) before you write either kind.

In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A rule for the sales team is therefore written on the role its members hold. Writing one needs the `restriction:manage` permission and the restrictions feature, which Gold and Black both include; a rule aimed at a single member also needs `restriction:override`.

## Restriction two: hold the team to reads without cutting off their other apps

Of the sharepoint connector's 97 tools, 53 are reads and 44 are not. Holding a role to the reads takes one of two shapes, and the second has a trap in it.

Block rules are additive and leave everything they do not name reachable. Blocking some of the write tools leaves the rest callable. To close the whole write surface with blocks, you have to name all 44.

Allow rules close it in one rule, but an allow rule turns on the allowlist for its whole layer the moment it exists. 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 every connector, not just the one you were thinking about. So a role held to SharePoint reads also needs whole-connector allow rules for every other app it uses. An allow rule that names nothing blocks everything for its target.

There is a per-person alternative that needs no rule at all. At Elaichi's consent screen, a person running the ChatGPT connection can choose "Only the ones I pick" and name up to 50 stored toolboxes. If those toolboxes hold only read tools, that grant reaches nothing else, including accounts connected later. Note what does not work: no consent checkbox holds a client to reading a connected app, because "Run your connected tools" covers every tier, and "Delete data and remove access" covers Elaichi's own deletes rather than the app's.

Role, team-membership and restriction changes reach every surface in about two minutes, not instantly. Plan the cutover with that in mind.

## Restriction three: one Microsoft identity per person, not one shared registration

Elaichi's sharepoint connector accepts either a per-person OAuth connection or an OAuth client-credentials connection. The difference decides whose permissions apply.

A per-person OAuth connection calls Microsoft as the person who connected it. A client-credentials connection calls with the app registration's own credentials, so everyone using that connection shares one identity. Every call through a connection uses the account it was connected with, whoever makes the call. A shared connection therefore runs as its owner for all of its grantees.

For a sales or support team, have each person connect their own account. Microsoft's delegated permissions intersect the app's consented permissions with the signed-in user's, so the app never exceeds the user ([Microsoft](https://learn.microsoft.com/en-us/graph/permissions-overview), checked October 2026). The pattern, and when a shared connection is the right call instead, is laid out in [AI agents with employee permissions](/blog/ai-agents-employee-permissions/).

Where one argument must never move, a toolbox entry can lock it. Frozen parameters are merged over the caller's arguments at execution, so the model cannot override them, as described in [locking a tool argument the way a wire locks its payee](/blog/frozen-parameters-wire-transfer-receiver/).

## The audit query that proves the restrictions held

Open the audit log and filter on three things: category **Assistant**, the actor, and the last 7 days.

The category is the part people get wrong. Connected-tool calls, including calls made from ChatGPT, sit in the assistant category, because their action is `assistant.toolbox_tool`. The mcp category holds grant events, such as an MCP client connecting. Filtering to MCP will not show you the tool calls.

Each row records the person, the toolbox the call went through, the tool's advertised and catalog names, the connector and the connection it reached. It also records the tool's classification, how approval was given, the surface, the MCP client's id when the surface is mcp, and the outcome. The console's detail panel renders it as a sentence that opens with where the call ran, for example "Using ChatGPT, Emily Carter updated...". The panel also shows a "What it did" line reading Read data, Changed data or Deleted data. That line is the evidence a reviewer wants.

Two honest limits. A call refused before it reaches execution, for example one a restriction withheld or one missing an OAuth scope, writes no row at all. So the audit log proves what ran; it does not prove what was blocked. For that, filter free text on `restriction` and read the `restriction.created` rows, which record who wrote the rule and when. Second, Elaichi keeps 90 days of audit history; forwarding it to your own Datadog comes with the Black plan, which is launching soon.

Every member can read the audit log at their own scope. With `audit:view`, which Org Owner, Org Admin and Auditor hold, they read every event in the organization. For the fuller field list, see [what an AI agent audit log must capture](/blog/what-an-ai-audit-log-must-capture/).

## When you do not need any of this

If Teams is the only app anyone asked about, and administrator-managed sync is available for your workspace and region, use it and stop. One vendor, one admin surface, no second set of rules to keep current. The same goes if your whole AI footprint is read-only search over one Microsoft source.

Elaichi earns its place at the second and third app. That is when the same team wants SharePoint, a CRM and a ticket queue in the same chat. It is also when restrictions need to differ per role rather than per workspace, and when one reviewer wants a single log across all of it. ChatGPT may still show its own confirmation card before a write, depending on the app permission setting and the action's context ([OpenAI](https://help.openai.com/en/articles/20001495-managing-app-permissions-in-chatgpt), checked October 2026). That is the client's behavior, not a rule you set once for everyone.

For the broader model behind these rules, read [how MCP governance assigns who may do what](/blog/mcp-governance/). For the workspace-side controls in ChatGPT itself, see [restricting ChatGPT Enterprise connectors](/blog/restrict-chatgpt-enterprise-connectors/). For the Claude equivalent of this Microsoft playbook, read [governing SharePoint in Claude](/blog/claude-sharepoint-permissions/). The governance use case is summarized at [/use-cases/governance/](/use-cases/governance/).

## FAQ

### Is there an official OpenAI Microsoft Teams integration for ChatGPT?

OpenAI documents Microsoft Teams in two places. Its administrator-managed sync page lists Google Drive, SharePoint and Microsoft Teams among possible sync sources. Availability depends on the workspace and its region (checked October 2026, https://help.openai.com/en/articles/10847137-administrator-managed-apps-with-sync-in-chatgpt). Microsoft Teams also appears among the legacy connectors for the Responses API, used through connector_id (checked October 2026, https://developers.openai.com/api/docs/guides/tools-connectors-mcp). Sync is a read path; the Responses API connector is a developer surface rather than an admin switch for a department.

### Will ChatGPT show people Teams or SharePoint content they are not allowed to see?

OpenAI says source permissions still apply whichever way an app authorizes access (checked October 2026, https://help.openai.com/en/articles/11509118-admin-controls-security-and-compliance-for-plugins-and-apps). On the Elaichi side, a per-person OAuth connection calls the Microsoft app as the person who connected it, so that person's own permissions apply. A connection shared with a team runs as its owner for everyone it is shared with, which is the case to watch.

### Can a restriction stop ChatGPT from posting a message or changing a sharing setting?

Yes. In Elaichi, a block rule written on a role or on one member keeps the named tools away from that person. The rule matches by tool name or by the operation pinned when it was saved, so renaming a tool does not get past it. The refused call comes back in-band, telling the caller the tool is restricted and that an admin can lift it. A restriction change reaches every surface in about two minutes, not instantly.

### How do I prove in the audit log that ChatGPT only read data?

Filter Elaichi's audit log to the Assistant category, pick the actor and a date range, then open a row. Connected-tool calls from any MCP client sit in the assistant category, not the mcp category. Each row records the person, the tool, the connector, the connection, the MCP client, how approval was given and the outcome. The console's detail panel adds a 'What it did' line reading Read data, Changed data or Deleted data. Elaichi keeps 90 days of audit history.

### What if the Microsoft app we need is not in Elaichi's connector catalog?

An Org Owner or Org Admin on the Gold plan can add a remote MCP server as the organization's own connector. The server must be reachable over public HTTPS. It then falls under the same restrictions, OAuth scopes and audit log as any catalog connector, and members connect it with their own sign-in. Creating one needs the connector:create permission, which among the built-in roles only Org Owner and Org Admin hold.

## Read next

- [Slack MCP access for ChatGPT: a safe company rollout](/blog/connect-slack-to-chatgpt-for-the-whole-company-safely/) — Two restrictions, one guard you do not configure, and one audit query: Slack MCP access for ChatGPT, rolled out company-wide.
- [Connect Ashby to ChatGPT for recruiters](/blog/connect-ashby-to-chatgpt-for-recruiters/) — Connect Ashby to ChatGPT for recruiters with two restriction rules that hold the role to reads, plus the audit query that proves nothing was changed.
- [Connect Linear to Claude for our product team](/blog/connect-linear-to-claude-for-our-product-team/) — To connect Linear to Claude for our product team, govern Linear's own MCP server: per-person sign-in, a block rule, review for new tools.