Security & limits

What protects a leaked v-key

Two layers apply:

  1. Watermark (page-lock) — requires the page-bound prompt. Reuse for coding/math blocked with 400 Bad Request (Guardrail Violation). See Watermarking.
  2. Budget (hard cap) — workspace pool + max_budget/budget_duration per key. Even if the prompt satisfied the watermark, spend stops at the cap. See Budgets.

Roles

PrincipalCan do
Management keyManage your v-keys, read your usage
v-keyInference (/v1/chat/completions, /v1/models)

Key hygiene

  • Never ship management keys to the browser. Store them on the server. Only v-keys belong in data-api-key.
  • Copy v-keys once. GET /key/info shows metadata, not the raw secret; recreate if lost.
  • Rotate by POST /key/delete + POST /key/generate with same alias or new one, same alias is recommended to keep track between rotated virtual keys.

What the proxy does not do

  • No budget limits unless you set them.
  • No rate limit by default beyond optional rpm_limit/tpm_limit/max_parallel_requests you set per v-key.
The proxy is health-checked via GET /health/readiness{"status":"healthy","db":"connected"} at https://proxy.klunqlabs.com/health/readiness.

Next: Quickstart · API reference

Help improve these docs

Found a gap? The widget is open source — open an issue or PR in the widget repo.