URL Elicitation: Keep Passwords and Payments Out of the Chat
Some steps should never travel through an agent conversation. How URL-mode elicitation hands the user off to a trusted page for payments, credentials, and consent — and brings the workflow back cleanly.

There is a category of step that should never pass through a model’s context: typing a password, approving a card charge, completing a third-party OAuth grant, sharing a private key. Not because the model is untrustworthy in some abstract sense, but because that data would then exist in transcripts, in traces, in whatever logging you turned on last quarter and forgot about.
URL-mode elicitation gives the server a clean way out: send the person to a trusted page you control, let that page own the sensitive interaction, and resume the workflow from a result.
Separate assistance from authority
Draw the line by asking who needs to be trusted with what. The agent is good at explaining why a step is required, what happens next, and what the user should expect to see. The out-of-band page owns authentication, consent capture, validation, and submission — the parts with legal and financial weight.
What comes back to the agent should be the minimum needed to continue. Payment authorized. Account linked. Consent recorded. Not the card, not the token, not the answers.
- Show the destination and the purpose before the user is asked to open anything
- Use a unique, short-lived correlation identifier for each request
- Never put credentials, payment details, or authorization codes into the conversation
- Bind the callback to the initiating user, session, and exact request — all three
- Expire abandoned requests and make retry behavior explicit rather than implicit
Design the return path, not just the exit
Teams build the handoff and forget the round trip. The result is a user sitting on a confirmation page in a second tab with no idea whether the first tab knows what happened. Tell them when they can close the external page. Show the agent’s state updating. Handle cancellation and expiry as normal outcomes with a clear next step â not as a silent stall the user has to guess about.
Phishing resistance is a design requirement
You are training users to click a link an AI handed them. Take that seriously. Show the actual domain before the click, keep the destination on a domain the user already associates with your product, and make the pattern consistent enough that an unusual one looks wrong. An agent that sometimes sends people to unfamiliar domains has taught them a habit an attacker can use.
Use it sparingly
Every handoff breaks the flow and costs completion. Reserve elicitation for the moments where a direct user interaction meaningfully improves security, consent, or compliance. Ordinary low-risk inputs — a date, a preference, a confirmation — belong inside the main experience where they cost nothing.
Primary sources
First-party documentation and announcements used to ground this field note.