Skip to main content
A Provider Key is an upstream LLM credential (e.g. sk-... for OpenAI, sk-ant-... for Anthropic) that you store with PromptGuard once. The gateway then attaches it as the Authorization header when forwarding to the provider, replacing whatever your app sends. This is the single biggest reason teams use PromptGuard in front of their LLM provider: your application code never embeds a vendor key, your CI never leaks one, and key rotation is a one-click operation in the dashboard instead of a multi-service deploy.

​
When you need this vs. when you don’t

  • You’re proxying through /api/v1/proxy/... endpoints (PromptGuard forwards to the upstream provider on your behalf).
  • You want a single rotation point for your vendor credential.
  • You don’t want browser/mobile clients to ever see the upstream key.
  • You’re running multi-tenant inference and want PromptGuard to pick the right key per project.

​
Storing a key

Open Dashboard → Gateway → Provider Keys → Add Provider Key, pick the provider, paste the key, give it a name. The key is encrypted at rest and the plaintext is never written to logs. Provider keys are stored reversibly because the proxy has to present the real credential to OpenAI or Anthropic on your behalf — unlike your PromptGuard API keys, which are stored as a one-way digest and shown only once, since we never need to read them back.

​
Accepted provider values

openai, anthropic, gemini, mistral, azure_openai, cohere, huggingface, bedrock, openai_compatible. bedrock and openai_compatible keys carry the host they may be sent to in base_url, and it is required for both: for bedrock it is the AWS region the key is for (see AWS Bedrock), for openai_compatible the service’s endpoint (see OpenAI-compatible hosts). A key without one could never be sent anywhere, so it is refused with a 400 — on creation, and on a PATCH that sets base_url to an empty string. The dashboard form asks for it when you pick either provider, as AWS region or Base URL. On PromptGuard Cloud an openai_compatible host must be on the public internet; OpenAI-compatible hosts says what is refused, and where private hosts are allowed. One more value is accepted that is not an LLM provider: pagerduty, for the Events API v2 integration key a PagerDuty alert destination authenticates with. It is stored the same way — encrypted, prefix-only afterwards — and is never used to forward a request; the destination references it by id. A base_url is refused for it.
google is accepted on input as a deprecated alias for gemini and is normalised before storage, so a key you stored as google reads back as gemini. Use gemini in new code. Any other value is rejected — the list exists so a provider name the proxy cannot resolve never reaches a row.
The response carries the plaintext key this once, with the key’s id, its base_url and the masked prefix (the first 7 and last 4 characters) that lists show from then on. To see the plaintext again use the reveal endpoint — the action is audit-logged.

​
Resolution order

When PromptGuard needs to forward a proxy request, it picks a Provider Key in this priority:
  1. The most recently created active key for the request’s project + provider.
  2. If no project-scoped key exists, the most recently created active key for the user + provider.
  3. If neither exists, the request’s own Authorization header is forwarded as-is.
This matches the access-list scoping model: project rules win, user-wide rules are the safety net.

​
Revealing an existing key

Returns the decrypted plaintext key. This action writes an audit-log entry (provider_key.reveal) recording the actor, IP, and timestamp. Use it for break-glass recovery, not as a runtime fetch path — fetching the plaintext on every request defeats the purpose of having PromptGuard hold it for you.

​
Rotation

Rotation is a four-line workflow:
  1. Create a new Provider Key in the dashboard for the same provider.
  2. Mark the old one inactive (PATCH /dashboard/provider-keys/{old_id} with is_active=false) — don’t delete it yet. New traffic will pick up the new key on the next request thanks to step 1 of resolution order.
  3. Watch the dashboard for failed upstream calls for one rotation cycle.
  4. Delete the old key. The audit log retains the deletion event for your retention period.
No application redeploy required.