API key hygiene
the complete guide

1. Never paste into a chat window

The moment you paste a key into a chat input, the key rides into the provider's input log. OpenAI, Anthropic, and Google all state on commercial plans that input data isn't used for model training, but it's retained for some period for operational logs, safety classification, and incident triage. Putting a key on screen means accepting that a trace of it now sits on someone else's servers. Paste it into an internal Slack or Notion and it's also inside your Workspace admin's search scope — a former employee's export history can surface it too. The CEO testing tools is exactly when the rule shouldn't have exceptions. When you ask Claude Code to "create a .env for me", don't echo the value in the terminal either — type it directly into the editor. "Don't look at the key with your eyes, don't show it on screen, don't hand it to an LLM" — those three together are the first gate. Domestic example: in 2024 an executive at a Japanese startup pasted a key into a chat window during a demo, and within minutes high-rate calls from overseas racked up a bill in the hundreds of thousands of yen. It showed up on Twitter.

2. Route through .env

The industry standard is to keep keys out of source code and hold them in environment variables or a .env file. Python, Node.js, and Go all have dotenv-style libraries that expect startup-time loading. Drop the file at the project root and have the app read process.env.OPENAI_API_KEY. No key text ever lives in code, so you can share the repo, paste chat transcripts, and nothing leaks. For ai-executive it's the same idea — the four keys (OPENAI_API_KEY / OPENAI_API_KEY_CEO / OPENAI_API_KEY_CFO / OPENAI_API_KEY_CTO) live in .env. In the workshop we ask Claude Code to "create a .env, I'll fill the values by hand later", so the template is generated without the values ever reaching the LLM. A typical .env looks like this.

# .env  (not tracked by git)
OPENAI_API_KEY=sk-proj-xxxxxxxxxxxxxxxxxxxx
OPENAI_API_KEY_CEO=sk-proj-yyyyyyyyyyyyyyyy
OPENAI_API_KEY_CFO=sk-proj-zzzzzzzzzzzzzzzz
OPENAI_API_KEY_CTO=sk-proj-wwwwwwwwwwwwwwww

The matching .env.example lists only the key names, with empty values. That one you can commit. New team members see at a glance which slots need filling.

3. Check .gitignore, always

Splitting the key into .env means nothing if .env isn't in .gitignore. An accidental git add, a push, and then — best case — GitHub Secret Scanning catches it and reports automatically to the provider, and the key dies. Worst case, an attacker's scanner finds it first. And remember: if a repo gets flipped to public, every past commit is exposed at once. The required checks are three: (1) is .env in .gitignore, (2) does git status show .env as untracked, (3) if it's already committed, detach it with git rm --cached .env. GitHub Secret Scanning runs free on public repos and auto-detects key formats from OpenAI, Anthropic, AWS, Stripe, and other major providers. Turn on push protection and commits containing a key get blocked at push time.

# .gitignore (minimum)
.env
.env.local
.env.*.local
*.pem
secrets/

A 2024 Japanese example: a consumer-app company committed an OpenAI key, Secret Scanning caught it, OpenAI revoked it immediately — but for the ~20 minutes in between, logs showed attackers probing with adjacent keys. The detection system is there, but it's not absolute.

4. Rotate on a schedule

Treat every key as "will leak eventually" from the moment it's created. The usual cadence is every 90 days, plus immediate rotation on leak detection, departures, or vendor change. To avoid service outages from sudden swaps, document a staged rotation in the SOP. Five steps: (1) generate the new key, store in Secrets Manager, (2) update the app's env vars to the new key and verify with canary traffic, (3) run both in parallel for 7 days, (4) disable the old key, (5) confirm retirement at monthly review and reconcile logs. If you're on a cloud Secret Manager, versioning lets you flip between old and new with a single flag. Once rotation is a routine procedure, the team stops being afraid of it — same principle as the safety KY meeting at a construction site. The CEO putting it on the annual calendar is what makes it stick. Two KPIs for exec review: rotation completion rate over the last 12 months (target 100%) and longest-lived key (target ≤ 90 days).

5. Least privilege

One key should never serve multiple purposes. The ai-executive model — "4 agents = 4 keys" — is the ideal. If one agent gets compromised, the others are untouched; the blast radius stays small. In OpenAI, you can create per-Project API keys within an Organization and set model restrictions, monthly caps, IP restrictions, and allowed endpoints per Project. Anthropic Console lets you set spend caps and permission boundaries per Workspace. Same thinking as AWS IAM — narrow what each key can do. Production key gets admin, dev key gets read-only, CI/CD key only calls specific models. And — retire unused keys immediately. Don't keep keys around "in case we need them later"; they leak when no one's watching. Both Anthropic and OpenAI show last-used timestamps per key on the dashboard. Make "30 days unused = candidate for retirement" an explicit rule.

6. Separate production and development keys

Never mix production and dev keys. It's the bank-vault-vs-wallet distinction. If dev code accidentally grabs a production key, one afternoon of "just playing around" burns through a hundred thousand yen of tokens. The most reliable split is naming. Recommended template: {env}-{service}-{role}-{YYYYMMDD}. Examples: prod-oai-ceo-20260421 / dev-oai-ceo-20260421 / workshop-20260421-demo. The prefix tells you prod or dev at a glance. Do the same at the env-var level — PROD_OPENAI_API_KEY vs DEV_OPENAI_API_KEY — and have the app pick based on environment. For workshops and one-off demos, the ideal is a disposable key made the day before and revoked within 24 hours. The keys for today's workshop follow that rule — they'll be invalidated as soon as we finish. When this rhythm becomes habit, you stop second-guessing "is this prod, demo, or my personal dev key?"