What an MCP Server Actually Grants in a Microsoft 365 Tenant
When you connect an AI assistant to a Microsoft 365 tenant through a connector or an MCP server, the assistant's effective reach is not the signed-in user's reach. It is whatever that server was granted, exposed through whatever tools that server offers. Three things decide how far that goes. The identity the server holds and how narrowly it is scoped. Whether your policy surface can reach individual tools or only the connector they arrive through. And whether the server's write operations can be reviewed before they run. Most reviews check the first and assume the other two.
That gap is the outbound half of AI exposure, and it is the half that acts.
The permission is on the server, not on the question
A connector or an MCP server sits between the model and the tenant. The model asks for something in language. The server turns that into Graph calls using its own credential.
So the interesting number is not what the user could have reached on their own. It is what the server holds. An integration granted tenant-wide read and write across SharePoint has that reach available to every prompt it ever serves, in every conversation, for every user it is wired up to. The assistant does not need to escalate anything. The reach was provisioned at install time and it sits there.
This is why the scoping question is worth more than it looks. Microsoft Graph
distinguishes between a tenant-wide grant like Sites.ReadWrite.All and a
per-site grant like Sites.Selected, where the application is given access to
named sites and nothing else. Same protocol, same tools, very different blast
radius when a prompt goes somewhere nobody intended.
Ironwright MCP, the reconciliation server I build, is built on the narrow one and never holds the broad one, including transiently during setup. That constraint drove real work: a live setup run proved Graph refuses a delegated token on the per-site grant endpoint even for a Global Administrator, which meant a separate grant-issuing application had to do that job so the server's identity is never over-privileged at any point in its life. The point is not that this is hard. It is that "scoped to least privilege" is a claim you can check, and it is usually checkable from the app registration before you ever authorize anything.
Governance got better this year, and it stops short of MCP
Microsoft improved this in 2026, and the improvement is real. Advanced connector policies reached general availability in June, replacing the old Business, Non-Business and Blocked classification with something far more precise. You can allow a connector and switch off one risky action inside it, or permit reads while blocking writes, using connector action control. If you have only ever seen the three-bucket model, that is worth a look.
That granularity does not reach MCP server tools. Microsoft's guidance on data policies for agents puts the control at the connector: blocking Power Platform connectors "also blocks access to tools in connected MCP servers, which rely on Power Platform connectors for connectivity." Block the connector and the server's tools go with it. Allow it and they all come along.
Follow that through, because the second half matters more than the first. An MCP server's tool surface is discovered from the server at conversation time rather than enumerated in a policy you approved. If it exposes ten tools and three of them mutate data, allowing the connector covers all ten. It also covers the eleventh, whenever that server decides to offer one.
So the review you did in March describes a surface that can change in April without asking you again. That puts the weight back on scoping. When the decision available to you is the server rather than the tool, the server's own identity is the control that is left.
Writes that cannot be reviewed before they happen
The third condition is whether the server's mutating operations are inspectable before they run.
A tool that renames or moves files on request gives the model a direct line from a sentence to a change in a document library. If the only record is that the change happened, the review conversation afterwards has nothing to work with.
The design worth asking a vendor about separates the two halves. One tool produces a plan, which is data a person can read. A second tool applies it. Dry run stays the default and a live run needs an explicit confirmation. Before anything is applied, a reversal log is written, and that log is itself a valid plan, so rollback runs through the same code path as the original operation rather than through a second implementation that gets less testing and more trust. Writes carry ETag preconditions, so a change made by someone else between the plan and its execution fails the write instead of silently overwriting them.
Ironwright MCP is built to that shape. Its write tools are designed and not yet built, so this is a description of the pattern, not a track record. It is still the right question to put to any connector you are about to authorize: can I see what it intends to do before it does it, and can I put it back?
Where this fits in a tenant assessment
The MCP and connector surface is one of three structural axes Augur scores.
- DataAccess: what a compromised assistant could read. Mailbox delegation, SharePoint and OneDrive sharing.
- InboundSurface: how untrusted content could reach a principal. External Teams access and federation.
- OutboundAction: what an assistant could do outward. Power Automate flows, external actions, and the MCP and connector tool surface.
Findings are rated severity 1 to 3, scored per principal into a heatmap, then aggregated into a single client exposure level from Baseline to Critical. The axes are deliberately separate because they fail differently. A tenant can be locked down on sharing and still hand an assistant a broad outbound tool surface, and reading only the sharing report will call that tenant safe.
Doing this without reading anyone's mail
An objection lands here reliably, so it is worth answering directly. Measuring a tenant's exposure does not require inspecting anyone's content.
Augur reads tenant configuration only. It never inspects message or file content, it needs read scopes across Graph, Exchange Online, Teams, and the Power Platform admin API and nothing more, and no AI component runs anywhere in the assessment pipeline. The analysis is deterministic configuration analysis. When a data source is unavailable it emits a presence stub rather than failing the run, and each run writes a timestamped folder of JSON, CSV, and HTML so runs never overwrite each other. GDAP-managed tenants can be assessed in batch.
That matters for a question like this one, because the honest answer to "what could this assistant do" is derivable from configuration. You do not need to read the documents to know who can reach them.
What to check before you authorize
Three questions, in the order they pay off:
- What identity does the server hold, and how narrowly is it scoped? Look at the app registration, not the marketing page. A per-site or per-resource grant and a tenant-wide grant are the same product with different blast radii.
- Does your policy reach individual tools, or only the connector? For MCP servers today it is the connector, so authorizing one takes every tool it offers now and every tool it adds later. The scoping from question one is what is left.
- Are its writes planned, reviewable, and reversible? If a mutating tool cannot show you its intent before acting, you are trusting a sentence.
Augur is the tooling I built to answer the tenant-side half of this at scale across managed tenants. It is written up on its project page.