What to check before an MCP server reads your Microsoft 365 tenant

01 / 11

An MCP server is not an app, and that is what makes the decision unfamiliar

The Model Context Protocol is the plumbing that lets an AI assistant call a tool instead of guessing. A remote MCP server is a service you point your assistant at — Copilot Studio, Claude, Visual Studio Code — which then answers by calling a real API on your behalf. For a Microsoft 365 tenant, that means somebody can ask how many administrators do we have, and which of them have no MFA registered, and get the answer from live data rather than a screenshot taken in June.

It is a useful thing to own, and a kind of connection most review processes do not quite fit. An application you install has a vendor, a contract and a support page. An MCP server has all of those plus a protocol sitting between it and your assistant, deciding what a token may be used for independently of your contract. So the request arrives looking like an ordinary consent prompt — and consent is only the first of three gates, owned by three different parties, of which exactly one is visible on the screen you click.

02 / 11

Before anything else: does it run on the vendor's infrastructure or your staff's laptops?

This moves the risk more than every other question below combined, and it is usually settled before security hears about it. A remote server is reached over HTTPS at a hostname, and an organisation consents to it deliberately. A local server is a process launched on somebody's own machine, generally from a JSON configuration file, running with that person's privileges.

Microsoft's own Visual Studio Code documentation puts the local case bluntly: Local MCP servers can run arbitrary code on your machine. Only add servers from trusted sources, and review the publisher and server configuration before starting it. The same product ships a sandbox described as being exclusively for locally-running stdio MCP servers. Remote servers get no equivalent containment there, because they never execute anything on the user's machine to contain.

In April 2026 the security firm OX Security published research arguing this is a design problem rather than a configuration hazard: the local transport's handling of server parameters lets configuration flow into command execution across the official SDKs. At least one resulting vulnerability is vendor-confirmed — LiteLLM's advisory of 21 April 2026 describes a command-injection flaw in its MCP server creation path, fixed with a command allowlist.

• A remote server you consented to is a vendor relationship. It reads through Microsoft's API, under permissions you granted and can withdraw.
• A local server on a laptop is a software supply-chain relationship. It is code running as that user, and your consent screen never saw it.
• The two need different controls. Tenant consent settings govern the first; endpoint and client policy govern the second.

03 / 11

A tension in the published guidance, worth naming

A reader who goes looking will find authoritative advice pointing the other way. The NSA published an information sheet on MCP in May 2026 recommending the opposite preference: When processing private data, always prefer a local instance of MCP server to reduce the risk of data leakage. That is not a contradiction, because the two reason about different risks — the NSA is protecting confidentiality, data leaving your control to a third party, while the supply-chain research is protecting integrity, unvetted code executing on your hardware. Note also that the NSA does not recommend against hosted servers; for external connections it prescribes a filtering outgoing proxy... or an enterprise data loss prevention (DLP) solution. The reading that these are two different risk axes is ours, not a claim either document makes about the other.

04 / 11

Three gates, and most buyers check one

Assume from here that the server is remote and the question is whether to consent. Three separate checks stand between it and your tenant data, and no single party operates all three.

Gate one is consent. Microsoft decides which permissions it will mint a token for, based on what an administrator approved.

Gate two is entitlement. The vendor decides whether your tenant is switched on in their service at all. This gate is in no standard anywhere — it exists only if the vendor chose to build it.

Gate three is audience. The protocol decides whether a token presented to a server was genuinely issued for that server. It is written into the MCP specification in capital letters, and almost nobody asks about it.

The three-gate framing is ours; the three mechanisms are not.

05 / 11

The seven questions, and what a good answer sounds like

Take these to the vendor before the consent screen rather than after it. A vendor who has thought about their own design answers all seven quickly. One who has not will improvise, and the improvising is itself the signal.

06 / 11

Gate one: what Microsoft will actually let it read

The consent screen is the only gate you read before deciding, and it carries one distinction that matters more than any other.

Delegated permissions let an application act on a signed-in user's behalf, and Microsoft is explicit that this caps its reach: For example, take an application that is granted the Files.Read.All delegated permission on behalf of the user. The application is only able to read files that the user can personally access. Application permissions are for the case with nobody signed in — and there, in Microsoft's own words, the application is able to access any data that the permission is associated with.

So a delegated grant inherits your existing access-control model; an application grant replaces it with a single tenant-wide ceiling. Both are legitimate, but a vendor asking for the second should be able to say why the first will not do. Tenant-wide admin consent is also broader than it looks: granting it allows all users to access the application unless otherwise restricted.

