Add an authorized person

Access is per-person, via LiteLLM virtual keys — not a shared password, and not the platform’s own SSO login-gate (that gate is cookie/session-based and would block plain API/CLI callers, so it’s deliberately left off for this tunnel). not built

Generate a key

curl -s http://127.0.0.1:4001/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" -H "Content-Type: application/json" \
  -d '{
    "models": ["local-qwen3-coder"],
    "user_id": "<their email>",
    "key_alias": "llm-demo-<their name>",
    "metadata": {"purpose": "llm.bunsenbrenner.org local model demo", "authorized_email": "<their email>"}
  }'

The response includes "key": "sk-..." — hand that to them directly (it’s shown once; LiteLLM stores only a hash). The models array is the actual enforcement: this key will 401 on every model on the proxy except local-qwen3-coder, including the cloud-routed ones this same LiteLLM instance also fronts.

measured Enforcement reproduced 2026-08-29 with the example key from the tutorial: it is refused for other models. The refusal now returns HTTP 403 / key_model_access_denied; earlier captures in these docs show 401.

Revoke one

curl -s http://127.0.0.1:4001/key/delete \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" -H "Content-Type: application/json" \
  -d '{"keys": ["sk-the-key-to-revoke"]}'

List everyone with access

curl -s "http://127.0.0.1:4001/key/list?user_id=<their email>" \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY"

These calls only work from the origin host (127.0.0.1:4001 isn’t exposed through the tunnel) — that’s deliberate: key management stays off the public endpoint entirely.