MCP Elicitation Security: Separate User Input from Credentials

An MCP server can pause a workflow and ask the user for more information through the client. The 2025-11-25 Model Context Protocol specification calls this elicitation. It supports form mode for structured responses and URL mode for sensitive interactions that must occur outside the MCP client.

That split creates a security boundary. A form can collect a project name or shipping preference after user review. Passwords and API keys belong in URL mode. Access tokens and payment credentials belong there too, where the user interacts directly with the external service and the client stays outside credential custody.

TL;DR

• MCP elicitation supports form mode and URL mode, declared through client capabilities.
• Form mode must stay free of passwords and API keys. Access tokens and payment credentials must also stay out.
• URL mode requires explicit user consent and a visible destination. It also requires careful URL handling and identity-bound server state.
• The MCP server retains third-party tokens obtained through the external flow and keeps them away from the MCP client.
• Completion notifications need correlation and replay handling. They also need timeouts and manual recovery controls.

Elicitation begins with capability negotiation

The official MCP elicitation specification requires clients that support elicitation to declare the capability during initialization. A client can advertise form mode, URL mode, or both. An empty elicitation capability retains backward compatibility with form mode.

Servers should treat that declaration as a hard protocol limit. Sending URL mode to a form-only client should produce an invalid-parameters response rather than a fallback that exposes sensitive data in a form. Preserve the negotiated capabilities with the session record and server identity. Preserve the client identity and protocol version with them.

My preference is to fail the workflow in plain language instead of improvising a weaker interaction. A red error line saying "URL elicitation unsupported" is safer than a helpful client quietly rendering credential fields it was never designed to protect.

Form mode needs strict field and consent rules

Form mode lets a server send a human-readable message and a schema for structured input. The client presents the request, allows the user to review or modify the response, and returns an action such as accept, decline, or cancel.

The server should bind the request to the client and user identity. Give each request a unique identifier and expiry. Limit schema size and field count. Limit nesting and string length. Restrict accepted formats. Render labels and descriptions as untrusted server content. Prevent markup or links from hiding the identity of the requesting server. Block Unicode tricks that have the same effect.

The specification prohibits form mode for credentials and other secrets that authorize access or transactions. Add server-side field-name and content checks as a backstop. A field labelled "workspace token" should fail even if the schema declares it as an ordinary string.

The MCP security best practices guide covers the wider rule: authorize each HTTP MCP operation under the current caller and policy rather than treating session establishment as permanent approval.

URL mode keeps sensitive interaction outside the client

URL mode sends the user to an external destination for an interaction such as OAuth authorization. The client must show the full URL and highlight the destination host. It must obtain explicit consent before opening it. The specification bars automatic prefetching because a preview request can leak state or trigger server behaviour before consent.

Open the URL in a secure browser surface that prevents the MCP client and LLM from inspecting the page or user input. The specification names SFSafariViewController as a suitable iOS example and rejects an embedded WKWebView for this purpose.

The server must keep credentials and personal data out of the elicitation URL. Pre-authenticated access must stay out too. Use opaque, short-lived correlation state. Validate the return path against the stored request and user. Check the client and expiry as well. Reject reused state and mismatched sessions.

Token custody belongs to the MCP server

For a third-party authorization flow, the MCP server acts as the OAuth client to that service. The user authorizes the server directly outside MCP. The external authorization server redirects to the MCP server, which stores third-party tokens under the user's identity.

Those tokens remain distinct from the credentials the MCP client uses when accessing the MCP server. The protocol's security best practices prohibit token passthrough, where a server accepts a token issued for another service and forwards it without proper audience and claim validation.

Store third-party tokens in a credential service with encryption and access controls. Enforce expiry and rotation. Support revocation and use logging. Keep them out of MCP messages and general application logs. The MCP OAuth authorization security guide explains the adjacent authorization-server and resource-server duties.

Completion needs correlation and recovery

User consent to open a URL means the external interaction may begin. Completion requires a separate event. The MCP server may later send notifications/elicitation/complete with the original elicitation identifier.

Send that notification only to the client that initiated the request. Clients should ignore unknown or completed identifiers. Add a timeout and keep manual retry or cancel controls available when the notification never arrives. Deduplicate repeated notifications and original-request retries so a reconnect triggers the protected operation at most once.

Preserve the elicitation identifier and user. Record the client and requesting server. Keep the URL host and consent action. Add the completion time and retry count. Preserve the final operation result. Exclude URL query secrets and tokens. This gives an investigator a timeline without turning the audit store into a credential cache.

Rate limits and user interface details are security controls

A malicious or defective server can flood the client with elicitation requests and interrupt work. Repeated prompts can also train users to click accept. Apply per-server and per-user rate limits. Collapse duplicate prompts and expose the requesting server prominently. Give decline and cancel equal visual weight.

For form mode, show every field before submission and let the user edit the response. For URL mode, show the full destination before opening it. Warn on ambiguous hosts and user information in the authority component. Also warn on non-HTTPS destinations outside development and unusual ports.

Test the interface with long server names and right-to-left characters. Put two similar hostnames side by side on a test screen. If an engineer needs a magnifying glass to tell the legitimate domain from a subdomain trick, the consent view needs work.

Keep elicitation separate from model-route authorization

Elicitation controls information exchange between an MCP server and client acting for the user. A later LLM request requires a separate authorization before carrying that data to a model. The MCP host should attach a stable workflow identifier and the authenticated principal when it sends an HTTP model request.

A separate model-route policy can then evaluate the use case and data classification. It can also evaluate the model destination and policy version. Tool execution also needs its own authorization. The MCP tool call authorization guide covers approval at that action boundary.

Local STDIO sessions and browser surfaces stay outside an LLM HTTP gateway. OAuth callbacks and token storage stay outside it too. Keep their events joined for investigation while preserving the ownership split.

DeepInspect

DeepInspect can enforce policy when an MCP-enabled application sends an authenticated HTTP request to an LLM through a governed route. It can evaluate application-supplied identity and role. It can also evaluate data classification and use case. The destination and policy version complete the decision context. DeepInspect can then record a permit or deny result, including any redaction decision.

MCP elicitation messages and consent screens remain outside that boundary. OAuth callbacks and third-party token storage also remain outside it. Local STDIO remains outside as well. The application can join the MCP and model-route records with a workflow identifier without treating one control as a replacement for the other.

Book a technical deep dive at deepinspect.ai.