AI
Sensitive Data Belongs Outside the Chat
Pasting a credit card number into ChatGPT is a bad idea. The LLM could memorize it, use it later, or leak it into training data. The user wants to give the card directly to a trusted processor like Stripe or PayPal. The MCP server should not ask the client to collect the card either. The solution is a URL sent directly from server to client, not through the LLM. That URL opens a browser where the user enters data into a trusted site. The server gets a confirmation without ever seeing the card.
URL Elicitation in Action
Barbettini ran a demo using the MCP TypeScript SDK. A client called a “payment confirm” tool on the server. The server responded with a URL instead of a result. The client asked for consent to open the link. After the user clicked, a browser page appeared to confirm payment. Once the user clicked confirm, the server notified the client that the elicitation succeeded. The client never saw the payment details, and the LLM never touched them.
Two Trust Boundaries, Not One
MCP servers often need to call external APIs like Google or Figma. Those APIs use OAuth. The MCP spec also uses OAuth between client and server. Reusing the same token across both boundaries is forbidden. The MCP server is not a thin proxy. It has its own scopes and audience. Sending the user’s API key through chat is also dangerous. The GitHub proposal for this feature generated over 400 comments debating the right approach.
Browser-Based OAuth Without Exposing Credentials
URL elicitation solves the OAuth problem by sending the user into their browser. The browser already has cookies and SSO. The user authenticates with the external service directly. The external service calls back to the MCP server with a token. The token never passes through the LLM or the client. The client only ever holds one token, scoped to the MCP server. This preserves correct trust boundaries and keeps sensitive credentials out of insecure contexts.
Q&A
Can URL elicitation handle step-up authorization for temporary read-to-write elevation? Yes, it provides a foundation, but fine-grained authorization work in the next MCP release will add explicit support. ▶ Watch (19:11)
Does teaching users to click URLs from their agent increase phishing risk? The problem is not the URL itself but verifying the server’s identity, which requires a trusted registry, similar to how HTTPS lock icons no longer prevent phishing. ▶ Watch (20:42)
Why is client adoption taking so long despite the feature being available since November? Ecosystem support is patchy; the conformance test suite does not yet include URL elicitation, and adding it to SDKs like Go and C# requires more contributor effort. ▶ Watch (25:55)
Notable Quotes
some interactions are too sensitive to be chat messages Nate Barbettini · ▶ Watch (1:19)
This is not a chat message. It’s not part of the conversation history. Nate Barbettini · ▶ Watch (3:27)
the MCP server itself is not a magical tunnel Nate Barbettini · ▶ Watch (12:33)
Key Takeaways
- URL elicitation keeps sensitive data (credit card numbers, OAuth tokens) out of the LLM and the client.
- It solves the two-trust-boundary problem for MCP servers calling external APIs without token reuse.
- Available since the November MCP release; VS Code, Cursor, and Cloud Code already support it.
About the Speaker(s)
Nate Barbettini is a leading voice in security and AI. At Arcade.dev, he’s building the MCP runtime that helps enterprises deploy multi-user AI agents that take actions across any system. As an active MCP contributor, Nate is focused on security-critical work, authoring URL Elicitation.