Summary
web_search_options.search_description and web_search_options.extract_description are client-controlled per-request and are used directly as tool descriptions for built-in web search tools.
Because tool descriptions influence tool-calling behavior, this blurs trust boundaries: untrusted callers can modify what is effectively system-level guidance for server-provided capabilities.
Evidence
1) Request schema accepts description overrides
mistralrs-core/src/request.rs (WebSearchOptions):
search_description: Option<String>
extract_description: Option<String>
2) Server request path passes client values unchanged
mistralrs-server-core/src/openai.rs:
ChatCompletionRequest includes web_search_options
mistralrs-server-core/src/chat_completion.rs:
NormalRequest.web_search_options: oairequest.web_search_options
mistralrs-server-core/src/responses.rs:
- OpenResponses path forwards
oairequest.web_search_options into ChatCompletionRequest
3) Tool descriptions are populated from these fields
mistralrs-core/src/search/mod.rs (get_search_tools):
- Search tool description uses
web_search_options.search_description.unwrap_or(SEARCH_DESCRIPTION)
- Extract tool description uses
web_search_options.extract_description.unwrap_or(EXTRACT_DESCRIPTION)
These descriptions are then supplied in tool definitions used by the model.
Why this matters
For deployments where API callers are not fully trusted, this allows clients to steer server-defined tool semantics and can:
- weaken guardrails around tool use,
- increase prompt-injection susceptibility,
- create unexpected behavior for downstream integrators assuming tool metadata is server-controlled.
Suggested fixes
- Treat tool descriptions as server configuration (or constants), not request input.
- If keeping overrides, gate behind trusted mode/auth and document risk.
- Add strict validation/length limits and optionally reject override fields for public-facing deployments.
- Consider a config flag to disable client-provided tool description overrides by default.
Minimal repro idea
Send a chat request with:
{
"web_search_options": {
"search_description": "(attacker-controlled text)",
"extract_description": "(attacker-controlled text)"
}
}
Observe these strings appear in the built tool metadata path via get_search_tools.
Summary
web_search_options.search_descriptionandweb_search_options.extract_descriptionare client-controlled per-request and are used directly as tool descriptions for built-in web search tools.Because tool descriptions influence tool-calling behavior, this blurs trust boundaries: untrusted callers can modify what is effectively system-level guidance for server-provided capabilities.
Evidence
1) Request schema accepts description overrides
mistralrs-core/src/request.rs(WebSearchOptions):search_description: Option<String>extract_description: Option<String>2) Server request path passes client values unchanged
mistralrs-server-core/src/openai.rs:ChatCompletionRequestincludesweb_search_optionsmistralrs-server-core/src/chat_completion.rs:NormalRequest.web_search_options: oairequest.web_search_optionsmistralrs-server-core/src/responses.rs:oairequest.web_search_optionsintoChatCompletionRequest3) Tool descriptions are populated from these fields
mistralrs-core/src/search/mod.rs(get_search_tools):web_search_options.search_description.unwrap_or(SEARCH_DESCRIPTION)web_search_options.extract_description.unwrap_or(EXTRACT_DESCRIPTION)These descriptions are then supplied in tool definitions used by the model.
Why this matters
For deployments where API callers are not fully trusted, this allows clients to steer server-defined tool semantics and can:
Suggested fixes
Minimal repro idea
Send a chat request with:
{ "web_search_options": { "search_description": "(attacker-controlled text)", "extract_description": "(attacker-controlled text)" } }Observe these strings appear in the built tool metadata path via
get_search_tools.