Notifications
Clear all
Topic starter
08/06/2026 5:05 pm
TL;DR: MCP elicitation adds a standard way for servers to request missing context during a live session, but the article also says it must not be used for sensitive information and clients need approval, schema validation, clear server identity, and rate limiting, according to WorkOS. The governance issue is no longer whether models can ask more questions, but which runtime trust assumptions remain safe when context negotiation becomes part of execution.
NHIMG editorial — based on content published by WorkOS: MCP elicitation and runtime context requests
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: How should security teams govern runtime context requests in MCP sessions?
A: Treat runtime context requests as a controlled identity interaction, not a convenience feature.
Q: Why do runtime context requests create new governance risk for AI systems?
A: They create risk because the system can change its behaviour after execution has already started.
Q: What breaks when MCP elicitation is used for sensitive information?
A: The trust model breaks because elicitation is designed for contextual input, not for credentials, tokens, or personal data.
Practitioner guidance
- Classify elicitation as a governed runtime control Document each MCP server prompt that can appear after session start, then define whether it is informational, approval-based, or prohibited.
- Block sensitive data from elicitation flows Prohibit requests for PII, credentials, tokens, and other secrets through MCP elicitation.
- Enforce schema validation on every response Validate every elicited value against the declared JSON schema before it is used in a tool call or state transition.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- The exact ElicitationRequest and response schemas used in MCP sessions
- Concrete request and cancellation examples for timezone, locale, and other context values
- The specification's recommended client behaviours for reject, cancel, and approval handling
- The updated URL-mode elicitation note for interactions that cannot safely happen inside the MCP client
👉 Read WorkOS's article on MCP elicitation and runtime context requests →
MCP elicitation and runtime context: are your controls ready?
Explore further
08/06/2026 7:04 pm
MCP elicitation turns runtime context into an identity governance decision, not just a UX feature. The article describes a standardized way for servers to ask for more information mid-session, which means the security boundary now moves with execution. That matters because the request is no longer a static input problem but a live trust decision about who can ask, what they can ask for, and how the response is handled. Practitioners should treat this as a governance surface that sits inside the AI workflow.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
- Only 53% of MCP servers expose credentials through hard-coded values in configuration files, according to Astrix Security research on MCP server security.
A question worth separating out:
Q: How do teams know if MCP elicitation is being overused?
A: Watch for repeated prompts, excessive user rejections, and requests that keep appearing for the same missing context. Those signals suggest the server is compensating for poor design or weak state management. A healthy implementation should request only what is needed, once, and should degrade gracefully when users cancel or refuse.
👉 Read our full editorial: MCP elicitation shifts runtime context into AI identity governance
