An OpenAI API key should be scoped to one job. The prototype key that quietly became load-bearing — powering a production feature, two internal tools, and a demo — cannot be rotated, restricted, or revoked without breaking something nobody can name in advance. Sprawl, not sophistication, is what turns small problems into big ones.

Start with project separation. Keep production, development, experiments, demos, and client work in different projects where practical. A prototype key should have no path into production usage or unrelated customer data.

Use service accounts for automation instead of tying long-running systems to individual users. Human accounts change roles, leave companies, and accumulate permissions. Workload identity should be owned by the system it serves.

Restrict key permissions. A narrowly scoped key beats one that can administer resources, create more keys, or operate across projects. Default to the least authority the workload needs.

Keep keys server-side. Not in browser code, mobile apps, shared notebooks, public repositories, screenshots, or tickets. Treat them like production secrets, because they are.

Use a secrets manager and a tested rotation path. Rotation nobody has practiced will be skipped when it matters most. A key should have one job, one owner, and one clean revocation path.

Monitor usage by project and workload. Sudden spikes, unusual models, and after-hours patterns should be visible enough for someone to notice early.

Budgets and rate limits are not full security controls, but they bound damage and make anomalies visible before the bill does.

Where supported and practical, prefer workload identity federation or other short-lived credential patterns over static secrets that live forever in deployment history and on developer machines.

What to check now: project boundaries, service accounts, key permissions, Admin API keys, server-side storage, rotation dates, owner records, usage dashboards, budgets, rate limits, and the procedure for immediate revocation.