OpenAI key hygiene: project-scoped keys, rotation, and keeping secrets server-side

Keys, scoped and rotated

The steps

1. Create separate projects for dev, staging, and production. Issue keys per project so a compromised dev key cannot spend production budget.
2. Give each integration its own key. When the key for the Slack bot leaks, you revoke one key, not the key that also serves your API.
3. Rotate keys on a schedule, not just after incidents. Rotation is: create the new key, deploy it, verify traffic on the new key, then delete the old one. Deleting first is how you cause your own outage.
4. Never ship a long-lived key in client-side code, mobile apps, or public repos. Browser and device clients get ephemeral session secrets minted by your server, scoped to the session.
5. Store keys in a secret manager, not env files in the repo, not chat logs, not CI output. If a key ever appears in a log, treat it as compromised and rotate.
6. Audit key usage quarterly: which keys made calls in the last 90 days, which are stale. Delete the stale ones. Unused keys are pure risk with zero value.

The trap

A single org-level key pasted everywhere "temporarily" that becomes permanent. Every copy is a leak waiting for a repo push, a screenshot, or a log aggregator.

Checklist

• Projects separated per environment; keys scoped per project and per integration.
• Rotation practiced on a schedule with a create-before-delete order.
• No long-lived keys in clients; ephemeral session secrets only.
• Keys in a secret manager, never in repos or logs.
• Quarterly audit; stale keys deleted.

OpenAI's platform documents project-scoped API keys and project-level token limits; the rate limits guide documents x-ratelimit-limit-project-tokens. Verified live at https://developers.openai.com/api/docs/guides/rate-limits.