A sampling request is the structured message a server sends through an MCP client when it needs model help to continue a task. It can include messages, system instructions, model preferences, context scope, and generation settings, giving teams a consistent way to shape AI behaviour.
Expanded Definition
A sampling request is a coordination message used in Model Context Protocol workflows when a server asks an AI model for help to continue an in-flight task. Its purpose is not to define the model itself, but to shape the next model interaction through structured inputs such as role messages, instructions, context boundaries, and generation preferences.
The boundary that matters is control, not capability. A sampling request can influence tone, scope, and output format, but it does not make the server the model provider or the client the policy engine. In practice, the term is often confused with general prompt submission; the distinction is that sampling is a protocol-level handoff embedded in a broader tool-and-context exchange. That makes the request part of a governed interaction path, not just an application prompt string.
For readers tracking identity and trust boundaries, the important point is that the request carries delegated intent across components. The security question is whether the server is allowed to shape model behaviour in that moment, and under what guardrails. For machine-context workflows, the most relevant external reference is the OWASP Non-Human Identity Top 10, because sampling requests often sit beside machine-to-machine trust and authorization decisions.
Examples and Use Cases
Sampling requests appear wherever an MCP server needs the model to complete a step before the workflow can proceed. They are most visible in agentic systems, automation layers, and orchestration services that combine tool access with generated reasoning or drafting.
- A support workflow asks the model to summarise a ticket thread before the server selects the next automation action.
- An internal agent requests a constrained rewrite of a document, with generation settings tuned for brevity and consistency.
- A workflow server sends only a narrow context window so the model responds to the current task instead of older, irrelevant state.
- An approval flow uses a sampling request to produce a recommendation, while the surrounding application retains final decision authority.
- A developer tool asks the model to explain an execution error so the server can route the user to the right recovery step.
The trade-off is usually between usefulness and control. Wider context and stronger instruction shaping can improve output quality, but they also increase the chance that irrelevant or sensitive material is brought into the model interaction. A well-designed sampling request therefore needs to reflect the minimum context required for the task, not the maximum context available.
Security Implications
Mismanaging a sampling request can turn a routine model interaction into a trust and exposure problem. If servers can inject overly broad instructions, they may steer the model in ways that bypass intended policy boundaries or confuse the user about who is directing the response. If context scope is too large, the request can expose secrets, customer data, or internal reasoning that was never needed for the task.
Operationally, the failure mode is often quiet. Teams may see plausible outputs while missing that the request included excessive context, stale instructions, or conflicting generation settings. That creates governance gaps: the model appears to be following policy, but the actual request path may be carrying hidden influence from a less-trusted component. In workflow-heavy environments, this can also produce inconsistent results across otherwise similar tasks.
The practical symptom is a mismatch between expected and observed model behaviour. If the same task produces different outputs depending on which server issued the sampling request, the issue may be request composition, not model quality. That is why request structure and provenance matter as much as prompt content.
Domain and Governance Relevance
Sampling requests matter most in MCP-based agentic and automation environments because they formalise how a non-human component delegates work to a model. That makes them a governance object, not just a transport detail. Organisations need to know which server can issue the request, what it may ask the model to do, and what information it may include in the exchange.
In NHI terms, the relevance is indirect but real. A sampling request often sits inside a broader machine-identity chain where a service, agent, or integration is already authenticated and authorised. The request then becomes one expression of that authority, so the question is whether the delegation is scoped, attributable, and reviewable. When that is missing, model usage can become an extension of unchecked machine access rather than a controlled workflow.
For NHIMG’s identity security lens, the main governance concern is delegated execution authority. Sampling requests should be treated as part of the control surface that determines how autonomous systems influence downstream decisions, especially where human review is limited or absent.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack surface, NIST CSF 2.0 and CIS Controls v8 set the technical controls, and ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Non-Human Identity Inventory and Ownership | Sampling requests ride on machine-to-machine authority and should be attributable to a managed non-human identity. |
| NHI-02 — Secrets and Credential Management | Request composition often depends on credentials, tokens, or delegated trust used by the calling server. | |
| Recommendation — Assign ownership to every server that can issue sampling requests and restrict that authority to approved identities. Protect the credentials that authorize sampling flows and rotate them when the calling service changes. | ||
| OWASP Agentic AI Top 10 | A1 — Agent Identity and Access | Sampling requests are a form of agentic delegation and need explicit access boundaries. |
| Recommendation — Constrain which agents can initiate sampling and scope their access to the minimum task context. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | The server's ability to influence model behaviour depends on authorization boundaries. |
| Recommendation — Enforce least privilege so only approved services can shape model requests and supplied context. | ||
| CIS Controls v8 | 6 — Access Control Management | Sampling requests should be limited by access governance for the systems that initiate them. |
| Recommendation — Review and remove unneeded request paths so only approved services can invoke sampling interactions. | ||
| ISO/IEC 42001:2023 | 6.1 — Actions to Address Risks and Opportunities | Organisations need governance for how AI request shaping is authorised and supervised. |
| Recommendation — Treat sampling request design as a governed AI risk decision and define who approves its scope. | ||
Related resources from NHI Mgmt Group
- What is the difference between network trust and request-level identity trust?
- Why do access-request workflows matter for NHI governance?
- How should organisations use AI in access request approval without weakening control?
- What is the difference between access request automation and access governance?
