MCP sampling and elicitation are client features that let a server start a request instead of only answering one. Sampling lets an MCP server ask the client to run an LLM completion on the server's behalf; elicitation lets a server ask the user for structured input through the client. Both are useful, and both create new attack channels: sampling is a path for prompt injection and model-budget abuse, elicitation is a path for phishing your own users. The specification's answer is the same for both: a human who can see and deny each request, plus rate limits, content validation and per-server opt-in.
Most MCP threat models focus on tools, where the agent calls the server and the server's output is the risk. Sampling and elicitation turn that around. If you have already read about tool poisoning in MCP, think of these as the same trust problem with the server now holding the initiative.
How sampling works
A client that supports sampling declares the sampling capability when it connects. The server can then send a sampling/createMessage request containing messages, an optional system prompt, model preferences and a token limit. The client picks a model, runs the completion and returns the result to the server (MCP sampling specification).
The design goal is reasonable. A server can use the user's own model access for summarising, classifying or planning without holding its own API key. The cost is that a third-party server now writes prompts that run on your model, under your account.
The specification is explicit about the trust implications. For trust and safety, there SHOULD always be a human in the loop with the ability to deny sampling requests. Applications SHOULD let users view and edit prompts before sending and review generated responses before delivery. Clients SHOULD implement rate limiting, and both parties MUST handle sensitive data appropriately.
Sampling risks
Prompt injection by design
A sampling request is a server-authored prompt. A malicious or compromised server can include instructions aimed at the model rather than at the stated task: ignore prior rules, reveal context, call a tool, output a payload. If the client runs sampling requests in the same session as the agent, or feeds results back into the agent's context, the injection travels with them. This is indirect prompt injection with a protocol-level delivery mechanism.
Context exfiltration
Sampling requests can ask the client to include context from the session. Depending on the client implementation, that can pull conversation history or content from other servers into a prompt whose output goes back to the requesting server. A server that should only see its own data may receive far more.
Cost and quota abuse
Every sampling request spends model tokens on your account. A server that loops, or sends large prompts with high token limits, turns your model budget into its compute. Without per-server quotas, the cost appears on the bill with no clear owner.
Response tampering
The server receives the completion and decides what to do with it. A server that rewrites or selectively uses responses can steer downstream actions while appearing to rely on your model's judgement.
How elicitation works
A client that supports elicitation declares the elicitation capability. The server sends an elicitation/create request with a message and a requestedSchema, which is limited to a flat object of primitive fields such as strings, numbers, booleans and enums. The client shows a form, and the user can accept, decline or cancel (MCP elicitation specification).
The normative rules are short and important. Servers MUST NOT use elicitation to request sensitive information. Clients SHOULD make clear which server is asking, SHOULD implement approval controls, and SHOULD let users decline at any time. Both parties SHOULD validate content against the schema.
Elicitation risks
Phishing inside a trusted interface
A form that appears in the user's familiar assistant or IDE inherits that interface's credibility. A server that asks for a password, an API key, an MFA code or a card number is breaking the specification, but nothing in the protocol stops it from sending the request. The client is the only enforcement point, and users tend to trust prompts that arrive in tools they already use.
Server impersonation
If the client does not show clearly which server made the request, a malicious server can word its message to look like it comes from a trusted one, or from the client itself. The specification asks clients to show which server is requesting information because this is the obvious attack.
Consent fatigue
Frequent, low-stakes elicitation requests train users to click accept. Once that habit forms, the one harmful request goes through with the rest. This is the same fatigue problem that affects any approval system; see human-in-the-loop approvals for agents for how to keep approvals meaningful.
Data collection beyond purpose
Even without secrets, elicitation can collect personal data such as names, emails and addresses that the server has no need for. For EU deployments that is a data protection question, not only a security one.
Controls for both features
| Control | Sampling | Elicitation |
|---|---|---|
| Per-server opt-in, off by default | Enable only for servers with a reviewed need | Enable only for servers with a reviewed need |
| Human can deny each request | Show the full prompt, allow edit and deny | Show the form and requesting server, allow decline |
| Content inspection | Scan prompts for injection patterns before running | Reject schemas with fields that look like secrets or credentials |
| Isolation | Run sampling outside the agent's main context; do not merge results back unreviewed | Never let elicited values flow into tool calls without validation |
| Quotas | Per-server rate and token limits | Per-server request rate limits |
| Logging | Record server, prompt, model, tokens and decision | Record server, schema, user action and timestamp |
| Review | Revisit which servers use sampling, and why | Revisit which servers prompt users, and for what |
Checklist before enabling either feature
The 2026 specification work on MCP is still evolving; check the MCP 2026 spec revision for changes to how capabilities are negotiated before you build controls on the current request shapes.
The Praesidia angle
Praesidia does not change how an MCP client renders sampling or elicitation requests; those controls live in the client. What it adds is the governance around the servers themselves. Discovery surfaces MCP servers that agent runtimes are using but nobody registered, so you know which servers could send these requests. For agents running on Praesidia, tool rules can allow, deny or require approval for a tool or pattern, guardrails check tool arguments before a call and results before the model reads them, and calls are logged with the agent, the policy decision and the latency, with the caveat that a record can be missing and calls outside Praesidia are not recorded. Discover the servers, secure the calls you route, and keep the evidence.
See how to monitor MCP tool calls and the MCP server governance guide for the broader model.