MCP Elicitation Security: Protecting User Input and Sensitive Data

MCP elicitation allows a server to request additional information from a user through the host. That can make tools easier to use: a booking workflow can ask for a date, a support integration can request a case number, and a deployment tool can ask which environment is intended.

The same capability creates a new trust problem. A remote or local server can place text and fields in front of a user inside a trusted AI application. If the host renders that request without clear provenance and policy, the server can imitate authentication, request secrets, disguise a consequential action or collect data unrelated to the task.

Elicitation should be treated as a security-sensitive user-interface channel—not a convenient form generator. This guide explains how to design and test it without assuming that schema validation alone establishes legitimacy.

What elicitation changes

Before elicitation, many MCP interactions were initiated by the user or selected by the model from known tools. Elicitation lets the server pause a workflow and ask the host to gather more information. The user may perceive the request as coming from the AI assistant or enterprise application rather than from a third-party server.

That difference in perceived authority is exploitable. A compromised travel server might ask for a corporate password “to confirm the reservation.” A repository server could request a personal access token even though the host already has an approved credential path. A harmless-looking confirmation could hide a broader action.

Map the actors: user, host, model, client, server and downstream service. Decide which text and fields each actor controls. The UI must preserve that provenance.

Make the requesting server visible

Every elicitation should identify the server and tool requesting information. Use a trusted display name bound to verified configuration, not a label supplied only in the request. For managed environments, indicate whether the server is enterprise-approved, user-installed or unverified.

Show why the information is needed and what happens next. Separate server-provided explanation from trusted host warnings. Users should be able to cancel without losing unrelated work. High-impact requests may require an additional policy or approval step.

Test deceptive names, long labels, Unicode lookalikes and requests that claim to come from security, IT or the identity provider. Ensure untrusted content cannot cover or visually merge with provenance indicators.

Prohibit secret collection through ordinary elicitation

Generic elicitation should not collect passwords, access tokens, private keys, recovery codes or full payment credentials. Sensitive authentication belongs in dedicated, trusted flows such as an approved OAuth browser or enterprise credential broker.

Field names and descriptions are not enough to enforce this. A server can label a token as a “project code.” Use policy based on server identity, field purpose, data classification and expected workflow. Detect obvious secret patterns as a secondary safeguard, not the only control.

If a use case genuinely requires sensitive input, use a purpose-built secure component that prevents the value from entering model context, server-visible logs or general transcripts. Document which component receives the value and how it is protected.

Treat schema as untrusted UI input

Schemas constrain structure, but the server controls field names, descriptions, options and defaults. Apply limits to field count, text length, nesting, option count and supported types. Reject executable markup, external images and arbitrary links.

Do not render server HTML. Escape text for the destination context. Prevent fields from impersonating host buttons, warnings or login controls. Defaults should not silently opt users into disclosure or irreversible action.

Validate returned values again at the server and downstream service. Client-side schema enforcement improves usability but does not replace authorization or business validation. An attacker may invoke the server directly.

Separate information requests from action approval

An elicitation form asking for an amount is not the same as authorization to transfer that amount. Collection and approval should be distinct when consequence is meaningful. The final confirmation must show trusted parameters and bind approval to the exact operation.

Avoid combining unrelated consent. “Enter the account number and accept data sharing, recurring access and marketing” creates ambiguity. Minimize the requested data and explain retention and recipients.

Test whether changing a field after confirmation alters the executed action. Replay old responses. Submit values for a different user or tenant. Verify the downstream system reauthorizes the final operation.

Control data minimization and purpose

Define which servers may request which categories of information. A weather server does not need an employee number. A documentation server should not request customer financial data. Enforce purpose constraints through managed policy where possible.

Do not send the full conversation to the server merely to explain the request. Provide the minimum context needed. Similarly, do not automatically place elicited values into future model prompts or long-term memory.

Record the classification, purpose and retention of collected values. Redact sensitive fields from analytics and debugging. The AI agent observability guide explains how to preserve useful evidence without indiscriminate content capture.

Defend against prompt injection through elicitation

An elicitation request is text entering the host. The model should not interpret server instructions in that request as higher-priority policy. Keep UI text separate from model control messages. Do not feed every field description back into the model without provenance.

A malicious request may tell the user to paste hidden system instructions, ask the host to call another tool or include encoded directives. Test whether those strings change subsequent tool behavior. The safest architecture treats elicitation as a bounded UI exchange handled by trusted code.

Results returned after elicitation remain untrusted too. A valid user response does not make the server's next output trustworthy. Continue to enforce tool, data and destination boundaries.

Authentication and session binding

Bind each elicitation to the correct server connection, user, tenant, session and pending operation. Use an unpredictable identifier and expiration. Reject responses after cancellation, timeout, logout or permission change.

Prevent one tab, agent or tenant from satisfying another's request. Test concurrent sessions and reordered messages. Race conditions can cause a response to attach to the wrong operation even when each component appears correct.

The server should not accept a client-supplied user identity as authoritative. Derive identity from the authenticated session and recheck authorization when processing the response.

