How to Let Employees Use Claude With Microsoft 365 — Without Handing It the Whole Tenant

The short answer: Letting staff use Claude with Microsoft 365 is a tenant-admin decision, not a user setting. Per Anthropic's current help-centre article (check it first, because it changes), the connector uses delegated permissions, so Claude can only reach what the signed-in employee can already open. The boundary has two layers: the Microsoft Graph permissions left on the connector's enterprise application, which an Entra admin can revoke one by one, and your existing SharePoint, Teams and mailbox permissions. Before anyone connects, restrict user consent, assign a pilot group to both Claude apps, revoke what the use case does not need, add Conditional Access, watch the sign-in logs and fix oversharing.

Picture the Microsoft 365 administrator at a Hong Kong professional-services firm of about 150 people, where client confidentiality is a contractual duty and client personal data is covered by the PDPO. Nobody asked IT's permission, but staff already use Claude on personal accounts: associates paste meeting notes into it, and a few paste draft client memos. The managing partner's request is reasonable and blunt: "Make it official, and make it safe."

What the partners actually want is narrow. They want Claude to turn Teams meeting transcripts into action lists and to answer questions over the firm's SharePoint knowledge base: engagement-letter templates, internal procedures, past proposals. What they do not want is any route to the HR mailboxes or to the client-matter mailboxes where privileged correspondence sits.

The administrator opens the connector's help page, finds that it covers Outlook mail, calendar, Teams, OneDrive and SharePoint together, and wonders whether "meeting notes yes, mailboxes no" can be expressed at all. It can, but not with a switch inside Claude: the controls sit in Entra ID and in the firm's own access rights.

What "Connecting Claude to Office 365" Actually Grants (Delegated vs. Application Permissions)

Microsoft 365 apps can be granted access in two different ways. Application permissions let an app act as itself, with no user present, across the whole tenant, which is what a backup tool or a compliance scanner needs. Delegated permissions let an app act on behalf of a signed-in user, and only within what that user is already allowed to see. Microsoft documents the difference on Microsoft Learn, and it is the most important idea in this decision.

Per Anthropic's current help-centre article, the Microsoft 365 connector uses delegated permissions: Claude acts on behalf of each signed-in user and can only reach data that user can already access, mirroring their existing Microsoft 365 permissions. It does not use application permissions. That is the good news: there is no tenant-wide service account quietly reading everything.

Enabling it creates two enterprise applications in Entra ID, "M365 MCP Client for Claude" and "M365 MCP Server for Claude". It requires a Microsoft Entra tenant tied to a Microsoft business plan; personal Microsoft accounts cannot connect. A Microsoft Entra Global Administrator grants a one-time tenant consent, and nobody can connect before that. On Team and Enterprise plans, a Claude organisation owner also enables the connector. Plan availability has changed before, so check the article.

What it can reach is broad: Outlook mail, including the primary mailbox's Archive folder and shared mailboxes the user has delegate access to, calendar, Teams chats and channels, meeting transcripts and recordings, and OneDrive and SharePoint files. Read and search tools work by default. Write tools (sending email, changing calendar entries, creating or updating files, posting Teams messages) stay off until an owner enables them, and a tenant that consented before they launched needs a Global Administrator to approve the expanded permissions. Access is on demand and revocable. The separate Online Archive mailbox is not covered by email search.

Setting Up the Tenant Before the First Employee Connects

Do these in order, and do them before the first employee clicks "connect". Entra menu names move around, so treat the paths below as a guide and check Microsoft Learn for the current ones.

Restricting user consent so staff cannot approve arbitrary apps themselves

Entra ID lets you decide whether ordinary users may consent to apps on their own. Under Enterprise apps, Consent and permissions, the options include not allowing user consent at all, or allowing it only for apps from verified publishers and only for permissions you have classified as low impact. For a firm with client-confidentiality duties, the safer setting is no user consent for anything that reads mail or files. The Claude connector needs a Global Administrator's consent anyway; this setting governs every other AI add-in.

Pair it with the admin consent workflow. When a user hits a consent prompt they cannot approve, they can submit a request, and a named reviewer, rather than whichever Global Administrator happens to be online, approves or declines it. This stops the quiet spread of AI add-ins that started as a free trial.

Admin-consenting only what the use case needs, and assigning who may use it

