A protocol pattern that moves sensitive user interaction out of the MCP client and model context into a trusted external surface. It is used for OAuth, credential entry, and similar flows where secrets must stay outside the conversation path.
How URL-Mode Elicitation Works
URL-mode elicitation shifts a sensitive interaction, such as OAuth consent or credential entry, out of the MCP client and model context and into a trusted external surface. The pattern matters because the model can coordinate the flow without ever seeing the secret itself, which reduces exposure while preserving a guided user journey.
In practice, the key security value is separation of duties between orchestration and secret handling. The assistant can request or continue the flow, but the user completes the sensitive step in a browser or other trusted surface designed for authentication, consent, or identity verification.
Why It Exists in MCP Flows
URL-mode exists because some interactions should not traverse conversation history, logs, or tool context at all. That is especially important when the flow involves OAuth redirects, login prompts, or other steps where a transient secret, code, or token could be exposed if handled inside the chat channel.
This design also helps preserve user trust. A trusted external surface can present the right origin, branding, and consent context more clearly than a model-driven prompt, which lowers the chance that a user confuses an authentic authorization step with a fabricated request.
Security Properties and Trust Boundaries
URL-mode elicitation is fundamentally about keeping sensitive material on the right side of the trust boundary. The model may initiate the interaction, but it should not observe passwords, authorization codes, session tokens, or other secret values that belong in the browser or identity provider flow.
That boundary reduces the blast radius of prompt injection, logging mistakes, and overbroad transcript retention. It also forces the implementation to treat the external surface as a controlled handoff point rather than an arbitrary link, which means origin validation, same-user checks, and clear return-path handling become part of the design.
The NHIMG MCP Sampling and Elicitation Security Guide covers the related security rules for URL mode, form mode, phishing resistance, and same-user checks.
Common Failure Modes
The main failure is treating URL-mode as a cosmetic redirect rather than a security control. If the returned URL can be swapped, replayed, or associated with the wrong user session, the flow can become a phishing or token-substitution path instead of a safe handoff.
Another failure mode is letting the model or client retain more state than necessary. Even when secrets are not directly exposed, poorly designed request correlation, weak state validation, or permissive redirects can let an attacker bind the wrong authorization result to the wrong conversation or user.
For a protocol-level reference point, the Model Context Protocol: Authorization specification explains how OAuth-oriented MCP authorization should avoid token passthrough and use audience-bound tokens.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | URL-mode often carries OAuth and login handoffs that must preserve auth integrity. |
| Recommendation — Validate the external auth handoff so returned tokens and codes are bound to the expected user flow. | ||
| NIST SP 800-63 | Digital Identity Guidelines | URL-mode is used for phishing-resistant authentication and external verification flows. |
| Recommendation — Use phishing-resistant identity flows when the interaction moves outside the MCP client. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Sensitive secrets should stay out of conversation paths and be handled as protected authenticators. |
| Recommendation — Store and rotate secrets so the model never processes or retains them in chat context. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org