The blue badge beside the publisher name proves less than most assume. Microsoft says so plainly: The blue verified badge doesn't imply or indicate quality criteria you might look for in an app... Publisher verification doesn't give you this information. It confirms the publisher is who they claim to be, and nothing more.

07 / 11

Gate two: consent is not the same thing as activation

No standard requires a vendor to treat admin consent and service activation as separate events. Most treat them as one: you consent, the integration is live.

Splitting them closes a specific hole. If consent alone activates, anyone who can reach the server and authenticate against your tenant is effectively a customer of it. If activation is a second step the vendor performs on your written instruction, a consent granted in error — by a new administrator working through a setup guide, say — exposes nothing until somebody at the vendor acts. Ask it in plain words, because the answer is never on a marketing page: if I grant consent right now and tell you nothing, what can your service do?

08 / 11

Gate three: who the token is actually for

Nothing about a bearer token physically prevents one issued for a server being replayed at a different server. OAuth solved this years ago with audience binding, and the MCP specification — currently at revision 2026-07-28 — makes it mandatory rather than advisory. Clients MUST implement Resource Indicators for OAuth 2.0 as defined in RFC 8707 to explicitly specify the target resource for which the token is being requested, and servers MUST validate that access tokens were issued specifically for them as the intended audience.

It then forbids the shortcut that makes this fail in practice. A server may not forward the token it was handed to an upstream API: MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server, with the security guidance stating flatly that token passthrough is explicitly forbidden in the authorization specification. The risk is the classic confused deputy — a service with legitimate access talked into exercising it on somebody else's behalf.

Here is the uncomfortable part. A specification requirement is not an enforcement mechanism. You cannot see from outside whether a server validates audience; you can only ask and judge the answer. A vendor who can name the revision they implement, and say what their server does with a token bearing the wrong audience, has read the specification. One who answers by describing their infrastructure has not.

09 / 11

What you can actually enforce today

Governance here is younger than the problem, but not absent. Three controls exist right now, documented by their own vendors.

• Claude Code lets an administrator restrict which servers run. Anthropic states the default plainly — By default, anyone running Claude Code can connect any MCP server they choose — and documents deploying a fixed approved set, or disabling MCP entirely.
• GitHub Copilot supports an enterprise allowlist or denylist in a managed settings file, matching by server name, by server URL, or by the specific command a local server would run.
• Visual Studio Code ships named enterprise policies — one controlling access to installed MCP servers, one restricting execution to an enterprise-managed allowlist — deployable through Group Policy or Intune.

10 / 11

Turning it off, and how long that actually takes

Now the question every security review asks last and ought to ask first: how quickly can we stop this? Revoking is mechanically simple — Enterprise applications, the application, Permissions, revoke. Two things about it are less obvious. The first Microsoft states outright: Revoking the current granted permission doesn't stop users from re-consenting to the application's requested permissions. Closing the door does not lock it.

The second we could not find Microsoft answering in any single place, and we looked hard. What happens to a token the application already holds? Two documented facts bear on it. Microsoft's default access-token lifetime is a random value ranging between 60-90 minutes (75 minutes on average) — though the same page elsewhere gives a flat two hours for certain first-party clients, without reconciling the two. And the events triggering near-real-time revocation for workload identities under Continuous Access Evaluation number exactly three: the service principal disabled, the service principal deleted, and high service principal risk from Identity Protection. Revoking consent is not among them.

Our reading, labelled as ours because Microsoft does not state it in one place: revoking consent stops new tokens being issued, but a token already in flight keeps working until it expires — so plan on a residual window of up to roughly an hour. If access has to stop immediately, disable the service principal instead, because that event is on the list.

11 / 11

Where to start

Turn on the MCP allowlist in whichever assistant your organisation uses, this week, before anybody needs it. That one control converts the problem from what did somebody connect into what did we approve. Then work the seven questions in order against any server that wants to read your tenant.

Disclosure, because this post recommends a category we sell into. Avalon Web Services operates a remote MCP server of its own, the Avalon CloudSec Security Intelligence MCP, which answers read-only questions about a Microsoft 365 tenant. Its answers are: remote, at a fixed hostname; ten read-only Microsoft Graph permissions, listed in full before consent; consent and entitlement kept separate, so consent alone activates nothing; and tokens scoped to that service and nothing broader. We think those are the right answers, which is why it was built that way — but put the questions to anyone, including us. To walk through them against your own tenant, email support@awservices.org.

Microsoft, Microsoft 365, Azure, Entra, Intune and Defender are trademarks of the Microsoft group of companies. Avalon CloudSec is an independent service and is not endorsed by Microsoft. Claude and Claude Code are trademarks of Anthropic.