MCP Elicitation Needs a Sensitive Data Gate

MCP elicitation is useful because it lets a server ask the user for missing information.

That also makes it a data boundary.

Short answer

Treat MCP elicitation as a permissioned data request. Before enabling it in a sensitive workflow, review which server can ask, what schema fields it can request, whether the fields include sensitive data, whether untrusted content can shape the request, what happens after the user accepts, how decline and cancel work, how repeat requests are rate-limited, and where the decision is logged. If you cannot deny, narrow, or audit the request, elicitation is too trusted for sensitive data.

What elicitation changes

Most MCP reviews focus on tools.

What can the server expose? What can the model call? Can the tool read private files, write to an issue tracker, query a database, or send data somewhere else?

That review still matters.

Elicitation adds a different question:

Can this server ask the user for more data?

The MCP elicitation specification describes elicitation as a way for servers to request additional information from users through the client during interactions. The server asks for structured data with a restricted JSON Schema subset. The client presents the request and returns the user's response.

That can support good workflows. A server may need a project name, a deployment target, a date range, or a missing preference before it can continue.

The risk is that the request feels like a harmless clarification when it is really a server-initiated data collection path.

If the server can choose the fields, the client needs a gate around the request.

The spec already gives you the shape of the gate

The MCP elicitation source card captured several controls that matter for builders:

• Servers must not use elicitation to request sensitive information.
• Applications should make clear which server is requesting information.
• Applications should let users review and modify responses before sending.
• Responses use a three-action model: accept, decline, or cancel.
• Clients should implement user approval controls and rate limiting.
• Requests should be presented in a way that makes clear what information is being requested and why.

That is not just interface polish.

It is a security control.

A user should know who is asking, what they are asking for, why it is needed, and what happens if the answer is sent. The user also needs a real decline path. A prompt that keeps coming back until the user accepts is not meaningful consent.

Sensitive fields should be denied by default

The cleanest rule is simple:

Do not let elicitation request sensitive information.

OWASP LLM02: Sensitive Information Disclosure lists sensitive information categories that map cleanly to elicitation review:

• PII
• Financial details
• Health records
• Confidential business data
• Security credentials
• Legal documents

That list should become a blocked field class for MCP clients and review checklists.

If a schema asks for an API key, customer identifier, private customer note, payment detail, medical detail, credential, legal summary, or confidential contract term, the default decision should be deny.

If the workflow truly needs sensitive data, it should move to a higher trust path with a named owner, a narrower schema, a retention rule, and a log. Do not hide that decision inside a generic prompt.

Prompt injection can shape the request

Elicitation also touches prompt injection.

OWASP LLM01: Prompt Injection describes prompt injection as inputs that alter an LLM's behavior or output in unintended ways. OWASP also calls out indirect prompt injection from external sources such as websites or files.

For elicitation, the failure mode can be subtle.

A malicious page, document, issue, or tool result may not directly steal data. It may influence the agent or server to ask the user for more data than the workflow needs.

That means the elicitation request itself needs review:

• Did untrusted content influence the requested fields?
• Did it change the label, reason, or default value?
• Did it push the user toward accept?
• Did it hide the decline or cancel path?
• Did it ask for data that belongs in the blocked set?

The safe pattern is to treat untrusted content as a reason to narrow the request, not as authority to expand it.

Elicitation can feed excessive agency

The other risk is what happens after the user accepts.

OWASP LLM06: Excessive Agency focuses on excessive functionality, permissions, and autonomy. OWASP recommends minimizing extensions, minimizing extension functionality, avoiding open-ended extensions, minimizing permissions, requiring user approval for high-impact actions, and using complete mediation.

That applies when an elicitation answer can trigger tools, writes, API calls, or decisions in another system.

The review question is not only, "Is this field safe?"

It is also, "What can the server do after the answer is accepted?"

If a server asks for a deployment environment and then can run a deployment tool, elicitation is part of the action path.

If a server asks for a customer account and then can query private records, elicitation is part of the access path.

If a server asks for a recipient and then can send an external message, elicitation is part of the communication path.

Treat the accepted answer as input to the whole workflow, not as an isolated form field.

The elicitation review record

Before enabling elicitation for an MCP server, write this down:

Requesting MCP server:
Workflow using elicitation:
Why the server needs user input:
Requested schema fields:
Sensitive field classes checked:
Untrusted content involved:
Who can see the response:
Where the response is sent:
Can the answer trigger tools or writes:
Default decision if unclear:
Rate limit or retry rule:
Log location:
Owner:
Review date:

This is small on purpose.

If a team cannot fill it out, it probably cannot explain the data boundary.

Deny or narrow these requests

An elicitation request should be denied or narrowed when:

• The requesting server is unclear
• The reason for the data request is vague
• The schema asks for credentials, personal data, legal material, health data, financial data, or confidential business data
• The fields were influenced by untrusted content
• The labels or defaults push the user toward sharing more than needed
• The response goes to a server or tool path the user cannot inspect
• Accepting the response can trigger a high-impact action without a separate approval gate
• The server can repeat the request without a quota, rate limit, or log
• The implementation collapses decline and cancel into the same path as accept

The key is not to block every interactive workflow.

The key is to stop elicitation from becoming a quiet way around data minimization.

Evidence versus opinion

Evidence from the sources:

• The MCP elicitation specification defines server-initiated user input requests through the client with structured schemas.
• The MCP elicitation specification says servers must not use elicitation to request sensitive information.
• The MCP elicitation source evidence points to clear requester presentation, response review, approval controls, rate limiting, and accept, decline, or cancel responses.
• MCP security best practices support per-client consent records as a useful analogy for elicitation consent records.
• OWASP LLM01 frames prompt injection as inputs that alter LLM behavior or output, including indirect injection from external sources.
• OWASP LLM02 defines sensitive information categories and recommends sanitization, input validation, access control, tokenization, redaction, retention clarity, and data minimization.
• OWASP LLM06 frames excessive agency as too much functionality, permission, or autonomy and recommends least privilege, human approval, and complete mediation.

My opinion:

Elicitation should be reviewed like a permissioned data request, not a generic chat clarification. The safest default is a narrow schema, visible requester, sensitive-field denylist, meaningful decline path, retry limit, and decision log.

If the request cannot be shown, constrained, denied, rate-limited, and audited, do not enable elicitation for sensitive workflows.

Free next step

Test one MCP server you use. Look for elicitation support, then fill out the review record above. If accepted answers can trigger tools or writes, compare the path against the MCP permission review, the MCP sampling approval gate, and the AI approval gate checklist before you turn it on.