Step-up authorization lets an MCP task request an additional scope when it first needs that access. Begin with the minimum grant required for the initial workflow, handle the documented insufficient_scope challenge, and resume only after the user grants the additional authority. A refusal is a valid outcome. Do not describe it as a broken connection or silently retry the privileged action under broader credentials.
Scope the first task narrowly
Write a task-to-scope map before designing the consent screen. A reporting assistant may need to list records immediately but only rarely perform an administrative change. Keep the latter authority separate when the provider and host support incremental authorization. Scopes describe available operation classes; the application must still check tenant membership, record ownership and current business conditions when the tool executes.
Cloudflare announced step-up support for its API MCP server on October 19, 2026, with additional scopes requested through an insufficient_scope challenge and existing grants retained. The announcement explicitly limits availability to MCP clients that support step-up. This is provider-specific evidence, not a guarantee that every custom server or installed host can run the same flow.
Cloudflare: step-up authorization availability and client requirement
A synthetic list-then-admin journey
Suppose a fixture assistant starts with record:read and lists a fictional workspace's permitted records. The user later asks to archive an integration. The server requires integration:manage and rejects the under-scoped attempt through its supported authorization mechanism. The host presents the new grant request. If the user declines, the assistant explains that the administrative task remains undone and may continue permitted reads.
| Event | Stored task state | User-visible result |
|---|---|---|
| New scope needed | Awaiting authorization | Change not yet made |
| Approval succeeds | Revalidate and execute | Report actual outcome |
| User declines | Not executed | Explain remaining access |
| Host lacks support | Blocked authorization path | Offer documented recovery |
The scope names are invented for this example. They are not Cloudflare API scope names and should not be pasted into a real provider configuration. An actual integration must use the authorization server's documented scopes, challenge fields and resource binding. Verify which grant the host obtained after consent; a consent screen displayed successfully does not prove that the subsequent token carries the required authority.
Bind resumed work to the current request
A user can spend time deciding whether to approve. During that interval, a record may change or the user may alter the requested action. Revalidate the target, current permissions and operation version before execution. Consent to a broader scope is not approval of every future business action covered by that scope. Consequential operations may still need a preview or confirmation tied to the exact proposed change.
Keep one logical operation identity across the challenge and resume where the provider permits it. If the original tool call could have committed anything before demanding a new scope, the workflow becomes difficult to reason about. Prefer checking the required grant before side effects, then execute through the same domain service used by ordinary product clients. Preserve a clear pending state while authorization remains incomplete.
Proposed task states
ready_with_read_grant -> needs_additional_scope
needs_additional_scope -> approved -> revalidate -> execute
needs_additional_scope -> declined -> leave_change_unapplied
needs_additional_scope -> host_unsupported -> explain_supported_pathTest denial as carefully as approval
A disposable fixture should exercise approval, refusal, closed consent UI, unsupported host behavior and a grant that is later revoked. Capture whether the original operation ran, not only whether a token endpoint returned success. Confirm that previously granted reads still behave according to the provider's policy and that the assistant cannot claim the archive completed after a refusal.
No live step-up flow is executed in this guide. The state map is a proposed acceptance contract to run with named host and server builds. For a custom server, inspect metadata, challenge handling and token audience rules together before relying on incremental authorization. If a supported host cannot perform step-up, provide a documented reconnect or alternate approved workflow rather than requesting maximum access for every initial task by default.
MCP server authentication: trace the identity all the way to the record
Evaluate the tool action, not just the answer.
Bring one tool workflow, supported hosts and a sanitized failure trace for a scoped AI integration review.
AptixLabs ai agent development
How should MCP step-up authorization work?
Start with the needed grant, challenge for an additional scope when a task requires it, then resume only after approval and fresh application authorization.
Does a new scope authorize every business change?
No. Operation permission, record access and any required action confirmation still apply at execution.
Do all MCP clients support step-up?
No. Verify the actual host build and provider flow; Cloudflare’s announcement specifies supporting clients.