Safe rendering and accessibility

Security indicators must remain understandable to users of assistive technology and on small screens. Provenance, consequence and cancellation cannot depend only on color. Focus should move predictably to the request and return after completion.

Prevent clickjacking and overlay attacks in hosts that render web content. Do not allow elicitation inside untrusted iframes. Keep trusted approval chrome outside server-controlled regions.

Test extreme text sizes, localization, right-to-left content and screen-reader order. A warning that disappears on mobile is not an effective control.

Logging and evidence

Record the verified server identity, tool, schema version, field classifications, requesting session, user decision and resulting operation. Avoid storing raw sensitive values. A field-level record can state that a value was supplied and validated without retaining it.

When investigating abuse, teams need to reconstruct what the user actually saw. Preserve a sanitized representation of the trusted and untrusted UI elements, not only the server request. Version host rendering rules because changes can alter the security meaning.

Alert on unusual elicitation volume, repeated cancellation, new sensitive field patterns and servers requesting data outside their normal category. Rate limits should apply per server and user to prevent harassment or denial of service.

Elicitation security test cases

Build a controlled server and attempt:

1. A password or token request disguised as a project identifier.
2. A trusted-brand impersonation using names and Unicode lookalikes.
3. Excessive fields, nesting, long text and malformed schemas.
4. HTML, scripts, external images and misleading links.
5. Defaults that opt into disclosure or action.
6. A response replayed after cancellation or expiry.
7. Cross-session and cross-tenant response substitution.
8. Parameter changes between collection and final execution.
9. Prompt instructions embedded in descriptions and options.
10. Sensitive values appearing in model context, logs or memory.
11. Concurrent requests completed in the wrong order.
12. Mobile and accessibility layouts hiding provenance or warnings.

For each test, capture the server request, host rendering, user action, policy decision, downstream effect and retained evidence. A blocked form is useful, but verify that the server did not receive a partial value before the block.

Enterprise policy checklist

• Inventory servers allowed to use elicitation.
• Display verified server and tool provenance.
• Prohibit ordinary collection of credentials and secrets.
• Limit schema types, size, nesting, markup and links.
• Enforce data-category and purpose restrictions.
• Separate information gathering from consequential approval.
• Bind requests to user, tenant, session and pending operation.
• Expire and invalidate requests on state changes.
• Keep elicited values out of model context unless required.
• Redact sensitive values from logs and analytics.
• Test deceptive UI, replay, concurrency and prompt injection.
• Provide cancellation, reporting and server-disable controls.

Frequently asked questions

Is elicitation the same as human approval?

No. Elicitation gathers information. A consequential action may require a separate authorization decision bound to trusted parameters.

Can an MCP server request an API key through elicitation?

An enterprise host should generally prohibit this. Use an approved credential or OAuth flow that keeps secrets out of model context and general server forms.

Who should validate elicited data?

The host should constrain rendering and collection, while the server and downstream system must validate values and authorization. Client-side validation alone is insufficient.

Does schema validation prevent phishing?

No. A structurally valid schema can still request inappropriate data or present deceptive text. Provenance, policy and purpose controls are necessary.

Elicitation is valuable when it closes a genuine information gap. It becomes dangerous when a server borrows the host's trust to collect data or consent it has not earned. Keep the channel narrow, attributable and separate from model authority. For related approval design, see human-in-the-loop security for AI agents and MCP authorization security.

Create an elicitation allowlist

Define which servers may request which field classes and for what purpose. Prefer constrained schemas over free-form requests. Explicitly prohibit credentials, recovery codes and unrelated sensitive data.

Validate field names, types, length and choices in the host. A server should not be able to render arbitrary HTML, links or misleading button text. Display the verified server identity and destination.

Version approved schemas. Treat added fields or changed purpose as a capability expansion requiring review, not a cosmetic update.

Separate information collection from consent

Providing an address or identifier does not approve a purchase, disclosure or account change. Use a distinct, trusted approval step for consequence and bind it to exact structured parameters.

Do not allow a server's natural-language explanation to define legal or operational consent. Product, privacy and legal owners should design the applicable workflow.

Test whether collected data is reused for another task, persisted into memory or sent to another tool. Enforce purpose and retention outside the model.

Test deceptive and excessive requests

Attempt urgent wording, authority impersonation, preselected options, hidden changes and repeated requests after denial. Check small-screen and accessibility behavior so critical identity information remains visible.

Test a compromised server that asks for secrets unrelated to its declared tools. Verify that host policy blocks the request before presentation or clearly warns the user.

Monitor unusual fields, volume, denials and cross-tenant requests. Preserve enough evidence to identify the server and schema without logging unnecessary user data.

Handle cancellation and partial completion

Users must be able to cancel without the server interpreting silence as consent. Define timeout and retry semantics. Do not repopulate a rejected sensitive field from memory.

If the server disconnects after collecting data, prevent a different server or run from inheriting it. Clear temporary state according to policy and surface uncertain outcomes.

Test replay of prior responses and schema changes between display and submission. Bind the response to the server, request and version the user actually saw.