ProjectTech4DevAI / ProjectTech4DevAI/kaapi-backend
API Management: Standardizing key usage
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 18
- Forks
- 10
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 14
Description
Is your feature request related to a problem?
OpenAI API keys are dispersed across individual developer accounts, leading to unreliable cost attribution and making it difficult to track usage. The absence of a naming and ownership convention results in many keys that are hard to identify, further complicating management.
Describe the solution you'd like
-
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.
-
Clean up
- Revoke unused and orphaned keys.
- Create replacements for in-use keys under the shared account, rotate the consuming services, then revoke originals.
- Verify nothing breaks post-rotation (staging first).
-
Standardise
- Document key creation convention from the shared account, not personal accounts.
- Use projects/service accounts for workload separation.
- Establish a naming scheme (e.g.,
<service>-<env>-<purpose>). - Define ownership for key creation and revocation.
- Add the convention to onboarding docs.
Original issue
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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No repository files, tests, or code entry points are named. Start by following the inventory scope in this issue and the usage API it identifies, then map Kaapi-owned keys to owners and services before planning rotation. Done means operational keys are under the shared account, each has an owner, purpose, and conventional name, and the convention is linked from onboarding documentation.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100