API Management: Standardizing key usage

Context

OpenAI API keys are currently spread across individual developer accounts rather
than the shared organisational account. Most keys appear to have been created
ad hoc by whoever needed one at the time, across a range of use cases (evals,
guardrails, feature work), so spend concentrates under a few personal accounts
and the shared account shows almost no usage.

There is also no naming or ownership convention, so it is hard to tell what any
given key is used for or whether it is still live. Several keys have been active
for a long time with no clear owner. This makes cost attribution unreliable and
the platform dashboard hard to read — pulling a six-month spend total currently
requires querying the usage API manually.

Scope

ONLY TOUCH KEYS USED BY KAAPI. DO NOT TOUCH OTHER KEYS (EG. GLIFIC BOTS, OTHER ORG KEYS)

1. Inventory

• Export all active API keys across Kaapi (id, project, creation date, creator, last used, spend over the last 6 months)
• Map each key to a use case and a current owner
• Flag keys with no identifiable owner or no usage in the last 90 days

2. Clean up

• Revoke unused and orphaned keys
• For keys still in use, create replacements under the shared account, rotate the consuming services over, then revoke the originals
• Verify nothing breaks post-rotation (staging first wherever a key backs a production path)

3. Standardise

• Document the convention: keys for regular operational use are created from the shared account, never from personal accounts
• Use projects / service accounts to separate workloads instead of separate personal keys, so usage is attributable by default
• Agree a naming scheme, e.g. <service>-<env>-<purpose>
• Define who owns key creation and revocation, and where the register of keys lives
• Add the convention to onboarding docs

Acceptance criteria

• No active keys remain under personal accounts for operational workloads
• Every active key has a documented owner, purpose, and conventional name
• Convention is written down and linked from onboarding

Notes

• Rotation needs coordination with whoever owns each consuming service; worth
  identifying those owners during the inventory step rather than at rotation time.
• Personal keys used purely for local experimentation can stay out of scope, but
  should be confirmed as non-production before being left alone.