Cloudflare lets users strip scopes at the consent screen, and your agent has to cope

Cloudflare has shipped OAuth scope customization, which lets a client owner mark individual scopes as optional and lets the user deselect those scopes on the consent screen during authorization ^[1][2]. The narrowing decision moves out of whatever pre-consent screen the developer built and into Cloudflare's own consent flow, so a client that asks for four scopes can come back holding two ^[7][14].

The scale explains the timing. Since June, developers have created thousands of third-party OAuth apps on Cloudflare, with more than a million authorizations since ^[3]. Cloudflare's own account of the problem is that its permission model has become more granular over time, which is good for security but makes a purely all-or-nothing consent screen hard to justify ^[5]. Clients could already request a subset of their configured scopes, but the user at the end of that flow had two options: approve the full request, or deny ^[4].

MCP servers are the case Cloudflare names. An MCP server might request a broad permission set because an agent could in theory use all of it, and most users would not want an agent holding that much access ^[6]. The workaround, per Cloudflare, was for the app developer to build a custom scope selection screen and run it before handing the user to the consent flow ^[7]. Read plainly, that is the concession: the consent screen could not express what agent authors needed it to express, so they were routing around it.

The mechanics are conservative. Required and optional are evaluated only against the scopes requested in that specific authorization flow, not the full set configured on the client ^[9]. Cloudflare's example is a client configured for user-details.read, workers-scripts.write, workers-kv-storage.write and zone.read, with the last two marked optional ^[11]. Request all four and the user can drop the two optional ones, leaving two of the four granted ^[11][14]. Request only workers-scripts.write and zone.read, and only those two are evaluated, which leaves exactly one scope the user cannot remove ^[12][15]. Clients that do not opt in keep their current behaviour, a flow that requests no optional scopes looks the same as before, and the default remains a full grant of everything requested ^[10]. Opting in is a field on the client configuration, set when the client is created through Cloudflare's oauth_clients API ^[13].

The spec cover is real. OAuth already permits an authorization server to grant a narrower scope set than was requested, and Cloudflare says it built on that flexibility ^[8]. So the honest framing is not that Cloudflare changed the contract, but that it started exercising a clause clients were always supposed to handle. Plenty do not. Code that asks for workers-kv-storage.write and then assumes a KV write will succeed now has a user-controlled failure mode, and in an agent that failure surfaces mid-task rather than at login.

The practical consequences are three. Read the granted scopes off the token response, not off your own configuration. Degrade per capability rather than failing the whole session. And mark as required only what genuinely breaks the product, because every required scope is one a cautious user has to accept or abandon the install ^[1][10].

Worth watching: how many client owners actually mark anything optional, given the default grants everything anyway ^[10]; how a dropped scope gets re-requested when an agent later needs it; and whether other identity providers with agent traffic follow Cloudflare in putting the checkbox in front of the user instead of the developer.