Notifications
Clear all
Topic starter
07/06/2026 8:27 pm
TL;DR: URL-mode elicitation gives MCP servers a protocol-native way to move OAuth, credential entry, and payments outside the client, keeping sensitive data out of model context while preserving workflow continuity, according to WorkOS. The key issue is trust boundary design: in-band elicitation works for structured input, but it breaks down when the interaction itself must be trusted and externally validated.
NHIMG editorial — based on content published by WorkOS: Understanding URL-mode elicitation in MCP
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: How should security teams handle sensitive authentication steps in MCP workflows?
A: Security teams should move any authentication step that involves tokens, passwords, or payment details out of the MCP client and into a trusted external surface.
Q: When should organisations use URL-mode instead of form-mode elicitation?
A: Use URL-mode when the interaction must happen in a trusted third-party surface, such as OAuth authorization or PCI-scoped payment entry.
Q: What breaks when sensitive user actions stay inside the MCP client?
A: Sensitive actions inside the client blur the boundary between prompt handling and identity assurance.
Practitioner guidance
- Classify every elicitation step by trust boundary Document which MCP interactions can stay in-band and which must move to an external URL.
- Make completion a server-owned event Track external flows with server-side state such as an elicitation identifier or OAuth state parameter.
- Fail closed when URL support is absent Require clients to advertise URL capability during initialization.
What's in the full article
WorkOS's full article covers the protocol mechanics this post intentionally leaves at the governance level:
- The exact JSON-RPC request and response fields for URL-mode elicitation.
- How server-side completion tracking works with OAuth state and elicitation IDs.
- The operational difference between required and optional URL-mode steps.
- The implementation guardrails for cancellation, timeouts, and secure redirection.
👉 Read WorkOS's explanation of URL-mode elicitation in MCP →
URL-mode elicitation in MCP: are your controls keeping up?
Explore further
07/06/2026 10:22 pm
URL-mode elicitation is a trust-boundary control, not an input format. The article makes clear that OAuth, credentials, and payments cannot safely be treated as ordinary in-band prompts. That matters because the security question is not how to collect more data, but where the interaction is allowed to occur. Practitioners should treat the client-to-external-URL handoff as a deliberate control boundary, not a convenience feature.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable when an external URL-based elicitation step fails or is bypassed?
A: The server remains accountable because it owns the workflow, the completion state, and the validation logic. The client can only present the redirect and report acceptance, decline, or cancellation. Frameworks such as zero trust and identity governance both depend on that server-side ownership of outcomes.
👉 Read our full editorial: URL-mode elicitation shows MCP needs out-of-band trust boundaries
