The interesting line of code is not in the consent screen. It is at the token endpoint. You exchange the authorization code, and the response comes back with a scope parameter that lists what the user actually granted. Cloudflare's instruction is to inspect that parameter rather than treat a successful exchange as proof you received everything you asked for [14]. Under the old behavior a client could request a subset of its configured scopes, but the user's only moves were approve or deny, so the request and the grant were the same string [3].
Now look at the sample configuration. It declares four scopes and lists two of them in `optional_scopes` [5]. That leaves two the user cannot decline: `user-details.read` and `workers-scripts.write` [1]. Cloudflare's own recommended pattern for agents is to require read access to whatever the agent queries and make write access optional [17]. The sample marks `workers-kv-storage.write` optional and keeps `workers-scripts.write` mandatory, so it does not follow that pattern [2]. Either the illustration is deliberately showing a client that genuinely needs one write path, or the example got written after the docs.
None of the underlying latitude is new. RFC 6749 already lets an authorization server issue a token with a narrower scope than the one requested, and what has changed is providers surfacing that in the consent interface as agent integrations make broad requests routine [13]. GitHub documents that users can edit scopes and grant less than requested, and tells developers to handle it [8]. Google shows granular checkboxes for non-sign-in scopes [9]. Microsoft Entra reports the granted set in the token's `scp` claim [10]. The delta Cloudflare adds is that the developer, not the provider, decides which entries are droppable, and marking one required means a user narrowing the request cannot strip something the application needs to function [11][12].
For that lever to be worth pulling, you need a product that has a coherent shape with the optional scope missing. Cloudflare's guidance is to degrade: disable the feature and say so, rather than emit a 403 that the user reads as a broken integration [16]. Umesh Malik, a software engineer who writes on AI and developer tooling, frames the bind this replaces as a choice between requesting minimal permissions and breaking advanced use cases, or requesting everything and watching users bounce [18]. Marking a scope optional only escapes that bind if the agent checks the granted set before acting and stops cleanly when the authority is absent [17]. If it improvises instead, you have moved the failure from a screen the user was reading to a call they were not watching. Cloudflare's motivating case is concrete enough: an MCP server may request a broad permission set because an agent could in theory use all of it, while most users would not want an agent holding that much access [2]. An agent comparing inventory does not need to change prices, and one checking order status does not need to issue refunds [19].
