OWASP lists “Privilege Escalation via Scope Creep” as MCP02 in its MCP Top 10. We set out to count MCP servers that ask for more access than their tools use. The first results show something bigger: most don't offer a smaller choice at all.
Why it matters
An agent reads text it didn't write: emails, tickets, documents, web pages. One planted sentence can make it call a tool nobody meant it to. What happens next is decided by the token. If it can only read, the damage is a leak. If it can write, delete, invite people or spend money, so can whoever planted the sentence.
The same goes for a token that leaks from a laptop, a log or a compromised client. Least privilege is the one control that limits the damage in every case, and by default most MCP servers skip it.
What we found so far
- 196 of the 220 servers that use OAuth in our random sample (89%) give a connected agent everything the user can do: 52 have no scope narrower than full access, 70 have a single scope that covers everything, and 74 tell AI clients to request every scope they list.
- The most-used servers are no better. Of the 18 we checked from well-known SaaS companies, 7 have no scopes beyond sign-in, 3 have one scope for everything, and 7 tell clients to request every scope they list: a median of 7 and up to 36 at once, all of them including write access. Only 1 asks for less than its full list.
- None of them asks for read-only access when you first connect, including the ones that have read-only scopes.
- Some of what's asked for isn't used. Where we've checked tool by tool, we've found scopes requested at sign-in for tools that are switched off by default, and for products the server has no tools for.
“Everything” means everything that user can do through that server. A scope can't exceed the user's own permissions, and some servers narrow access in other ways at sign-in, such as choosing a workspace. Scopes are what an agent's token carries everywhere, so they're what we measure.
The fix is already in the spec
The MCP authorization spec, since its 2025-11-25 revision and still in the current one, says a server should name the scopes a client needs in its sign-in challenge, keep its list of supported scopes to the minimum for basic use, and ask for more only when a tool needs it. When a server names nothing, clients are told to request every scope it lists. Only 9% of the servers in our sample point clients at a smaller set than they support. A server that splits read from write, asks for read first and steps up on the first write gives agents what they need and nothing more.
How we measure
- Pull the official MCP Registry and keep servers a company hosts on its own verified domain, without gateways, free hosting or duplicates.
- Draw a random sample of 500 with a published seed (20261011), and add the servers from well-known SaaS companies, which a random sample almost never includes.
- For each, read only what it shows every client before sign-in: its OAuth metadata and the scopes its sign-in challenge asks for. From that, classify what a connected agent gets by default.
- Where a server publishes its tools, in docs or code, classify each requested scope as needed, broader than needed, or never used.
- Tell owners privately, then publish counts, patterns, the seed and the code so anyone can repeat it.