Testing Cloudflare's MCP step-up authorization: what changes for agent access control

Cloudflare adds step-up authorization to its API MCP Server

On October 19, 2026, Cloudflare announced that its API MCP Server now supports step-up authorization: connect an agent with only the scopes it needs, then approve more on demand when a tool call turns out to require them. A developer who built a custom MCP client and sent 128 requests to the live service has published a hands-on comparison on dev.to, contrasting the mechanism with Google's long-standing incremental authorization. The findings are relevant to anyone building agents that talk to scoped APIs.

The core conclusion is that step-up authorization is not a new way to grant access. The authorization step itself is an ordinary OAuth authorization-code flow. What is new is a defined path for the server to tell the client that a permission is missing — something that matters because an AI agent, not a developer, chooses which tools to call, so a client cannot know in advance which scopes it will need.

Two scope lists, 382 entries apart

According to the dev.to analysis, Cloudflare's MCP endpoint publishes two different scopes_supported lists. Protected Resource Metadata (RFC 9728) names two scopes — user:read and account:read — described as the minimum for basic functionality. Authorization Server Metadata (RFC 8414) lists 384 scopes, including items such as dns.write, zone.write and workers-r2.read.

That gap is why the feature exists. Without step-up, a first-time client has to choose from 384 scopes up front. Request too few and operations fail; request too many and the agent ends up overprivileged. Starting with two scopes is practical only if more can be granted when a task reveals the need.

Standard OAuth underneath

The error that starts the flow — a 403 with insufficient_scope in a WWW-Authenticate header — was defined in RFC 6750 in 2012. What the MCP specification adds is the surrounding procedure: parse the challenge, form the union of the scopes requested last time and the scopes named in the challenge, reauthorize through the normal authorization-code flow, and retry the original request.

Measured against Google's incremental authorization, the dev.to author draws the distinction along three lines: who notices that more access is needed (the application in Google's model, the server in MCP's), how the missing scope is communicated (implicitly by Google, explicitly via a challenge by MCP), and who remembers previously granted scopes — the authorization server when include_granted_scopes=true on Google's side, the client on MCP's.

The feature is also less new than the changelog implied. The step-up flow already existed in the 2025-11-25 MCP specification and was absent before 2025-06-18. The 2026-07-28 revision changed one significant thing: it moved responsibility for assembling the scope union from the server to the client.

What the live tests found

Cloudflare's changelog said scopes already granted are kept, without saying by whom. Live testing settled the ambiguity from both directions. Cloudflare's authorization server does not carry previously granted scopes into new grants beyond the baseline set — the two metadata scopes plus offline_access — the opposite of Google's behavior, which means MCP clients genuinely have to maintain the union themselves. Yet the server did mirror a token's granted scopes when building 403 challenges, an approach the 2026-07-28 specification had moved away from.

Coverage was also inconsistent. On the same server, some under-authorized operations returned a proper 403 challenge while others returned HTTP 200 with an empty list. Listing zones and listing Workers scripts both came back empty before the relevant scopes were granted and populated afterwards (three zones, twelve scripts). Listing D1 databases returned a challenge before authorization and five items after. The author reported the gap to Cloudflare, and it was fixed the same day.

The change was the third step in a rollout: Wrangler and the API MCP Server gained optional scopes and an Edit Permissions consent option on August 22, 2026, and workers-oauth-provider v1 shipped on October 1 with a one-line insufficientScope() helper for server authors.

Why it matters

The empty-list failure mode is the quiet danger. When the challenge path works, an agent can start with minimal privileges and escalate with user approval. When it does not, the agent does not report a permission problem — it reports that the resource does not exist. In the author's case, an agent told them there were no zones; there were three. For agent developers, the practical lessons are to track granted scopes client-side rather than assuming the server will, and to treat empty results from scoped APIs with suspicion. For MCP server builders, the lesson is to issue challenges consistently, because to a model with no other way to check, silent emptiness is indistinguishable from absence.