Govern SharePoint in Claude with delegated OAuth

Why SharePoint in Claude needs per-person OAuth

SharePoint in Claude stays inside each person's own permissions only when every call is delegated. That means each person signs in with their own Microsoft account. The app never acts beyond what that account can already see. Microsoft states the rule for delegated permissions directly: "the application can't access anything the signed-in user couldn't access" (learn.microsoft.com, checked October 2026). Site permissions, library permissions and item-level restrictions then do the work they already do. The MCP layer adds no new access; it inherits what Entra and SharePoint already enforce.

Elaichi's SharePoint connector accepts two connection modes:

A client-credentials connection signs in as one app identity. Everyone who reuses that connection reaches whatever the app was granted. That is not what they personally can open in a browser. For keeping SharePoint permissions, that is the wrong shape.

Graph permissions come in two forms, and the distinction decides whether an admin has to approve anything. Delegated Sites.Read.All and Files.Read.All need no admin consent; their application (app-only) equivalents do (learn.microsoft.com, checked October 2026). In delegated mode, Graph intersects the app's granted scopes with the signed-in user's actual permissions. The app's scope is a ceiling, and the user's access is the real limit. The lower of the two always wins.

Share a template, not a connection

The per-person shape in Elaichi is a template shared at use, never a shared connection. A template holds a tool list with overrides, defaults and frozen arguments, and never holds a connection itself. This is the mechanism that keeps one shared setup from collapsing into one shared identity.

Build a template from the SharePoint connector and share it with the team at use. Each member then stamps their own toolbox from it. Stamping binds every entry to the stamper's own connection, so each person's calls run on the Microsoft account they signed in with. An entry with no usable connection is left as "needs connection" until that person connects, so it fails visibly, not silently.

A shared connection works the opposite way. It runs on its owner's credential, so every call reaches SharePoint as the owner, regardless of who triggers it. A toolbox shared at use has the same effect, because every entry in it is pinned to the connection its owner chose at creation time. For permission parity across a team, the template is the only one of the two that preserves per-person boundaries. A shared connection or a shared toolbox both re-create the app-only problem, just with a human owner instead of a service principal. The same fork appears in drawing the folder line in Google Drive, where a dedicated account is sometimes the better of the two shapes.

What Elaichi's SharePoint connector carries

Elaichi's sharepoint connector carries 97 tools. 49 have names starting list_ or get_, and they read. Most of the other 48 create, update, publish, upload or delete pages, lists, list items and files, and five change who can see what.

Elaichi authors and serves this connector from its own infrastructure, alongside the rest of the 600+ connectors. So no third-party MCP server sits in the call path between Claude and Microsoft Graph. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.

Two tools behave differently from the rest:

• list_all_sharepoint_search runs Microsoft Search under the hood and is classified other, not read. A rule written to match "all read tools" will not catch it by accident, and a rule meant to allow it must name it explicitly.
• list_all_sharepoint_get_all_sites requires an app-only token. On a delegated connection it returns HTTP 403. That 403 is the expected result of per-person auth working correctly, not a connector fault. If you see it on a delegated setup, the setup is doing what it is supposed to.

The full tool list is on the SharePoint connector page.

Writing the allow rule for a reading role

Hold a reading role with an allow rule that names the read tools it needs plus list_all_sharepoint_search explicitly, since it is not classified read. A block list fails open on a connector this size. Of 97 tools, roughly 48 write or act. Every one you forget to name in a block list stays reachable. The same arithmetic plays out on Intune's 198 tools, where six blocks are not enough. An allow list fails closed instead, so anything not named is denied. That is the direction you want on a document store. The cost of one missed write tool is a deleted or overwritten file.

For a reading role, name tools such as list_all_sharepoint_sites, get_single_sharepoint_site_by_id, list_all_sharepoint_drives, list_all_sharepoint_drive_items, get_single_sharepoint_drive_item_by_id, list_all_sharepoint_lists, list_all_sharepoint_list_items and list_all_sharepoint_search.

One property of restrictions catches people out: an allow rule is the target's entire allowlist across every connector, not only the app it names. Once a role holds one allow rule, every connector that rule does not mention is denied for that role. That includes connectors that had no restrictions before. A support role reading SharePoint and working in Jira needs the SharePoint allow rule plus a separate allow rule naming Jira whole. It cannot rely on Jira being unrestricted by omission once any allow rule exists on that role. Allow rules targeting the same role union together, so one rule per connector is the normal way to compose this, not one giant rule.

In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A block rule matches the advertised tool name or the pinned operation it maps to. An allow rule matches the pinned operation only. The mechanics are covered in why blocks match names and allows do not. A restriction change takes effect within about two minutes.

The five tools that change who can see what

Five tools in the SharePoint connector edit SharePoint's own sharing model rather than its content:

These are the tools that can quietly widen the permission model everything else in this post assumes is stable. An invitation sent to the wrong address opens that item to someone outside the team until someone notices and revokes it. A reading role keeps all five out simply by never naming them in its allow rule. There is nothing to block, because anything the allowlist does not name is already denied.

