Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.promptguard.co/llms.txt

Use this file to discover all available pages before exploring further.

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 with the same envelope used for your dashboard API keys; the plaintext is never written to logs. 
# Or via the API:
curl -X POST https://api.promptguard.co/dashboard/provider-keys \
  -H "Authorization: Bearer $DASHBOARD_TOKEN" \
  -H "X-CSRF-Token: $CSRF" \
  -H "Content-Type: application/json" \
  -d '{
    "provider": "openai",
    "name": "Production OpenAI",
    "key": "sk-proj-..."
  }'
The response contains the key’s id and prefix (the first 12 characters of the masked key, used for display) but not the plaintext. 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

curl -X POST https://api.promptguard.co/dashboard/provider-keys/$KEY_ID/reveal \
  -H "Authorization: Bearer $DASHBOARD_TOKEN" \
  -H "X-CSRF-Token: $CSRF"
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.