Protect MCP Elicitation Inputs
Control the fields and URLs an MCP server may request from a user, with safe denial and phishing checks.
MCP elicitation lets a server request information from a user through the client. That can help complete a task, but it also gives a connected server a way to ask for secrets or send a user to a deceptive page. The 2026-07-28 MCP specification distinguishes form mode from URL mode. It prohibits requests for credentials through form mode and sets specific rules for URL handling.
Before enabling elicitation, list the fields each tool may request. A server should not ask for an API key in an ordinary form just because the task requires authentication. Use an approved authorization flow for credentials. The client must identify the requesting server and let the user decline or cancel.
Field and URL policy
| Request | Default decision | Review point |
|---|---|---|
| Non-sensitive project label | Allow with clear purpose | Field length and type |
| Customer record text | Hold | Scope and data handling |
| Password or one-time code | Deny in form mode | Use trusted auth path |
| External URL | Hold for user consent | Full URL and requesting server |
| New field after update | Deny until reviewed | Catalog and schema diff |
Parse the requested form schema, reject unknown or oversized fields, and bind a response to the active tool request. A later server message must not reuse an old answer. Do not let model prose replace the client's own security display.
For URL mode, show the full URL before asking for consent, not only a friendly label or domain. The client must not automatically pre-fetch the URL or its metadata. It must not open the URL until the user explicitly agrees. The server must not put credentials, personal data, or a pre-authenticated access link in the URL. Open an approved destination in a way that prevents the MCP client or model from inspecting the page contents or user input.
Verify the person and test the flow
The server must verify the identity of the person who opens the elicitation URL before it accepts information. Match that verified identity to the user who started the MCP request. Do not trust a user name typed into the page or an identity value supplied only by the client. Bind any URL request state to that user so a forwarded link cannot attach another person's authorization to the wrong session.
In an owned fixture, request one permitted label and complete the task. Then ask for a synthetic secret, a new field, and a URL with a misleading display name. Check that the full URL appears before consent and that no network prefetch or navigation occurs while consent is pending. Open a copied URL as a different test user and require denial before data is accepted. Repeat after cancellation; the old form and URL must not complete the request.
Record the requesting server, field names or URL origin, policy decision, and result without storing entered values. A refusal should leave no partial write. If the client cannot show the full destination or the server cannot verify the opener, keep URL elicitation disabled.
Know what your agents can reach
Map data access, tool actions and approval boundaries before testing. Use the scope guide, or discuss a review of your AI application.