Security
Rotate generated LLM Proxy client keys with confidence
Automatically create a missing LLM Proxy client key, show it once, store only its digest, and replace it through an explicit confirmed rotation.
Teams that want self-service client access without permanent retrievable secrets.
The problem
Long-lived client secrets become harder to control when users can retrieve old raw values or when rotation requires operator edits.
How LLM Proxy helps
LLM Proxy generates tenant secrets, returns them once, stores only SHA-256 digests, and replaces a current value through one authenticated management operation.
How it works
- Open Settings after signing in.
- Copy the one-time client key created automatically for a profile that does not have one.
- Use the generated secret in public proxy request examples.
- Confirm Replace key when access should change, then copy the one-time replacement.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| One-time display | Generated secrets are shown once after creation. | The database stores only their digest. |
| Immediate replacement | The prior secret stops authenticating as soon as its replacement is stored. | Access can be rotated without provider-key rotation. |
| Secret-safe examples | Request examples retain the <generated-secret> placeholder after creation. | Raw client keys remain confined to the one-time Key field. |
Use-case examples
New app secret
A developer copies the automatically created client key and substitutes it for the /v2 example placeholder.
Compromised client
A user confirms replacement, copies the new secret once, and updates the authorized client.
Provider key unchanged
Rotating the tenant secret does not require changing the saved provider API key.
Objections and limitations
- If the one-time value is lost, the user must generate a new secret.
- Tenant secrets remain application credentials and need normal secret handling.
- A client key cannot be deleted independently; delete the owning non-final tenant when the whole tenant should be removed.
Repository evidence
export function generateSecret() {
return requestJSON(`${MANAGEMENT_BASE_PATH}/secrets`, { method: "POST" });
}Verified 2026-07-26 by Tyemirov on GitHub against site/assets/llm-proxy/js/core/backendClient.js.
FAQ
When does LLM Proxy create a client key?
The management UI creates one after authentication when the current profile reports that no client key exists. A configured profile does not trigger another creation request.
Can the raw generated client key be retrieved later?
No. The raw value is presented once in a masked, read-only field, while the backend stores only the digest used to authenticate proxy requests.
What does replacing the client key affect?
Replacement immediately stops the prior client key from authenticating public proxy requests. It does not remove or rotate separately stored upstream provider credentials.
Do request examples embed the generated key?
No. Examples retain the <generated-secret> placeholder so the one-time raw value does not enter page markup or copied example commands.
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