Keep the user's secrets out of the agent's context

When you need a password, an API key, a card number or a third-party authorization from the user, send them to a page you host to enter it there, so the secret never passes through the model, the agent's client or its logs.

Why

Anything an agent is told ends up in its context, and context is copied into transcripts, logs, traces and sometimes training pipelines. A secret that travels that path is no longer a secret, and OWASP names the result in its MCP Top 10 (MCP01): the model or protocol layer becomes an unintentional secret repository. Its mitigations start with keeping sensitive data out of model memory and context windows. MCP turns this into a rule for servers. Form-mode elicitation, where the client renders a form and returns the answers, is fine for choices and plain values (see AX-SYS-25), but servers MUST NOT use it for passwords, API keys, access tokens or payment credentials, and MUST use URL mode instead. In URL mode the server hands the client a link to a secure page it hosts; the user enters the secret there, the server stores it bound to that user's identity, and later calls use it without anyone repeating it. The specification states the outcome: sensitive credentials never pass through the LLM context, the MCP client or any intermediate MCP server. The same pattern covers a third-party OAuth grant or a payment step. URL mode is not how the client authenticates to your server; that remains your normal authorization flow.

Do

Collect secrets and third-party grants on a page you host, and keep them server-side, bound to the user.

Don't

Ask the agent to pass along a password, key or card number, or echo a secret back in a tool result.

Artifact

{
  "resultType": "input_required",
  "inputRequests": {
    "api_key": {
      "method": "elicitation/create",
      "params": {
        "mode": "url",
        "url": "https://mcp.example.com/ui/set_api_key",
        "message": "Please provide your API key to continue."
      }
    }
  },
  "requestState": "AEAD-protected blob"
}

The client answers {"action": "accept"} once the user agrees to open the page; that is consent, not completion. It retries with the same requestState, and the server checks whether the key has arrived before continuing.