AI API Key Governance Checklist: Isolation, Caps, Audit
AI API key governance checklist for security leads: 12 principles on isolation, spend caps, rotation, audit and data retention, plus honest notes on gaps.
Why AI API keys need their own governance framework
Traditional thinking about API key management often falls short when applied to AI APIs. The reason is that an AI API key is usually tied directly to a balance that keeps spending money. A leak does not just mean "data got seen." It means "the bill spirals out of control." This checklist is not a theoretical list. Each item comes with a "why it matters" and a "what to actually do," and it honestly marks which parts ready-made tools can help with and which still depend on your company's own processes.
The checklist
1. Do not deploy vendor keys to your hosting platform
Why: Vendor API keys usually have no ceiling. Once one leaks, the attacker can cause unlimited damage, and you can only stop it after noticing an abnormal bill.
How: Do not put keys from OpenAI, Anthropic or similar vendors directly into the environment variables of deployment platforms such as Zeabur or Vercel. Instead, use keys issued by a relay layer (such as BazaarLink). Keep the vendor key in just one place: the relay account's settings.
2. Use separate keys for each project and each environment
Why: If one key is shared, a problem in one environment exposes the quota of every project. It is also hard to work backward from the bill to find where the problem came from.
BazaarLink today: Keys can be given individual names when created (the name field). Each key is managed and revoked independently, without affecting the others.
3. Every key needs a spend cap and a reset cycle
Why: This is the only mechanism that locks in the maximum loss once a leak happens. A key without a cap means a leak can cost an unlimited bill.
BazaarLink today: When creating a key, you can set limit (a USD spending cap) and limit_reset (daily, weekly or monthly reset).
4. Set an expiry date and rotate regularly
Why: The longer a key goes unchanged, the longer the window of exposure and the more risk accumulates. This is especially true for keys that contractors, test environments, or former employees have touched.
BazaarLink today: Keys support an expires_at expiry date field. We recommend pairing this with an internal company schedule to regenerate production keys regularly (for example, quarterly).
5. Least privilege: separate management rights from calling rights
Why: If one key can both change settings and call models that spend money, a leak has a double impact.
BazaarLink today: Keys come in two types, "management" and "regular." A management key can create, modify and revoke other keys, but cannot call models directly. A regular key can call models, but cannot manage other keys. The two permissions are separated by design.
6. Automatic alerts for abnormal usage
Why: A spending cap stops the bleeding after the fact. An anomaly alert catches problems early. Ideally, when a key approaches its limit or usage suddenly spikes, the owner is notified proactively instead of discovering it at month-end reconciliation.
BazaarLink today (honest note): We have not found an automatic push alert mechanism for customers. Usage queries are self-service (through the dashboard or the API), so you have to go and check. The system does not notify you proactively. If this matters for your organization, we recommend first scheduling a script that calls the usage query API regularly to raise its own alerts, rather than assuming the system will notify you.
7. Keep an audit trail for every critical operation
Why: Who changed a key, who adjusted a quota, and who logged in to the system are the basis for after-the-fact investigation and accountability. Without an audit trail, you cannot tell who did what when something goes wrong.
BazaarLink today: Critical operations such as logins, quota adjustments and key changes are all recorded in the audit trail, with the operator, time and source IP.
8. Audit records must be exportable for compliance review
Why: If audit trails can only be viewed inside the system and cannot be exported, they become a problem during external audits or compliance reviews.
BazaarLink today: Audit records can be exported for compliance review.
9. Keys must be revocable when personnel change
Why: An employee who leaves or transfers and has touched a key should treat that key as a risk to be reassessed. Not revoking it leaves a back door that nobody is watching.
BazaarLink today (honest note): Keys can be revoked manually (DELETE), but we have not found an automated offboarding flow connected to your company's HR system. We recommend adding "key inventory and revocation" to your company's existing offboarding or project-closure SOP, and using a manual process to cover the part the system does not automate.
10. Get vendor data-handling terms in writing
Why: AI APIs often process a company's internal or customers' actual content. Whether that data is retained, or used to train models, cannot rest on verbal assurances.
BazaarLink today: The terms of service explicitly state that the relay layer itself has zero data retention. It does not log, store or review API prompts or model responses. It records only the metadata needed for billing (model name, token counts, timestamps), and this is not used to train any model. But note: this covers only the relay layer itself. The upstream model providers you actually choose (OpenAI, Anthropic, Google and others) handle requests under their own policies, and some providers may retain inputs and outputs and use them for training or improvement. You must check each provider's current terms separately. Do not assume that "zero retention at the relay" means "zero retention at every provider."
11. Organization-level multi-layer budgets and an emergency brake
Why: A single key's spend cap controls one key. But if a company has several teams and projects using keys at the same time, you also need an organization-level total budget control, so that the combined total of all keys does not spiral out of control.
BazaarLink today: Enterprise plans provide organization-level multi-layer budget controls and an emergency brake mechanism. Combined with the key-level audit mentioned above, this forms two layers of protection.
12. Test failover regularly
Why: The value of automatic multi-model failover is that the system keeps running when a provider has problems. But if it has never been tested, you will not know whether it actually works when you really need it.
BazaarLink today: Automatic failover is supported (currently in Beta). When the primary model's provider returns a 5xx error, times out or rate-limits, the request can automatically retry on a designated fallback model. Before you rely on this mechanism in production, test it yourself to confirm that its behavior meets your service-level requirements, since it is still in Beta.
Closing
Some items on this list are things the tools can do for you (isolation, caps, audit, data-retention terms). Others honestly still need your company's own processes to fill the gap (proactive alerts, automatic revocation on offboarding). Governance is not "buy the tool and you are automatically secure." It means making full use of what the tools can do, and writing what they cannot do into your company's own SOPs. The purpose of this checklist is to help you tell the two apart.
FAQ
How does governing AI API keys differ from governing ordinary API keys?
An AI API key is directly tied to a balance that keeps spending money. The loss from a leak is not just that data gets seen. It is that the bill spirals out of control. That is why spend caps, separate keys and expiry-based rotation matter more here than for a typical API.
Will the system notify me proactively when a key nears its limit?
There is currently no automatic push alert for customers. Usage queries are self-service (through the dashboard or the API). If this matters to you, schedule a script that calls the usage query API regularly and raises its own alerts.
When an employee leaves, are their keys revoked automatically?
Keys can be revoked manually (DELETE), but there is no automated offboarding flow connected to an HR system. We recommend adding key inventory and revocation to your company's existing offboarding or project-closure SOP.
What is the difference between a management key and a regular key?
A management key can create, modify and revoke other keys, but cannot call models. A regular key can call models, but cannot manage other keys. The two permissions are separated by design, which follows the principle of least privilege.
TWD billing · Taiwan invoices · leading AI models · OpenAI-compatible API