Credentials policy
No credentials in this handbook. Ever.
This page describes where credentials actually live, not what they are.
Categories of secrets
| Type | Where it lives | Who has access |
|---|---|---|
| Supplier API keys | Supabase Vault (OMS project) | OMS runtime only |
| Stripe API keys | Vercel environment variables | OMS runtime only |
| Shopify admin API tokens | Vercel env vars | OMS runtime only |
| Google Ads / Analytics | Google accounts owned by Ray | Via Google login |
| Cloudflare API tokens | Cloudflare account | Via Cloudflare login |
| Supabase service role keys | Vercel env vars + .env.local (local dev only) | OMS runtime only |
| GitHub personal access tokens | Individual developer machines | Each developer |
| Passwords for shared services | Password manager (1Password / Bitwarden) | Specific staff per service |
Rules
- If you see a credential in a commit, in Slack, in the handbook, or in any chat — treat it as exposed. Rotate immediately.
- No shared accounts. Each person has their own GitHub, Supabase, Cloudflare, etc. login. Use SSO where available.
- Password manager for shared services only. Shared items in the password manager must have clear access control.
- Rotation schedule:
- Supplier API keys: every 12 months or when compromised
- Developer tokens: every 6 months
- After any team member offboarding: rotate anything they had access to
When a credential is exposed
- Rotate it immediately (before investigating root cause)
- Scan logs for any usage from unexpected IPs
- Notify Ray if the exposure was external
- Write an incident log entry in incident response
Offboarding checklist
When a team member leaves:
- Remove from GitHub org
- Remove from Cloudflare account
- Remove from Supabase organization
- Remove from Google Workspace
- Remove from Cloudflare Access for the handbook
- Remove from password manager
- Rotate any shared credentials they had access to
- Audit git history for any credentials they may have committed