The MCP Privilege Escalation Blind Spot: Authorization Is Not Authentication

Introduction: An Overlooked Security Gap

As AI Agents gradually move from experimentation to production environments, managing their permissions has become an unavoidable topic. MCP (Model Context Protocol) has made an important contribution in this area — it standardizes how Agents request additional permissions. MCP is an open protocol introduced by Anthropic in late 2024, designed to establish a unified standard for interactions between Large Language Models (LLMs) and external data sources and tools. Before MCP, every AI Agent framework had to write custom integration code for each external tool, leading to severe ecosystem fragmentation. MCP adopts a client-server architecture and defines a series of standardized processes for how Agents discover available tools, pass context, and request execution permissions — think of it as the USB-C port of the AI world. MCP has already gained support from major AI vendors including OpenAI and Google DeepMind, and is becoming the de facto industry standard.

However, a critical issue has surfaced: While MCP addresses "scope step-up," it does not answer the question of "authentication step-up."

The core insight in one sentence: MCP standardizes how Agents request more permissions, but it doesn't yet have the vocabulary to ask whether the person behind the token is still present.

This seemingly subtle distinction actually touches on a fundamental blind spot in AI Agent security architecture.

The Essential Difference Between Scope Step-Up and Authentication Step-Up

How Scope Step-Up Works

In authorization frameworks like OAuth, "scope" defines the range of resources a token can access. OAuth 2.0 is the most widely used authorization framework on the internet today, allowing users to authorize third-party applications to access their resources without exposing passwords. Its core concept, "scope," defines the permission boundaries of an access token — for example, in GitHub's OAuth scopes, repo grants access to code repositories, while user:email only allows reading email addresses. In the OAuth flow, the client (in this case, the Agent) requests specific scopes, and after user consent, receives an Access Token with the corresponding permissions.

When an Agent needs to perform more sensitive operations — such as escalating from "read emails" to "send emails" — it needs to request a broader permission scope. This is scope step-up. MCP handles this well: it provides a standardized mechanism that allows Agents to declare in a structured way, "I now need higher permissions." This solves an important engineering problem in Agent tool invocation — the dynamic expansion of permissions.

It's worth noting that the IETF has already defined the OAuth 2.0 Step-Up Authentication Challenge Protocol in RFC 9470, providing technical specifications for resource servers to require clients to present higher levels of authentication. However, how this mechanism should be implemented within MCP's Agent interaction model remains an open question.

What Authentication Step-Up Solves

Authentication step-up is an entirely different matter. The question it answers is not "what can this token do," but rather "right now, is there actually a living, breathing person behind this token authorizing this operation?"

In traditional human-computer interaction, when you're about to perform a high-risk operation (such as a large fund transfer or account deletion), the system requires you to re-verify your identity — enter a password, perform two-factor authentication (2FA), biometric verification, and so on. Multi-factor authentication (MFA) technology has undergone significant evolution in this area: traditional SMS OTP has been gradually phased out due to SIM-swapping risks, replaced by more secure alternatives such as TOTP (Time-based One-Time Passwords, like Google Authenticator), FIDO2/WebAuthn-based hardware security keys (like YubiKey), and on-device biometrics (like Face ID and fingerprint recognition). This "re-confirmation" ensures the operation is genuinely initiated by the actual person at that moment, rather than being executed by a hijacked session or an automated script.

Why This Distinction Is Critical in the Agent Era

Agents Break the "Human Present" Assumption

In traditional applications, tokens are usually tied to a real person actively using the application. But in Agent architectures, the situation changes fundamentally:

• Agents may continue running for hours or even days after the human has left
• Agents may make autonomous decisions and trigger a chain of operations
• Tokens may be cached long-term, passed around, or even circulated among multiple Agents

In traditional web applications, Access Tokens are typically set with short expiration periods (e.g., 15 minutes to 1 hour), paired with Refresh Tokens for seamless renewal. But in Agent scenarios, token lifecycle management faces entirely new challenges. Agents may need to run in the background for days to complete complex tasks (such as monitoring data changes or generating periodic reports), requiring tokens with longer validity periods or frequent automatic refresh capabilities. However, long-lived tokens mean greater risk of theft and abuse — the attack window grows linearly with token validity. Furthermore, in multi-Agent collaboration scenarios, tokens may be passed and delegated through Agent-to-Agent communication, further blurring the question of "who is using this token." The Zero Trust principle of "never trust, always verify" becomes particularly relevant here.

This means that a token with sufficient scope does not guarantee there is real-time human intent behind the operation. Scope only answers "can it be done," but not "does the person want to do it right now."

High-Risk Operations Require "Human-in-the-Loop" Verification

Consider this scenario: your AI assistant has been granted permission to access banking APIs. One day, an injected malicious prompt (prompt injection) causes the Agent to attempt transferring a large sum of money. Prompt Injection is one of the most serious security threats facing AI Agents — attackers embed malicious instructions in data sources the Agent might read (such as email content, web page text, or document attachments), tricking the Agent into treating these instructions as legitimate user requests. This attack is particularly dangerous because current LLMs are architecturally unable to reliably distinguish between "user instructions" and "instructions embedded in data." Indirect Prompt Injection can even propagate across application chains, making Agents with broad permissions ideal attack vectors.

