Model Context Protocol Elicitation is a specification-defined capability that lets an MCP server request additional structured information from a user mid-session through the client, using an elicitation/create request and, optionally, a JSON schema describing the requested fields. Because elicitation can occur at any point during an already-established session rather than only at connection setup, it operates outside the initial trust negotiation most tool-call governance is built around. This creates specific risks, including consent fatigue, expanded data exposure, and misattributed consent, that require per-request runtime enforcement rather than reliance on session-level approval alone.
Model Context Protocol Elicitation: Security Implications for Enterprise AI Agents
Elicitation lets an MCP server request structured information from a user mid-session, outside the trust negotiation that typically governs tool calls. This guide explains how the mechanism works, why it introduces a distinct governance gap, and how security teams can enforce policy on it at runtime.
MCP Elicitation at a Glance
Four characteristics define elicitation's risk profile and distinguish it from the tool-call interface security teams typically monitor most closely.
Server-Initiated
Elicitation requests originate from the MCP server and can occur at any point during an active session, not only at connection setup.
Schema-Based
Requests may include a JSON schema describing the structure of the information being solicited from the user.
Consent-Gated
The specification requires explicit consent for each elicitation exchange, distinct from prior session-level authorization.
Governance Gap
Mid-session, server-initiated requests fall outside typical tool-call approval workflows, creating a distinct audit and policy category.
What Is MCP Elicitation
Elicitation is a capability defined in the Model Context Protocol specification that allows an MCP server to request additional structured information from a user during an active session, rather than only at initial connection setup. The mechanism is implemented as an elicitation/create request sent from the server to the client. The client is responsible for presenting the request to the human user and returning a structured response back to the server. Elicitation requests can include a JSON schema that defines the expected structure of the requested information, allowing servers to solicit specific fields rather than open-ended text.
This distinguishes elicitation from tool-call invocation, which is typically initiated by the host or agent orchestrating a session. Elicitation is server-initiated, which introduces a second interaction channel through which an MCP server can request input from a user, separate from the tool-calling interface that security teams typically monitor most closely.
How the Request-Response Cycle Interacts With Trust Boundaries
MCP's architecture separates hosts, clients, and servers, with the client acting as the intermediary responsible for mediating and enforcing user consent for server-initiated actions, including elicitation. In a standard tool-call flow, trust boundary enforcement happens largely at session initialization, when a client authorizes a server's declared capabilities. Elicitation operates on a different timing model: because a server can trigger an elicitation/create request at any point during an already-established session, enforcement must occur continuously, per request, rather than once at connection time.
The specification's trust and safety principles reflect this by requiring clients to obtain explicit user consent before completing an elicitation exchange, rather than relying solely on prior session-level authorization. Each elicitation prompt is meant to function as a discrete consent event. If a client implementation treats session-level approval as sufficient and does not re-verify consent per request, the mid-session elicitation channel can end up operating with less oversight than the tool-call channel it sits alongside.
Security Risks Introduced by Elicitation
Three risk categories follow directly from elicitation's design and recur across the specification's own guidance and the runtime controls needed to mitigate them:
- Consent fatigue: because elicitation can be triggered repeatedly within a single session, users may approve later requests with declining scrutiny, particularly when prompts are not clearly distinguished from one another.
- Expanded data exposure: the schema-based request format allows a server to solicit specific structured fields directly from the user, through a channel that sits outside the visibility most teams apply to tool-call monitoring.
- Misattributed consent: when an elicitation prompt does not clearly disclose the requesting server's identity, a user's approval may be recorded as consent to a request whose actual source they did not fully understand.
Why These Risks Are Architectural, Not Incidental
These risks follow directly from elicitation's mid-session, server-initiated design rather than from a specific implementation defect. The specification itself anticipates part of this exposure by stating that servers must not use elicitation to request sensitive information such as passwords or credentials, and by recommending that client UIs clearly identify the requesting server and allow users to review, modify, or decline a request before submission. These are guidance provisions, not enforced runtime constraints, which means the actual risk profile of a given deployment depends heavily on how faithfully a specific client implementation applies them.
No independently confirmed public incident report or vulnerability disclosure specific to MCP elicitation exploitation has been verified within the past 12 months. The risks described here are derived primarily from the specification's own security guidance rather than documented attacks, which does not reduce their relevance but does mean enterprise risk assessment should treat them as architectural exposure to be governed proactively, not as confirmed active threats to be remediated reactively.
Evaluation Questions for Security Teams
Security and platform teams evaluating an MCP client implementation can use the following questions to assess whether elicitation-specific risks are actually covered by existing governance processes.
- Does the client implementation disclose the requesting server's identity before displaying an elicitation prompt, as recommended by the specification?
- What runtime controls exist to block or flag elicitation requests attempting to solicit credentials or other sensitive data?
- Can policy enforcement be applied to elicitation request schemas prior to end-user presentation?
- How are elicitation request and response events logged and retained for audit purposes?
- Does the deployment include rate limiting on elicitation requests at the session level to mitigate consent fatigue?
Runtime Governance Controls for Elicitation
Because elicitation sits outside session-level trust negotiation, governance needs to act on each request individually. The following controls address the risk categories described above.
✓Schema Filtering
Apply allow/deny rules to elicitation request schemas before they reach end users, filtering for credential-like or high-sensitivity field patterns.
✓Identity Disclosure
Render the requesting server's identity and purpose in the consent UI for every elicitation prompt, not as a one-time session-level approval.
✓Request Throttling
Throttle the frequency of elicitation requests per session to reduce consent fatigue.
✓Response Validation
Validate elicitation responses against declared schemas before forwarding data back to the requesting server.
✓Dedicated Audit Logging
Capture elicitation request and response pairs in audit logs distinct from tool-call logs to support dedicated security review.
Govern MCP Elicitation at Runtime
Enterprise AI agent deployments using MCP need policy enforcement that extends to server-initiated elicitation requests, not only tool calls.
Explore MCP Security