Cloudflare has introduced optional OAuth scopes, allowing users to deselect specific permissions on consent screens rather than accepting or rejecting an application's entire access request. The company announced the feature with AI agents and MCP servers as the primary use case, addressing a problem where agents request sweeping permissions users rarely want to grant in full. Client owners can now designate which scopes may be removed, giving users granular control without forcing developers to build custom permission screens before the authorization flow.
The feature targets a mismatch specific to agent applications. According to Cloudflare, an MCP server might ask for a wide array of permissions because theoretically an agent could utilize all of them, while most users wouldn't want an agent holding that level of access. An agent reading inventory to compare products doesn't require permission to modify prices. One checking order status doesn't need authority to process refunds. One reviewing supplier records during research doesn't need payment access. The authorization request exposes the combination of everything the agent might ever perform, and the consent screen requires the user to approve it all simultaneously. Software engineer Umesh Malik, who writes on AI and developer tooling, characterizes the dilemma this creates: developers must either ask for minimal permissions and break advanced features, or request everything and lose users at the consent screen. Previously, Cloudflare OAuth operated as all or nothing—a client could request a portion of its configured scopes, but once it did, the user could only approve the complete set or deny it.
Client owners now mark scopes as optional when setting up an OAuth client, using an `optional_scopes` array beside the existing list. Required and optional scopes are assessed against the scopes requested in a particular authorization flow, not against everything configured on the client. Clients that don't adopt the feature retain their current behavior, and the consent screen still grants the full requested set by default. Partial consent isn't new—GitHub's documentation states users can edit their scopes and grant an application less access than requested, while Google displays granular checkboxes for non-sign-in scopes and Microsoft Entra supports incremental consent. What Cloudflare contributes is developer control over which permissions may be dropped. When a user deselects an optional scope, the access token carries only what was granted, and 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 encounter authorization errors on calls it expected to work.
Cloudflare's guidance is to degrade rather than fail—an application losing a write scope should disable that feature and communicate it, instead of showing a 403 error 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, and 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, and 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. The shift means developers can no longer assume a successful token exchange delivers every requested permission, forcing a new layer of runtime checks that distinguish features users trust from those they don't. As agent integrations normalize broad permission requests, consent interfaces are surfacing the latitude OAuth already permitted, turning user choice from a binary gate into a negotiation over individual capabilities.