URL-mode elicitation shows MCP needs out-of-band trust boundaries

At a glance

What this is: URL-mode elicitation extends MCP with a standard way to move sensitive user steps outside the client and keep them out of model context.

Why it matters: It matters because IAM, NHI, and autonomous workflow teams need to separate trusted authentication and payment steps from in-band assistant interactions before sensitive data becomes part of the session.

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.

👉 Read WorkOS's explanation of URL-mode elicitation in MCP

Context

MCP URL-mode elicitation is a trust-boundary problem, not just a UX feature. The protocol is trying to keep OAuth authorization, credential entry, and payment setup out of the MCP client so sensitive data never enters model context or a reusable session artifact.

For IAM and NHI teams, the key question is where a workflow stops being a safe in-band exchange and becomes an external identity event. That distinction matters for human login flows, service authorization, and any workflow where an autonomous system might trigger access to third-party systems.

The core governance gap is that structured elicitation assumes the server can safely collect and validate input inside the session. That assumption fails once the interaction depends on a trusted external surface that the client should not observe or mediate.

Key questions

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. The client should only guide the user to that location and return a completion signal. That preserves the trust boundary and keeps sensitive data out of model context.

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. Use form-mode only for bounded, structured input that can be validated safely inside the session. The deciding factor is whether the data or action belongs outside the MCP client.

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. That can expose tokens, credentials, or payment data to the session context and create false confidence that a client acceptance equals successful authorization. The result is a weaker trust model and harder incident investigation.

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.

Technical breakdown

Form-mode elicitation versus URL-mode elicitation

Form-mode elicitation keeps the interaction inside the MCP client and returns structured JSON to the server. That is suitable for bounded inputs such as choices, short text, or configuration values. URL-mode elicitation changes the control plane: the server asks the client to redirect the user to an external system, and the client returns only completion status. This is not just a different UI path. It is a protocol decision about where trust, validation, and sensitive data handling belong. The server must treat the external flow as out of band and verify the result independently.

Practical implication: map each elicitation step to the correct trust boundary and refuse in-band collection for sensitive authentication or payment data.

Capability negotiation and required URL-mode steps

The client must explicitly advertise URL support during initialization before a server can rely on it. That capability check prevents silent failure and forces the server to choose between fallback form mode or a hard error. When URL-mode elicitation is marked required, the workflow becomes blocking: the server cannot continue until the external step completes or the client reports failure. This is important because the protocol is expressing an execution dependency, not a suggestion. The server therefore needs state tracking, completion verification, and error handling that are independent of the client session.

Practical implication: enforce explicit capability negotiation and treat required URL steps as blocking controls, not optional prompts.

Completion tracking outside the client session

URL-mode completion is validated by the server through its own callback or state mechanism, such as an OAuth state value or an elicitation identifier. The client’s acceptance only means the redirect was initiated, not that the user completed the external step or granted access. That distinction matters because it prevents the client from becoming a source of false assurance. In practice, the server must own the lifecycle of the external event, including cancellation, timeout, retry, and final success verification. The protocol is separating navigation from authorization.

Practical implication: instrument server-side state tracking so completion, cancellation, and authorization outcomes are validated independently of the MCP client.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

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

NHI Mgmt Group analysis

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.

Dynamic trust for MCP workflows depends on separating session control from identity proofing. Structured elicitation assumes the server can safely validate user input inside the session, but authorization flows do not work that way. When the external system, not the MCP client, is the trust anchor, governance has to follow the redirect path, the callback state, and the completion signal. The implication is that session management and authorization assurance can no longer be collapsed into one control plane.

Out-of-band interaction creates an identity blind spot unless the server owns completion evidence. The client’s acceptance only proves navigation, not user consent, granted access, or successful authentication. That breaks the assumption that user interaction and security outcome are the same event. The practical consequence is that identity teams must demand server-side proof of completion for any workflow that leaves the MCP session.

MCP server permissions are only as safe as the external surfaces they delegate to. URL-mode elicitation expands the protocol into third-party authentication and payment systems, which means the real risk sits at the boundary between the assistant and the external identity provider. That shifts the governance problem from prompt handling to delegated access assurance. Practitioners should read this as a sign that MCP controls now need explicit external-flow governance, not just better client UX.

From our research:

• 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.
• That visibility gap is why OWASP Agentic Applications Top 10 is a useful next read for teams mapping assistant workflows to identity controls.

What this signals

Out-of-band trust will become a governance requirement, not a protocol nicety. As assistants begin brokering more authentication and payment flows, IAM teams will need to classify where the identity event actually occurs. URL-mode elicitation is a preview of a broader pattern: the security boundary lives outside the chat surface, and the client should be treated as a redirect orchestrator, not a place to complete sensitive identity work.

With 53% of MCP servers exposing credentials through hard-coded values in configuration files, the protocol ecosystem is already carrying identity debt. That makes external flow governance more urgent because the surrounding implementation environment is still prone to secret leakage and weak scoping. The practical signal for programme owners is that MCP adoption should trigger an explicit review of secret handling, callback validation, and delegated authorization paths.

MCP programmes will increasingly need to align with zero trust thinking because the external step, not the client session, is where assurance is established. Teams that can distinguish navigation from verification will be better positioned to govern both human-initiated and agent-initiated workflows without collapsing sensitive actions into the assistant boundary.

For practitioners

• Classify every elicitation step by trust boundary Document which MCP interactions can stay in-band and which must move to an external URL. Reserve URL-mode for OAuth, credential entry, and payment setup, and prohibit sensitive data from flowing through the client or model context.
• Make completion a server-owned event Track external flows with server-side state such as an elicitation identifier or OAuth state parameter. Do not infer success from client acceptance, because the client only confirms that navigation started.
• Fail closed when URL support is absent Require clients to advertise URL capability during initialization. If they do not, stop the workflow or fall back only where the interaction is genuinely safe to complete as structured input.
• Review MCP integrations for sensitive-data leakage paths Inventory every place where a user could be asked for a token, password, payment detail, or private authorization inside an assistant workflow. Move those steps to trusted external surfaces before the data reaches model context.

Key takeaways

• URL-mode elicitation turns MCP into a protocol that can respect trust boundaries instead of forcing every interaction into the client session.
• The security value comes from server-side completion validation, because client acceptance does not mean authorization or sensitive action success.
• Teams should separate in-band configuration prompts from external identity events, or they will keep pushing sensitive data into places it should never reach.

Key terms

• URL-mode elicitation: A protocol pattern where the MCP server asks the client to send the user to an external URL to finish a step that should not happen inside the session. It is used when the interaction needs a trusted surface, and the server must validate completion independently.
• Trust boundary: The point at which one system stops being allowed to assume integrity, confidentiality, or outcome visibility from another system. In MCP, the boundary moves outside the client when the user is redirected to an external identity or payment system, so the server must own verification.
• Out-of-band completion: A workflow outcome that is confirmed outside the original session rather than from the client’s immediate response. For MCP URL-mode flows, the server checks its own callback or state before treating the action as finished, which prevents false assurance from client-side acceptance.

Deepen your knowledge

MCP trust boundaries and out-of-band authorization are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is starting to govern assistant-driven workflows, it is worth exploring.

This post draws on content published by WorkOS: Understanding URL-mode elicitation in MCP. Read the original.