Cloudflare has added optional OAuth scopes, letting users deselect individual permissions on the consent screen instead of approving or denying an application's full request. Client owners mark which scopes may be dropped, and the company names MCP servers as the motivating case.
The problem it targets is specific to agents. An application built around a handful of scopes can describe its access needs on a consent screen, and a user can reasonably judge them. An agent cannot. As Cloudflare puts it, an MCP server might request a broad set of permissions because in theory an agent could use all of them, while most users would not want an agent to have that much access.
That gap is easy to see in practice. An agent that reads inventory to compare products does not need permission to change prices. One that checks order status does not need authority to issue refunds. One that reads supplier records during research does not need payment access. The connection exposes the union of everything the agent might ever do, and the consent screen asks the user to approve all of it at once.
Umesh Malik, a software engineer who writes on AI and developer tooling, describes the bind that creates:
That leaves developers with two bad choices: request minimal permissions and break advanced use cases, or request everything and watch users bounce from the consent screen.
Until now, Cloudflare OAuth handled that as all or nothing. A client could request a subset of its configured scopes, but once it had, the user could approve everything or deny. Developers who wanted finer control built a custom scope-selection screen before the consent flow.
Client owners can now mark scopes as optional when configuring an OAuth client, using an optional_scopes array alongside the existing list:
"scopes": [
"user-details.read",
"workers-scripts.write",
"workers-kv-storage.write",
"zone.read"
],
"optional_scopes": [
"workers-kv-storage.write",
"zone.read"
]
One detail governs the behavior. Required and optional scopes are evaluated against the scopes requested in a specific authorization flow, not against everything configured on the client. A client configured with four scopes that requests two shows the user only those two. Clients that do not opt in keep their current behavior, and the consent screen still grants the full requested set by default.
Partial consent isn't new, and Cloudflare isn't the first to offer it. GitHub's documentation states that users can edit their scopes, granting an application less access than requested, and tells developers to handle that case rather than assume the full set. Google shows granular checkboxes for non-sign-in scopes. Microsoft Entra supports incremental consent, with the granted scopes appearing in the token's scp claim.
What Cloudflare adds is developer control over which permissions may be dropped. On the other hand, the user decides unilaterally, and the application discovers the result at runtime. Marking a scope required means a user narrowing a request cannot remove something the application genuinely needs to function, which is a different proposition from hoping they do not.
None of this required changing OAuth. RFC 6749 already permits an authorization server to issue a token with a narrower scope than requested. What has changed is that providers are surfacing that latitude in the consent interface, and doing so as agent integrations make broad requests routine.
The developer consequence is an assumption that no longer holds. When a user deselects an optional scope, the access token carries only what was granted. Applications must inspect the scope parameter in the token response after exchanging the authorization code rather than assuming success means everything. Code written against the old behavior will meet authorization errors on calls it expected to work.
Cloudflare's guidance is to degrade rather than fail. An application that loses a write scope should disable that feature and say so, instead of surfacing a 403 that reads to the user as a broken integration.
For agents specifically, that shapes a design pattern: require read access to whatever the agent queries, make write access optional, check the granted set before acting, and stop cleanly when authority is missing rather than improvising around it. An agent that can read a team's Workers scripts and write to them only when explicitly permitted presents a different risk profile than one demanding full write access at first contact.
The release joins a set of moves addressing different parts of the same problem. The MCP 2026-07-28 specification tightened client authorization, preferring pre-registered clients and Client ID Metadata Documents while deprecating Dynamic Client Registration. Microsoft's hosted Azure DevOps MCP Server reached general availability without support for Claude, ChatGPT, or Cursor, because Entra lacks the client registration mechanisms those clients need. Consent granularity is a third piece: not who the agent is, or which clients may connect, but how much a user must hand over to let it work.
Cloudflare reports more than a million authorizations across thousands of third-party OAuth apps created since June. The company says it will expand account and zone-level roles to cover nearly every product over the coming weeks, adding API token roles, account membership options, and OAuth scopes.