## The gap

On a multi-tenant proxy (multiple teams / virtual keys), the response-cache key is derived only from the request parameters (model + messages + settings) — **not** the caller's team or key. So two different teams sending the same request **share cache entries**: team B is served team A's cached response, and the hit is observable via the `x-litellm-cache-key` header (identical across teams). With the Redis semantic cache, even a *similar* request from team B hits team A's entry.

## Reproduce

1. Enable the Redis cache: `litellm_settings: {cache: true, cache_params: {type: redis}}`. 2. Create two virtual keys on two different teams (`/team/new` + `/key/generate`). 3. Send the same `/chat/completions` request with each key.

→ Both responses carry the **same** `x-litellm-cache-key`; team B's response is team A's cached generation.

## Why it matters

- Cross-tenant response reuse (one tenant served another's generated/billed output). - A cache-probing oracle: a tenant can infer whether another tenant asked something via cache hits. - No documented warning, and no built-in mitigation (only a manual per-request `namespace`).

## Proposed fix

A `cache_params` option to fol…