Cloudflare’s Task-Based OAuth Consent Turns All-or-Nothing Agent Permissions Into a Choice

For years, connecting a third-party app to a Cloudflare account meant one binary choice at the consent screen: approve everything the app asked for, or walk away. On August 20, 2026, Cloudflare shipped a fix aimed at a problem the company says its own permission model created: OAuth clients, MCP servers and AI agents in particular, that request broad access because they might theoretically need it, even when a given user only wants to grant a fraction of that access. The new feature, OAuth scope customization, lets developers mark individual scopes as optional so users can narrow a request instead of accepting or rejecting it wholesale.

The all-or-nothing problem MCP servers made obvious

OAuth scopes are the mechanism that lets a user grant an application access to specific parts of an account instead of the whole thing: read a zone’s DNS records, write to a Workers KV namespace, and so on. Cloudflare already let OAuth clients request a subset of their configured scopes, but once a client made that request, the user had no way to narrow it further on the consent screen. As Cloudflare put it in its announcement, “If an application requested more access than a user was comfortable granting, their only options were to approve the full request, or deny outright.” Before this change, the only workaround was for each app developer to build a custom scope-selection screen of their own, ahead of handing the user off to Cloudflare’s consent flow. Cloudflare laid out the change in its own announcement post.

Cloudflare points to MCP servers, the Model Context Protocol’s standardized interface for connecting AI agents to external tools and data, as the clearest example of why that mattered: “An MCP server might request a broad set of permissions, because in theory an agent could use all of them. But most users would not want an agent to have that much access.”

How optional scopes work

With OAuth scope customization, client owners can mark specific scopes as required or optional when configuring an OAuth client. At authorization time, required scopes still show up as non-negotiable, but the user can deselect any of the optional ones before granting access. The configuration itself is a small addition to the client registration payload:

{
  "client_name": "ACME Corp",
  "redirect_uris": ["https://acme.org/oauth/callback"],
  "grant_types": ["authorization_code"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "client_secret_basic",
  "scopes": ["user-details.read", "workers-scripts.write", "workers-kv-storage.write", "zone.read"],
  "optional_scopes": ["workers-kv-storage.write", "zone.read"]
}

In that example, user-details.read and workers-scripts.write stay required whenever they are part of a request, while the user decides whether to also grant workers-kv-storage.write and zone.read. If a request contains no optional scopes at all, the consent screen behaves exactly as it did before.

Scoping applies per request, not per client

One detail matters for anyone integrating this: required and optional status is evaluated against the scopes a specific authorization flow actually requests, not every scope ever configured on the client. Cloudflare’s own example makes this concrete. Take a client configured with four scopes, two required and two optional. If that client starts a flow requesting all four, the consent screen evaluates all four. If it later starts a flow requesting only two of them, only those two are considered, whether or not the other two are marked optional elsewhere in the client’s configuration.

That has a direct consequence for developers: they now need to check the granted scope set after exchanging the authorization code, rather than assuming a client received everything it asked for. Cloudflare frames this as good practice rather than a chore, arguing that an app or agent that operates gracefully within whatever narrower grant it receives is one users feel more comfortable authorizing in the first place.

None of this is a Cloudflare-specific quirk. RFC 6749, the OAuth 2.0 Authorization Framework, has always given authorization servers this latitude: “The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner’s instructions. If the issued access token scope is different from the one requested by the client, the authorization server MUST include the ‘scope’ response parameter to inform the client of the actual scope granted.” Cloudflare’s change is a consent-screen interface built on top of a decade-old spec provision that most clients never had to reckon with, because until now, few consent flows actually put that provision in the user’s hands.

Why this maps onto the confused deputy problem in MCP

The timing lines up with something the Model Context Protocol’s own authorization specification already treats as a named risk. MCP’s spec, built on OAuth 2.1 and a set of supporting RFCs (RFC 8414 for authorization server metadata, RFC 7591 for dynamic client registration, RFC 9728 for protected resource metadata), devotes a dedicated section to what it calls the “Confused Deputy Problem”: “Attackers can exploit MCP servers acting as intermediaries to third-party APIs, leading to confused deputy vulnerabilities. By using stolen authorization codes, they can obtain access tokens without user consent.” The spec’s own mitigation is largely procedural: MCP proxy servers using static client IDs are required to obtain user consent for each dynamically registered client before forwarding it to a third-party authorization server. But the underlying exposure is the same one Cloudflare’s feature narrows from a different angle: an intermediary holding more access than any single interaction requires is a bigger blast radius if that intermediary is ever tricked, compromised, or simply misused.

sxz.io has covered adjacent pieces of this same problem already: how to isolate per-user OAuth tokens so one compromised session cannot reach another user’s data, how scoped authorization tokens fix the confused deputy problem inside an agent’s own tool-calling logic, and how Cloudflare’s Access for Workers pushes vibe-coded internal apps toward a zero-trust default instead of open-by-default. Optional OAuth scopes attack the same problem from yet another angle: instead of trusting the agent, or its developer, to request only the minimum, it puts the final narrowing decision in the hands of the person actually granting access. Readers who want the OAuth fundamentals underneath all of this, authorization codes, redirect URIs, and PKCE, can find a from-scratch walkthrough in sxz.io’s OAuth 2.0 authorization code flow tutorial.

What’s next

Cloudflare says it is expanding optional-scope support over the next few weeks to cover nearly every Cloudflare product, meaning more API token roles, account membership options, and OAuth scopes will get the same treatment. The company credited two of its interns, Miller Vargas, a University of Texas at Austin senior studying computer science and math, and José Enrique Rodriguez, a Universidad Panamericana engineering senior, with building the feature. For developers, this is a configuration change rather than a new integration: existing Cloudflare Third Party OAuth clients can start marking scopes optional today.

The broader pattern is hard to miss. As more of what touches an account is an agent rather than a human clicking through a UI, the definition of “enough access” keeps shrinking, and the tooling for enforcing that shrinkage is having to catch up fast.