LiteLLM MCP keyword search was reported to bypass virtual-key request limits and audit

The reporter configured a virtual key with rpm_limit=4, then issued five or six MCP keyword search requests within the rate window. All searches reportedly completed while direct tool calls hit the limit and created the expected usage records. The report traces this discrepancy to a search handler that bypasses common pre-call counter and logging paths. Semantic embedding-backed search followed a different route and reportedly did generate enforcement telemetry.

A search endpoint still consumes infrastructure and can disclose tool metadata; quota and audit coverage must include every authenticated entry point rather than only the nominal tool execution route. This is a reporter demonstration pending upstream review, not a confirmed cross-user data breach. Technical issue.

The keyword version of mcp_tool_search dispatches through a path lacking the shared pre-call quota and spend-log checks, whereas semantic ranking invokes an embedding model and traverses those checks. In the reported configuration, a key limited to four requests per minute accepted five or six keyword searches without adding an audit row; direct tool calls were refused after four. The observable effect is unaccounted request consumption and incomplete auditing, not proof that the search exposed an otherwise unauthorized tool. The side-effect ledger should count authenticated search operations irrespective of how ranking is implemented, while distinguishing a search from a later tool execution.