Step-up authorisation in MCP: start agents with minimal scopes

Most OAuth consent screens for MCP servers ask for everything at once. An agent that only needs to read a few DNS records ends up holding a token that can also delete them, because the person connecting it did not want to be asked again later. On 19 October 2026 Cloudflare changed that for its API MCP server: it now supports the step-up authorisation flow from the MCP specification, so a client can connect with minimal access and ask for more only when a task needs it. The feature is defined in the protocol, not by one vendor, so it is worth understanding how it works and where it can go wrong.

What changed

The Cloudflare changelog entry describes the behaviour in a few lines. It says users can "grant only the required scopes when you connect, then authorize more on demand as your agent performs a task." When a tool call needs a scope that has not been granted, the server returns an insufficient_scope challenge naming it, and the MCP client asks the user to approve it. Scopes already granted are kept. To start with the least access, the user chooses Minimal on the consent page.

The entry says it works in "all MCP clients that support step-up authorization". That qualifier matters: the benefit depends on the client, and a client without support will see a failed call instead of a prompt.

How step-up works in the specification

The mechanism is built from standard OAuth parts. RFC 6750 defines the insufficient_scope error: the request "requires higher privileges than provided by the access token", and the resource server should answer with HTTP 403 and may name the scope it needs.

The 2026-07-28 MCP authorisation specification builds a flow on that. When a client's token lacks a scope at runtime, the server should respond with a challenge like this one (shortened from the specification's example, which also has an error_description):

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope",
  scope="files:write",
  resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

The client then parses the challenge, works out the scope set it needs, re-authorises, and retries the original request. A few rules in the current text are worth reading closely:

• Keep earlier scopes. The client determines the new scope set "by computing the union of the client's previously requested scope set and the scopes from the current challenge". The specification calls this the scope-union requirement and makes scope accumulation a client-side responsibility.
• One challenge per operation. Servers should include all scopes the operation needs in a single challenge. Asking for one scope, then another on the retry, forces several round trips for one call.
• Hierarchies count. Servers must account for scope hierarchies, where a broader scope implies narrower ones, when deciding whether a token is enough.
• Retries are limited. Clients should retry only a few times, track upgrade attempts, and treat repeated failure as permanent.
• Users and machines differ. Clients acting for a user should attempt step-up. Clients acting on their own behalf, with the client_credentials grant, may step up or abort.

What the previous revision said

The 2025-11-25 revision already had a step-up flow with the same retry advice, but it put the job of keeping earlier permissions on the server. Its recommended approach was for a server's challenge to include "both existing relevant scopes and newly required scopes to prevent clients from losing previously granted permissions", and clients determined scopes "as outlined in Scope Selection Strategy". The current text moves that job to the client, with the explicit union step, and adds the single-challenge guidance and the hierarchy rule. During the transition, a client written to the older text that meets a server written to the newer one could replace its token with one holding only the newly challenged scope, and lose access it had a moment earlier. If you maintain an MCP client, check which behaviour it implements. We covered the wider changes in the 2026-07-28 revision when it was published.

Why it matters for agents

Least privilege has been hard to apply to agents for a practical reason: nobody knows in advance which tools a task will need. Teams have either granted wide scopes up front or given up on the agent halfway through a task. Step-up offers a middle course. The standing token stays small, and each widening happens at the moment it is needed, with a person in the loop.

It does not remove every risk:

• Consent fatigue. A prompt that appears mid-task, while the user is waiting for a result, is easy to approve without reading. A poorly designed server that challenges one scope at a time makes this worse. Our article on what an agent approval actually approves looks at what a prompt should show so that the approval means something.
• Scopes only grow. The union rule keeps earlier grants, so a long-lived session ends with every scope it ever needed. The step-up flow describes how scopes are added. It does not describe dropping them. Short token lifetimes, or reconnecting with Minimal for new work, keep the set small.
• Unattended agents. A scheduled or headless agent has no one to approve the prompt. For those, a fixed, reviewed grant, or the abort path, is more predictable than step-up.
• Prompt injection. An injected instruction can push an agent towards a write tool, and the step-up prompt then asks a person to approve that wider access. The prompt is a control only if the person can see why the scope is wanted.

What it means for engineering and security leaders

• Check client support before relying on it. The server-side change is only half of the flow. Test each MCP client your teams use against a server that issues insufficient_scope challenges.
• Prefer Minimal as the default for new connections, and make widening an explicit act.
• Set token lifetimes with accumulation in mind. A scope granted for one task should not stay on a token for weeks.
• Treat service accounts separately. For client_credentials agents, decide the grant in review and let the client abort rather than step up.

Practical takeaways

• When connecting the Cloudflare API MCP server, choose Minimal and let the client request more.
• In MCP clients you build, compute the union of scopes on step-up, cap retries and log every scope upgrade.
• In MCP servers you build, return all required scopes in one 403 challenge, include resource_metadata, and handle scope hierarchies.
• Show the user which tool and which action triggered the request for a new scope.
• Review long-running agent sessions for scopes that were granted once and never used again.

SpanDock's MCP gateway, on the Premium and Enterprise plans, takes a related approach on your own server: a connector can use each person's own account so the service's permissions apply, while the gateway's rules apply first and can only narrow that access. Connectors start read-only, and destructive tools need approval. On Enterprise, just-in-time access lets people request a connector's write tools for a limited time, up to 8 hours. A named approver grants each request, and nobody can approve their own.