Responses API over WebSocket (/v1/responses upgrade) bypasses every usage-hook scrub #129

Summary

litellm 1.83.14 serves the Responses API over WebSocket too: @router.websocket("/v1/responses") and "/responses" in proxy/response_api_endpoints/endpoints.py (responses_websocket_endpoint, route_type="_aresponses_websocket"). That path relays upstream events over the socket without going through async_post_call_streaming_iterator_hook or async_post_call_success_hook. That means none of the scrubbing applies on it: the #637 allowlist, and the neutral ids, id padding and canonical stream from helmcode/nan-devops#665.

The Cloudflare edge normaliser doesn't read 2xx bodies by design, so it doesn't cover this path either.

To verify (read-only)

• Is the route reachable through Cloudflare / Traefik on api.nan.builders and api.helmcode.com? Test with an Upgrade: websocket request using the synthetic key.
• If it is: do the frames carry the upstream's raw item ids, model slugs and provider-only fields? Expected yes.
• Are any members using it? Check SpendLogs call_type for _aresponses_websocket.

Options

1. Block the WebSocket upgrade on /v1/responses at the edge or in a Traefik middleware, and return a clear 4xx. Simplest.
2. Or wrap the relay so it runs the same canon. That needs a fork patch, since there is no hook.

Found in the security review of helmcode/nan-devops#665 (#122). It is out of scope there on purpose.

🤖 Generated with Claude Code