MCP elicitation shifts runtime context into AI identity governance

At a glance

What this is: MCP elicitation is a runtime context-request mechanism for MCP servers, with the key finding that interactive context negotiation needs explicit approval, validation, and abuse controls.

Why it matters: It matters because IAM, NHI, and agent governance teams now have to decide which runtime requests are acceptable, how they are attributed, and where human approval must remain mandatory.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read WorkOS's article on MCP elicitation and runtime context requests

Context

MCP elicitation extends Model Context Protocol sessions by letting a server request missing information while execution is already underway. That changes the identity governance problem from static prompt design to runtime trust decisions, because the system now decides what context it needs after a session has started.

For IAM and NHI teams, the important shift is that context requests can now sit inside the control plane of an AI workflow instead of outside it. That creates a new boundary question: which runtime requests are legitimate, which require user approval, and which should never be asked through an MCP channel at all.

The article is typical of the current MCP wave: useful capability first, governance guardrails second. That is exactly where the operational risk sits.

Key questions

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. Define which servers may elicit input, require explicit user approval for any state-changing branch, validate every response against schema, and log the requesting server identity. If the request could expose secrets or PII, it should move to a separate secure channel rather than remain in the MCP flow.

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. That means security teams are no longer governing only the initial prompt or configuration, but also the live request path, the user’s response, and the downstream effect of that response. Without approval, attribution, and validation, the request channel becomes a trust boundary with weak visibility.

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. Once sensitive information is pulled into an interactive runtime request, the system inherits extra privacy, retention, and misuse risk. Teams should move those data exchanges to secure out-of-band flows and keep elicitation limited to non-sensitive context.

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.

Technical breakdown

How MCP elicitation works inside a live session

Elicitation is a protocol-level back-and-forth between an MCP server and client when required context is missing or ambiguous. The server sends an ElicitationRequest, the client presents the user prompt, and the response can be accepted, rejected, or canceled. This is materially different from stuffing every variable into the initial prompt, because the request happens mid-session and can branch based on runtime state. The design helps support confirmation, re-authentication, and progressive data gathering, but it also makes the client part of the trust boundary rather than a passive transport layer.

Practical implication: Map every elicitation flow to an explicit approval path before it is allowed to reach tools or downstream actions.

Schema validation and client approval as control points

The article makes clear that elicitation responses are only safe if clients validate them against the requested JSON schema and give the user a clear reject or cancel path. That matters because malformed or coerced values can corrupt session logic even when the request looks benign. The client also has to show which server made the request, especially in multi-server or multi-agent environments where attribution can blur. In practice, the client is now enforcing both data integrity and accountability, not just rendering a dialog box.

Practical implication: Require schema enforcement, server attribution, and explicit opt-out before any elicited value is accepted into the session.

Why runtime context negotiation changes MCP security

Runtime context negotiation expands what an MCP server can influence during execution, which means the control problem shifts from static configuration to live interaction management. The protocol is intended to make systems more adaptive, but every adaptive branch increases the number of states security teams must govern. The article’s security guidance is clear that sensitive information must not be requested this way, because elicitation is designed for context, not secrets. That is the core architectural boundary.

Practical implication: Treat elicitation as a governed interaction surface and block any use case that tries to move credentials or PII through it.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Only 18% of MCP server deployments implement any form of access scoping for tool permissions. That figure shows how early the ecosystem still is in constraining tool reach, even before dynamic elicitation is layered on top. Once a server can ask for missing context during execution, weak scoping becomes more consequential because the request path itself can steer subsequent behaviour. Practitioners should assume that elicitation without scoped permissions compounds the blast radius of an already immature control plane.

Runtime context negotiation creates an identity blast radius if the requesting server is not explicitly attributable. The article’s requirement that clients show which server is asking is a recognition that multi-server and multi-agent environments obscure accountability. Without clear attribution, a user may answer a request without knowing which system will consume it or how far the response will travel. Practitioners should only allow elicitation flows where server identity is visible and auditable.

Сredential and PII request paths must remain outside MCP elicitation. The spec’s own security guidance says servers must not use elicitation to request sensitive information, which is a control boundary rather than a nice-to-have. That boundary matters because runtime convenience often tempts teams to collapse authentication, consent, and context collection into one interactive flow. Practitioners should preserve separate secure channels for sensitive data and keep elicitation strictly for non-sensitive context.

Context-aware AI does not remove governance friction, it relocates it to the moment of action. Elicitation can improve adaptability, but adaptability without rate limits, schema checks, and rejection handling creates a new class of operational noise. The field will need to judge these flows by whether they are observable and bounded, not by whether they are interactive. Practitioners should align MCP governance with Zero Trust assumptions: verify every request, constrain every response, and log every branch.

From our research:

• 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.
• For a broader view of how agentic tool access changes identity controls, see OWASP Agentic Applications Top 10.

What this signals

MCP elicitation shifts the governance burden from static configuration to live interaction management. That means teams need policy for when a server may ask, what it may ask, and how the client proves the request was approved. With only 18% of MCP server deployments implementing any form of access scoping for tool permissions, the control environment is still too thin to absorb more runtime flexibility without stronger boundaries.

A practical named concept here is runtime context trust debt: the accumulation of ungoverned prompts, unscoped tool reach, and ambiguous server attribution inside live sessions. The more often a server negotiates context mid-flight, the more the programme depends on user judgment instead of enforceable controls. Teams should expect auditability, rate limiting, and separate handling for sensitive data to become baseline requirements.

For teams comparing this pattern with agentic AI guidance, the useful reference point is whether runtime requests remain observable and bounded under the same assumptions that govern tool use. The OWASP Agentic AI Top 10 is a useful companion lens when MCP sessions begin to look like delegated execution rather than simple context exchange.

For practitioners

• 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. Build the approval path into policy, not just into the client UI.
• Block sensitive data from elicitation flows Prohibit requests for PII, credentials, tokens, and other secrets through MCP elicitation. Route those needs to secure out-of-band mechanisms with separate authentication and logging.
• 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. Reject values that fail type, required-field, or format checks.
• Make the requesting server visible to the user Require the client to display which server is requesting context, especially when more than one server or agent is active in the session. Tie that identity to logs so the interaction can be audited later.
• Rate-limit repetitive elicitation requests Set thresholds for repeated or abusive context prompts so a misbehaving server cannot harass users or exhaust session trust. Escalate repeated requests into policy review and incident handling.

Key takeaways

• MCP elicitation makes runtime context negotiation a first-class control problem, which means identity governance must move closer to the moment of action.
• The article’s own security guidance is clear that elicitation must not be used for secrets or PII, and clients need approval, schema validation, attribution, and rate limiting.
• Teams should treat live context requests as a policy surface, not a prompt convenience, because the governance gap is now inside the session itself.

Key terms

• MCP Elicitation: A runtime protocol mechanism that lets an MCP server request additional context from a client during an active session. It is designed for missing or ambiguous non-sensitive information, not for secrets or personal data, and it shifts governance into the live interaction path.
• Runtime Context Negotiation: The process of resolving missing inputs after execution has already started. In AI systems, this creates a moving trust boundary because the request, the user response, and the downstream action all occur within the same session and must each be governed.
• Schema Validation: A control that checks whether an input matches the declared JSON structure, type, and required fields before it is accepted. In MCP elicitation, schema validation prevents malformed or coerced values from entering the session and corrupting later tool actions.

Deepen your knowledge

MCP elicitation, runtime approval flows, and identity-bound session controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for context-aware AI systems, it is worth exploring.

This post draws on content published by WorkOS: MCP elicitation and runtime context requests. Read the original.