Kubera

Kubera — Guardian of Treasures (Secrets & Credentials)

Kubera guards the vault: every key, token, and credential the company holds.

Never commit secrets

• Run gitleaks as a pre-commit hook (pre-commit framework) and in CI on every PR.
• .env is in .gitignore in every repo, always. Commit a .env.example with keys but no values.
• If a secret ever touches git history, treat it as exposed: rotate immediately, then scrub history (git filter-repo). Rotation first — scrubbing alone is not enough.

Storage & scoping

• Production secrets live in a secrets manager (AWS Secrets Manager, GCP Secret Manager, Doppler) — never in .env files on servers or baked into images.
• One key per environment (dev/staging/prod) and per service. Never share a prod key with staging or reuse one key across services.
• Least scope always: read-only tokens where writes aren't needed, expiring tokens over permanent ones, repo-scoped over org-scoped PATs.
• Rotate on any suspected exposure, on team member departure, and on a calendar schedule (every 90 days for high-value keys).

Keeping secrets out of the wrong places

• Never log secrets. Redact Authorization headers and key-shaped values in logging middleware and error reporters (Sentry before_send).
• Never put secrets in frontend code. Anything in NEXT_PUBLIC_* or VITE_* ships to the browser — those are for public config only. Calls needing a secret go through your backend.
• Python: load config via pydantic-settings with SecretStr so values don't repr into logs.
• JS/TS: validate process.env at startup (zod schema); fail fast on missing keys instead of shipping undefined to prod.

CI/CD

• CI secrets come from GitHub Secrets (environment-scoped) or, better, OIDC federation to the cloud provider — no long-lived cloud keys in CI at all.
• Never echo secrets in workflow steps; GitHub masks known secrets but not derived values.
• Restrict which environments/branches can access deploy secrets (GitHub Environments with protection rules).

AI-native specifics

• Separate LLM API keys (Anthropic/OpenAI) per environment, each with its own spend limit — a leaked dev key must not be able to burn the prod budget (see lakshmi).
• Never send secrets inside prompts. Scrub credentials from any context, logs, or user data before it reaches an LLM API.
• Review LLM-generated code for hardcoded keys before committing — models happily inline placeholder or real-looking credentials. Gitleaks catches most; eyes catch the rest.

Before every commit — checklist

• gitleaks pre-commit hook installed and passing
• .env ignored, .env.example up to date
• No secrets in frontend bundles or NEXT_PUBLIC_/VITE_ vars
• New keys are least-scope, per-env, per-service
• Any exposed key already rotated