MCP fixed secret handling. URL elicitation moved the phishing risk into the browser

COMMENTARY: URL mode elicitation solves a real Model Context Protocol problem: credentials should not pass through an AI client just because an agent needs to complete an OAuth flow, collect an API key, or hand a payment to a secure page.

The protocol's maintainers introduced it for exactly that reason. Instead of asking the user to type a secret into the AI interface, the MCP server directs the client to a browser flow where the sensitive interaction happens out of band. The current 2026-07-28 specification carries these interactions through Multi Round-Trip Requests, so a tool can pause, request user input, and resume when the client retries the call.

That is a security improvement. It also creates a trust hop that many enterprise controls are not watching.

The hard question for anyone responsible for agent security is no longer only whether the model can see the credential. It is whether the browser destination the agent asks the user to open was ever authorized.

A safer credential path creates a new trust decision

The client never needs to receive the third-party credential; the server handles it directly after the browser flow completes. But a trusted AI client now becomes the place where a user is told, in the middle of a legitimate workflow, "open this page to continue."

Related reading:

Users have spent years learning to distrust unexpected links in email and text messages. They have not learned the same skepticism for an authentication link presented by an enterprise-approved assistant after they asked it to do a task. Attackers will notice.

The elicitation specification is candid about this. Clients must show the full URL and obtain explicit consent before opening it, and should highlight the domain and warn on suspicious addresses such as Punycode. Servers must verify that the person who opens the link is the person the request was generated for, because a forwarded link can otherwise bind one user's third-party tokens to another user's account. The MCP security guidance separately requires clients to reject dangerous URL schemes and to avoid shell-based URL launching.

Those are necessary protocol controls. But a consent prompt is only as good as the judgment behind it, and a user shown an unfamiliar hostname has no policy to judge it against. The specification cannot answer the enterprise question: which domains should this specific MCP server be allowed to send this specific user to?

Static MCP inventory does not see the whole transaction

Security teams are inventorying MCP servers, reviewing tool descriptions, and restricting what agents can reach. That is necessary. URL elicitation adds something different: a destination that can appear only at runtime, while the tool is executing.

A server approved for one business function may legitimately need an identity provider, a payment processor, or a third-party SaaS authorization endpoint. A compromised or malicious server can use the same mechanism to present a host outside the expected set, with the credibility of the assistant behind it.

Today the controls are fragmented. An MCP registry knows which server and tool were approved. A secure web gateway sees a browser request but often cannot tell which agent or server caused it. The browser knows where the user is going but usually lacks the provenance of the agent action that led there. An identity provider sees an authorization attempt without the original request. Each sees one piece, which makes incident reconstruction harder than it should be.

Treat elicitation destinations as capabilities

An elicitation destination is a requested capability, not presentation data. Three controls follow.

Give each approved server a destination policy. Record the identity providers, SaaS domains, and payment processors it may invoke, and enforce that list at the client or MCP gateway before the consent prompt appears. A host outside the set should be rejected or escalated, never merely displayed.

Re-approve on change. A new destination is a new capability. Treat it like a new tool or a widened OAuth scope, with review before users see it.

Preserve the causal chain. Log the sequence below with a shared correlation identifier, so a responder can join client, gateway, proxy, and identity provider records after a malicious session:

user request → agent → MCP server → tool → elicitation request → destination host → user approval → browser navigation

Moving secrets out of the model context is the right design decision. It removes one of the most obvious ways credentials leak through an agent.

But removing the secret from the prompt does not remove the trust problem. It moves the point where trust has to be enforced.

For URL elicitation, that point is now the browser.