Read the default permission set before you click: Anthropic's article lists it scope by scope (Mail.Read, Mail.Read.Shared, Chat.Read, Sites.Read.All and so on). You can narrow it afterwards. In Enterprise applications, open "M365 MCP Server for Claude", go to Permissions and, on the Admin consent tab, revoke individual Microsoft Graph permissions; tools that need them then return a "Failed to call tool" error. A revocation applies to everyone in the tenant, and re-running admin consent restores the defaults, so record what you revoked.

You can also control who uses it. In the Entra admin center, open "M365 MCP Server for Claude", go to Properties, set "Assignment required?" to Yes and assign a group, then do the same on "M365 MCP Client for Claude": Anthropic says both apps must be restricted to the same people. Start with a pilot group of a dozen people, not the whole firm.

Conditional Access and MFA on the app, and using sign-in logs to see what connected

Conditional Access policies can target an enterprise application, so you can require MFA or a compliant device for the Claude apps. Know the limits first: Anthropic's article says Claude's servers make follow-up requests from Anthropic's IP range, so location, network and sign-in-frequency policies can block the connector for everyone, and device compliance is checked against the device recorded at connection. Test in report-only mode. If your MFA rollout is still patchy, fix that first; the MFA rollout at a Hong Kong accounting firm shows a practical sequence.

Then watch it. In the Entra sign-in logs, check the non-interactive tab too, where the connector's server-side requests appear, and filter by user, since rows can sit under either Claude app. You can see who connected, from where, and whether Conditional Access applied. Look monthly; the Entra ID security audit guide for APAC firms covers the wider review.

A Worked Example — Allowing Meeting-Notes and Document Q&A but Not Mailbox Read

Back to the Hong Kong firm: meeting summaries and SharePoint Q&A for ten associates, with the HR and client-matter mailboxes out of reach. Two layers do it: revoke the connector's mail permissions, then remove the pilot users' access to the sensitive areas that remain reachable.

1. Create the pilot group. Make a security group, for example "Claude pilot", with ten named associates and no partners, no HR staff and nobody with delegate access to client-matter mailboxes. Set "Assignment required?" to Yes on both Claude apps and assign only this group.

2. Revoke the mail permissions. On M365 MCP Server for Claude, under Permissions, Admin consent, revoke the mail-read scopes in Anthropic's permissions reference: Mail.Read, Mail.ReadBasic, Mail.Read.Shared, MailboxItem.Read and MailboxFolder.Read. This applies tenant-wide, which suits a firm that wants no mailbox reading. Ask pilot users to turn off the matching mail tools in their own connector settings.

3. Remove the sensitive access from those ten people. Mail is out, but Teams channels and SharePoint sites are not. Remove membership of the HR and client-matter channels and sites, and any full-access or send-as rights on those shared mailboxes, that their role does not need. Content a pilot user cannot open is content Claude cannot read for them, and this layer still holds if someone restores the mail permissions.

4. Check what the pilot users can see in SharePoint. Run a sharing review on the knowledge-base site and on any site shared with "Everyone except external users". Move client files out of broad sites and fix broken inheritance before the pilot, not after.

5. Apply Conditional Access. Require MFA and a compliant device for both Claude apps, scoped to the pilot group, in report-only mode first and then enforced. Do not add a location or sign-in-frequency condition.

6. Test with real prompts. As a pilot user, ask: "Find the transcript of this morning's Project Review meeting in Teams and list the decisions, the owner of each action, and any question nobody answered." Then: "In the Engagement Templates SharePoint site, which version of the engagement letter is current, and what does it say about termination?" Then try to break it: "Summarise the last five emails in the HR Cases mailbox" should fail with a tool error (if not, step 2 is unfinished), and a request for this week's messages in the HR Teams channel should return nothing (if not, step 3 is unfinished).

7. Review, then widen. After two weeks, check the pilot users' sign-in logs, ask what worked, and only then add the next group.

Notice what this example claims. Mail is off tenant-wide through revoked permissions, not a setting inside Claude; if partners later want Claude on their own inboxes, restore the mail scopes and rely on step 3 (see Claude and Microsoft 365 email automation). Nor does it restrict Claude to named SharePoint sites: Anthropic says site-specific restriction is not supported, so the example restricts the people.

