MCP elicitation security

An MCP server can request user input, but the client must preserve who is asking and what the answer authorizes.

01 / The operating case

What changes in a real workflow?

A third-party server elicits a password in a dialog styled like an enterprise SSO prompt.

Trace the authority boundary
  1. 01Client / task
  2. 02MCP server
  3. 03Tool call + arguments
  4. 04Downstream effect

02 / Decision contract

What the executor must check

Display server origin and purpose, avoid collecting secrets through untrusted form flows, and use a dedicated authorization redirect when credentials are required.

InputPrincipal · task · action · target
DecisionGrant ancestry · policy · current state
ResultEnforce · record · verify outcome

03 / Failure and evidence

What goes wrong, and what can be proven?

Failure mode

The user mistakes a server-authored prompt for a first-party approval and discloses credentials.

Evidence to retain

Log elicitation origin, mode, destination and user response status without retaining the secret.

04 / Canonical scope

Why this reference stands alone

Human approval owns consent to an effect; elicitation can ask for information and must not be equated with approval.

Protocol or attack trace

Elicitation origin test

Sequence

Third-party server presents a form that imitates enterprise SSO and asks for a password.

Negative test

Client shows server origin and rejects secret collection in an untrusted form; redirect to appropriate authorization flow.

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation