Security
Reject client-supplied provider key leaks
Fail public proxy requests that try to send upstream provider API keys in query, JSON, or multipart input.
Security-conscious teams that want mistakes to fail before provider credentials spread.
The problem
A caller may accidentally include an OpenAI or provider api_key field in a proxy request body, query string, or multipart form.
How LLM Proxy helps
LLM Proxy public endpoints reject provider-key-like fields so upstream credentials stay in server-side configuration or authenticated management storage.
How it works
- Keep upstream provider credentials out of public proxy requests.
- Authenticate clients only with key=<tenant secret>.
- Use management APIs for provider key save/update/removal.
- Treat rejected provider-key fields as integration bugs to remove.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| Query rejection | Provider-key-like query fields fail at the public endpoint. | A leaked api_key parameter is not forwarded. |
| JSON rejection | Text request bodies cannot carry upstream provider keys. | Prompt payloads stay separate from provider credentials. |
| Multipart rejection | Dictation forms reject provider-key-like fields too. | Audio upload paths follow the same boundary. |
Use-case examples
Frontend mistake
A form accidentally posts provider_api_key and receives a client error.
Notebook cleanup
A notebook migration removes OPENAI_API_KEY from request bodies and uses the tenant secret instead.
Dictation upload
A multipart /dictate request includes only audio and proxy authentication.
Objections and limitations
- This catches provider-key-like request fields; it does not inspect arbitrary prompt text for secrets.
- Tenant secrets must still be protected by client teams.
- Provider credentials belong in backend config or authenticated management storage.
FAQ
What is the main job of reject client provider key leaks?
LLM Proxy public endpoints reject provider-key-like fields so upstream credentials stay in server-side configuration or authenticated management storage.
Who should read this security resource?
Security-conscious teams that want mistakes to fail before provider credentials spread.
Does this page claim provider performance or pricing advantages?
No. The supported claim is about LLM Proxy's documented routing, configuration, management, security, usage, and deployment contracts. Provider cost, speed, rankings, and benchmark claims are not made here.
Where should setup details come from?
Use the main README and implementation notes for current command, config, and endpoint details. This page summarizes the workflow without replacing LLM Proxy documentation.
What should I read next?
A closely related resource is Keep provider API keys server-side for LLM apps, which covers server-side provider API keys.
Related resources
Use this pattern in LLM Proxy
Start from the canonical API reference, then use the management surface when the workflow needs tenant or provider configuration.
Open API reference