Consumer Accounts vs. a Managed Team Deployment vs. Blocking It Outright

• Staff on personal Claude accounts (the status quo). The connector is available on Free, Pro and Max plans too. Nobody can connect until a Global Administrator has consented for the tenant, but after that any employee with a Microsoft business sign-in can connect from a personal account unless "Assignment required?" limits it. The firm controls nothing about that Claude account; its levers are in Entra: assignment, revoked permissions and Conditional Access.
• A managed Team or Enterprise organisation. The firm owns the Claude organisation and controls SSO, membership and whether the connector is enabled at all. An owner turns it on, a Global Administrator consents once, and you assign the pilot group in Entra. Check Anthropic's commercial terms and Trust Center for how data is handled on these plans, and do not assume consumer terms apply.
• Blocking it outright. Do not grant admin consent for the connector, so nobody in the tenant can connect, keep user consent restricted for other apps, and say so in the staff policy. This is a legitimate answer for a firm that is not ready. But it does not stop anyone pasting a client memo into a personal account in a browser, so it needs a policy and an approved alternative alongside it.

Getting This Right — Sensitivity Labels, Guest Access and What the Connector Can Still Reach

Because the permissions are delegated, the connector is a mirror of your tenant's existing access, and everything wrong with that access becomes reachable the first time someone asks a question. A SharePoint site shared with "Everyone except external users", a team with broken inheritance, a folder with an old sharing link: Claude finds what the user can find, only faster. The Copilot oversharing readiness guide covers the clean-up, and it applies equally here.

Sensitivity labels and site permissions are the controls you actually have. Label the client-matter sites and HR libraries, restrict them to named groups, and review guest accounts: a guest who can open a site can open it through an assistant too. Check current Anthropic and Microsoft documentation on how labels and encryption behave with the connector before you treat them as a hard stop.

Add an offboarding step. Access is revocable and follows the user, so when someone leaves, disable the account, revoke their sessions and remove them from the assignment group, as you would for any app. A personal Claude account stays outside your control, so remind leavers what firm information may not be kept there.

Write the decision down. The PDPO's Data Protection Principle 4 expects all practicable steps against unauthorised access to personal data, so record who approved the connector, which group has it, which permissions were revoked, which tools are enabled and the date, and review it when Anthropic changes the connector.

Deciding which groups should get Claude, what the connector may and may not touch, and writing the prompts and rules around it is AI+ Support work. The Conditional Access, MFA and consent controls it depends on are MFA and Conditional Access work, the day-to-day tenant administration sits with managed IT and cloud services, and staff questions afterwards go to our IT support team.

Frequently Asked Questions

Does the connector see everything the employee can see?

In principle, yes. Per Anthropic's current article it mirrors each user's existing Microsoft 365 permissions, so by default it can reach mail (including shared mailboxes the user can access), calendar, Teams, meeting transcripts and recordings, and OneDrive and SharePoint files, when the user asks. Any permission you revoke in Entra narrows that for everyone.

Can we limit it to certain SharePoint sites?

No. Anthropic's article says SharePoint search runs across the whole tenant with the user's permissions, and site-specific restriction is not supported. The practical method is to change who can see what, by moving or restricting content, and to assign only a pilot group.

What happens to access when someone leaves?

Access is revocable and tied to the user's Microsoft account. Disable the account, revoke their sessions and remove them from the assignment group, as in your standard offboarding. Conversations held in a personal Claude account sit outside your control, which is why the policy matters.

Is this the same as Microsoft Copilot?

No. Copilot is Microsoft's own assistant, built into Microsoft 365 and licensed through Microsoft. The Claude connector is a third-party app in your Entra tenant, with its own consent, enterprise applications and data terms. The oversharing problem is the same for both, so one clean-up serves both.

Where is the data processed?

Check rather than assume. For a Team or Enterprise organisation, start with Anthropic's commercial terms and Trust Center for data use, retention and processing locations, and confirm against your PDPO obligations with your own counsel. Anthropic's connector security guide says file content is fetched on demand and not cached, but tool results are kept as part of the stored chat.

Should we enable the write tools?

Not at the start. Write tools stay off until an owner enables them and, where needed, a Global Administrator approves the write permissions. Keep them off for the pilot, and enable them only for a named use case with a person reviewing what is sent or changed.