Cloudflare lets users remove permissions an MCP server asks for

Cloudflare has added optional scopes to its OAuth provider. A client can now mark some of the permissions it asks for as optional, and the consent screen lets the user choose each one before granting the token. The change was published on the Cloudflare blog on 20 August 2026 by Miller Vargas and José Enrique Rodriguez, two interns on the identity team, and was covered by InfoQ on 2 September.

What actually changed

Before this, a Cloudflare OAuth client sent a single list of scopes. The user either accepted the whole list or refused it. If a client wanted narrower consent, it had to build its own scope-selection page and hand a reduced list back to the OAuth endpoint. The new feature adds a second field, optional_scopes, next to the existing scopes. Anything in that array shows on the consent screen as a checkbox that the user can turn off. The token that comes back only carries the scopes the user actually approved.

Cloudflare says the feature is generally available. It applies to third-party OAuth apps on the Cloudflare platform, which the post says have processed more than a million authorisations since June across thousands of clients.

Why MCP is their main example

The blog names Model Context Protocol servers as the reason they built it. An MCP server exposes a set of tools, and an agent that connects to it typically requests every scope the server declares, because the agent does not know ahead of time which tools it will use. On the current all-or-nothing consent flow that means a user is asked to grant every permission the server could ever want, up front, on a single screen.

With optional scopes, the MCP server author can mark the writes and destructive actions as optional and leave the reads as required. A user who wants an agent to browse but not delete can now approve only what they trust, without the server having to run its own consent UI.

If you are building an MCP server on Cloudflare, the split you make between required and optional scopes is now a design decision users can see. So the honest approach is also the safe one: put in scopes only what the server cannot function without, and move everything else into optional_scopes. A user who declines the writes will get a working read-only session rather than a failure, so the server has to handle a partial-grant token as a normal case.

People building agent tools have been discussing this wider pattern for a year. Agent connections tend to ask for too much because they cannot know in advance what they will need, and the human at the consent screen has no good way to refuse part of it. A checkbox per scope is the smallest tool that gives the user the power to say no, and it puts it in the standard flow instead of hiding it behind custom UI that most servers will never build.

Source

Primary source: Cloudflare blog, 20 August 2026. Coverage: InfoQ, 2 September 2026.