Management UI
Bring-your-own provider key portal for AI access
Use account connections to manage provider credentials and tenant assignments.
Organizations where users or teams own their upstream provider accounts.
The problem
BYO provider keys can become risky when users paste keys into product apps, scripts, or support messages instead of a controlled backend surface.
How LLM Proxy helps
The management UI accepts provider API keys only through authenticated management endpoints and keeps public proxy requests on the tenant-secret contract.
How it works
- Sign in through the configured MPR/TAuth shell.
- Select the tenant and create or choose a provider connection.
- Enter the required credentials and settings. Verification uses the catalog default text model.
- Use generated proxy examples that never include upstream provider credentials.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| Catalog provider choices | Connection creation lists the supported providers from the catalog. | The catalog defines each required credential and setting. |
| Masked credentials | Connection details show saved credential masks and permit replacement. | A shared connection edit identifies each affected tenant. |
| Tenant route example | The text example identifies the saved provider and model. | The tenant API key remains separate from the command placeholder. |
Use-case examples
Team-owned OpenAI account
A team saves its own OpenAI key and uses the generated tenant secret in internal tools.
Specialized provider trial
A user adds a Gemini key for one workflow while leaving default examples available.
Connection detachment
A tenant can detach a connection while its usage and provider prompt remain. Other tenant assignments remain intact.
Objections and limitations
- Users need an authenticated management session before saving provider keys.
- A provider without a key cannot serve requests for that tenant.
- Provider-key encryption protects storage exposure, not runtime operators from all access.
FAQ
What is the main job of bring your own provider key portal?
The management UI accepts provider API keys only through authenticated management endpoints and keeps public proxy requests on the tenant-secret contract.
Who should read this management ui resource?
Organizations where users or teams own their upstream provider accounts.
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 Self-service LLM key management for internal teams, which covers self-service LLM key management.
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