From a permissions perspective, the Agent is fully "authorized" to do this — the token's scope includes transfer operations. But from a security perspective, a critical piece is missing: there is no mechanism to confirm "whether a real person is authorizing this transfer at this moment." This is exactly where authentication step-up should come into play, yet MCP currently lacks the corresponding "vocabulary" to express this need.

MCP's Design Gap and Evolution Path

The Protocol Lacks Authentication Semantics

The core issue is this: MCP, as a protocol, lacks standardized semantics for expressing "please re-verify the human's identity." When an Agent encounters a high-risk checkpoint that requires real-time human confirmation, it has no standardized way to "pause and request proof of human presence."

The difficulty of implementing authentication step-up in Agent architectures lies in the fact that Agents themselves cannot perform biometric or password-based verification — they must "relay" the verification flow back to the human user's device. This requires a standardized interrupt-resume mechanism — the Agent pauses its current task, triggers a verification request on the human's device (such as a push notification requiring Face ID confirmation), and upon successful verification, the Agent receives a new token with "freshness proof" and resumes task execution. This flow is technically feasible but requires protocol-level standardization.

This isn't a design flaw in MCP — it's an evolutionary space yet to be filled. Any emerging protocol needs time to cover all edge cases, and the field of Agent security itself is rapidly evolving.

Four Viable Solution Approaches

To bridge this gap, the following directions can be considered at both the protocol and implementation levels:

1. Introduce an Authentication Challenge Mechanism: Add a new class of signals in MCP that allows resource servers to demand "fresh" authentication proof, rather than merely a valid token. This can draw on the Step-Up Authentication Challenge design defined in RFC 9470, adapted to MCP's request-response model.

2. Token Freshness Markers: Distinguish between tokens that were "just verified by a human" and those that have been "cached long-term," allowing sensitive operations to accept only the former. Specifically, an auth_time (most recent authentication time) field can be embedded in the token's Claims, and resource servers can set acceptable maximum authentication time intervals based on operation sensitivity — for example, requiring auth_time to be within 5 minutes for transfer operations.

3. Human-in-the-Loop (HITL) Hooks: Design standardized human confirmation flows for high-risk operations, requiring the Agent to obtain real-time authorization before execution. HITL implementation in AI Agent contexts typically includes several patterns: synchronous confirmation mode — the Agent pauses before executing sensitive operations and requests explicit approval from the user via push notification; asynchronous approval queues — the Agent places high-risk operations in a pending approval queue for periodic human review; and tiered autonomy mode — dynamically determining the degree of autonomy based on operation risk level. The technical challenge of implementing HITL lies in maintaining security without excessively interrupting the Agent's workflow, avoiding "confirmation fatigue" that leads users to blindly approve every request.

4. Operation Risk Tiering Mechanism: Dynamically decide whether to trigger authentication step-up based on the sensitivity of an operation. This requires establishing a standardized risk assessment framework that comprehensively considers factors such as operation type (read vs. write vs. delete), asset value involved, frequency anomaly, and Agent session duration, automatically calculating risk scores and matching them to corresponding verification requirements.

Security Design Checklist for AI Agent Developers

For developers building Agent systems, this insight provides important security design reminders:

• Don't equate "having permission" with "having intent." A token's scope is only one part of access control and should not be the sole gateway for high-risk operations. In security engineering, this embodies the principle of "Defense in Depth" — not relying on a single security layer, but establishing protections at multiple levels.

• Design separate confirmation mechanisms for sensitive operations. Even if the MCP protocol itself doesn't provide this, implement "human-in-the-loop" protections at the application layer. In practice, maintain a "sensitive operations whitelist" that includes operations involving fund transfers, data deletion, permission changes, and external communications within a mandatory confirmation scope.

• Be wary of long-running Agent sessions. The longer the session, the less reliable the assumption that "the person is still present" behind the token. Consider implementing session timeout policies — for Agent sessions that haven't had human interaction beyond a set duration (e.g., 30 minutes), automatically downgrade the risk level of executable operations and force re-authentication when high-risk operations are attempted.

• Implement the Principle of Least Privilege. An Agent should only hold the minimum scope of permissions needed to complete its current task at any given moment, rather than being pre-granted broad permissions. Permissions that are no longer needed should be promptly revoked after task completion to minimize the potential attack surface.

Conclusion

MCP has taken an important step in standardizing Agent permission management, but scope step-up is not authentication step-up. The former manages "what can be done," while the latter confirms "who is authorizing it at this moment."

In an era of increasingly autonomous AI Agents and increasingly long-lived tokens, this distinction is no longer an academic detail — it's a practical issue that concerns fundamental security. Identifying and filling this gap is a necessary step on the path to mature Agent security infrastructure. As the Agent ecosystem rapidly expands — from personal assistants to enterprise automation, from single-Agent to multi-Agent collaboration networks — establishing a standardized security framework that encompasses authentication step-up semantics has become a priority that the entire industry urgently needs to advance together.