When you connect an MCP server like Slack to Claude or ChatGPT, you usually see an OAuth consent screen and click “Allow.” What you are actually approving is much broader than most people realize: a token that lets your AI client call every tool the server exposes, not just the one you had in mind. OAuth scopes are supposed to be the fix for that — a way to say “only this much access, nothing more.” Here is what scopes actually control in MCP today, where they fall short, and how to close the gap.
What happens when you click “Allow”
MCP’s authorization model is standard OAuth 2.1 with PKCE. Your AI client discovers the server’s authorization endpoint, registers itself (usually via dynamic client registration), and redirects you to a consent screen. You log in to the underlying service — Slack, Notion, GitHub, whatever it is — approve the request, and get redirected back with an authorization code. That code is exchanged for an access token, which the client attaches to every subsequent MCP request.
In principle, the scope parameter in that request is what limits the token: channels:read instead of full workspace access, say. In practice, the token is what the AI client uses to call any tool the server currently exposes — and MCP’s tool list sits on top of the OAuth layer, largely independent of it.
Why MCP scopes are coarser than they look
Most MCP servers today request one broad scope, or none at all beyond “authenticated user,” and expose their entire tool list to any token that clears login. A server built to read your calendar and one built to delete your calendar events can sit behind the same consent screen if the underlying API scope covers both. The OAuth flow correctly proves who you are; it does not reliably limit what the AI is allowed to do with that identity once the token is issued.
That gap matters more for MCP than for a typical OAuth app, because the party using the token is not a fixed piece of software you wrote — it is a language model deciding at runtime which tools to call, based on instructions that can come from content it reads, not just from you.
Read the consent screen like it’s the real permission grant
Before you approve, it is worth treating the consent screen as your one real chance to see what you are granting:
- Look at the requested scope name, not just the app name. “Full access” and “read-only” are very different grants that can look identical in a client’s UI.
- Check who is asking. The consent screen shows which application is requesting the token — make sure it is the client you expect, not an unfamiliar name.
- Assume the tool list, not the scope name, is the real limit. After you approve, go look at the server’s actual tools (see our checklist for vetting an MCP server before you connect one) rather than trusting the scope label alone.
Tokens outlive the moment you approved them
An access token is not a one-time decision. It typically lives for an hour or more and comes with a refresh token that can renew it for weeks, all without asking you again. If a server you approved months ago quietly adds a new, riskier tool — or an attacker compromises the server itself — your original OAuth consent is still doing the authorizing, even though the thing it is authorizing has changed. This is the same “rug pull” problem we cover in our piece on prompt injection and tool poisoning, approached from the token side instead of the tool-description side.
The fix isn’t a better scope string — it’s a policy layer
Waiting for every MCP server to ship fine-grained, well-documented OAuth scopes is not a plan you can rely on today. The practical fix is to add a policy layer on top of whatever scope the server happens to offer — deciding, per tool, whether your AI client can call it at all.
That is the model our MCP security page describes and what gate enforces once a server is connected: every tool gets an allow / ask / block rule, set per tool and per AI client, independent of whatever scope the upstream OAuth grant covers. A Slack server that only requested one broad scope can still have its message-deleting tool set to “ask” while its read tools stay on “allow.” If a tool changes after you approved it, drift detection flags it instead of letting the original grant silently keep covering the new behavior.
On the identity side, connecting through a gateway also means the OAuth relationship is between you and the gateway, not a separate one-off grant per client. Revoking a client’s access, or an entire server, is one action instead of hunting down every place a token might be cached.
The bottom line
OAuth scopes are the right idea — least privilege at the authorization layer — but most MCP servers today don’t implement them finely enough to trust on their own. Read the consent screen carefully, check the actual tool list before and after you connect, and put a per-tool policy in front of anything you can’t fully audit yourself. See our guide to MCP access control for teams for how this extends once more than one person is connecting servers. The scope string gets you in the door; what happens after is on you to control.