A withheld tool is invisible, not merely disabled. It is absent from tools/list and absent from the search index. Its name never goes on the wire to the model. To the model it looks exactly like a tool the connector never had.

Does Sites.Selected limit SharePoint to chosen sites?

Sites.Selected is Microsoft's mechanism for holding an application to sites it has been granted explicitly, rather than tenant-wide. An app consented for a Selected scope has zero access at first. Access starts once it is granted a role on a specific site through POST /sites/{siteId}/permissions. The role is set to read, write, owner or fullcontrol. Creating that grant itself requires Sites.FullControl.All, and in a delegated flow requires a caller with SharePoint Administrator role or higher (learn.microsoft.com, checked October 2026).

Do not assume every third-party connector draws the site line this way. Sites.Selected is one specific Graph mechanism, and a connector can be delegated (per-user) without also being Selected (per-site). In Elaichi, the site line is drawn by the Microsoft account each person signs in with and by the restriction on their role. Elaichi's console does not show which Graph scopes its SharePoint connector requests, so do not assume it uses Sites.Selected.

For comparison, two other Microsoft-adjacent AI products sit at different points on this same spectrum:

Claude's own Microsoft 365 connector does not support Sites.Selected. Its SharePoint search runs tenant-wide under Sites.Read.All, limited to each user's own permissions (support.claude.com, checked October 2026). Microsoft Copilot sits in a comparable place. It "only surfaces organizational data to which individual users have at least view permissions" (learn.microsoft.com, checked October 2026). Restricted Content Discovery can hide a site from organization-wide search and Copilot without changing its underlying permissions (learn.microsoft.com, checked October 2026). Whether Restricted Content Discovery also suppresses a site from third-party Graph-based search, including Elaichi's, is not documented by Microsoft. Do not plan a security boundary around it.

When Claude's own Microsoft 365 connector is the better choice

If SharePoint is the only system your team needs inside Claude, and read access is all that is required, the answer is simpler. Anthropic's native Microsoft 365 connector is genuinely less machinery to operate. It is available on all Claude plans and takes a one-time Entra Global Administrator consent. On Team and Enterprise plans an Owner can also enable it. It is read-only by default; enabling SharePoint writes requires turning on write tools plus granting Files.ReadWrite.All (support.claude.com, checked October 2026). For a single-app pilot with one connector and no cross-tool audit requirement, that is usually the right answer and adds no operational layer worth maintaining.

The trade-off shifts once a role needs more than one system, for example SharePoint plus Jira, Zendesk or Salesforce. The alternative is writing and maintaining access rules separately in each vendor's own console, instead of once per role in a single control plane. It shifts again where a single audit trail needs to cover all the tools a given actor touched, not just one connector's logs. Whether that trade-off is worth the added layer depends on how many connectors a role actually spans, and on how centralized the audit requirement is. It is not automatically the right call for every team.

Adding the endpoint and what each person consents to

The address is https://api.elaichi.ai/mcp for every organization: one URL, not one per team. In Claude Team or Enterprise, an Owner adds it under Organization settings, Connectors, Add, Custom, Web. Members then connect it individually under Customize, Connectors (support.claude.com, checked October 2026). The same URL also serves ChatGPT, Cursor, any MCP-compatible client, and the Elaichi Agent.

Each person signs in on Elaichi's own consent screen, picks one organization, and ticks what the client may do. Delete is never pre-ticked by default. With "Run your connected tools" ticked, a second step asks whether to grant all tools or only chosen toolboxes. The consent request itself lasts 30 minutes before expiring. That is long enough to stamp a template in a second tab. It does need to happen in one sitting.

One mechanical detail trips people up. For a connected app's tools, the general tools checkbox covers reads and writes together. Only a delete action costs a separate destructive-action scope. Leaving "Create and change data" unticked does not make SharePoint read-only by itself. Read-only access is enforced by the allow rule on the role, not by this checkbox. That is covered in restricting one tool or a whole app.

What the audit trail records, and what leaving ends

Elaichi writes one entry per tool-call attempt, succeeded or failed. The raw error text Microsoft returns to the caller is never copied into the audit record itself. That keeps third-party response payloads out of the audit log pipeline. The entry records that a call failed and which tool and operation it was, not the verbatim upstream error body.

The entry records the surface as mcp and names the OAuth client that made the call. Claude is among the clients whose identity is marked verified by its registered redirect URIs. A call made through an MCP client is logged with an actor kind of user. The grant backing the call belongs to that person, not to the client application.

When someone leaves the organization, removing or suspending them in Elaichi is what ends their access through Elaichi. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. Offboarding runs a preflight first. It lists every connection the departing member owns, private and shared alike. Each one is either transferred to another active member or deleted. It is never silently transferred to the admin running the removal, which would otherwise let one admin accumulate other people's connections during offboarding. The full sequence is set out in offboarding when the agent holds the access. Removal ends access through Elaichi specifically; the person's underlying Microsoft account still exists and must be deprovisioned separately in Entra or through your identity provider. These are two different revocation events and neither one substitutes for the other.

For the wider model, see what an MCP control plane is.