What Happens If an AI API Key Leaks, and How Should a Company Store It?
A leaked API key lets someone else call AI on your company's account. Per OpenAI, this can cause data loss, unexpected charges, a depleted quota, and interrupted API access. If a key leaks, revoke it immediately, switch to a new key, and review usage. Day to day, four things matter: keys stay out of code, repositories, and chat; each person or system has its own key; keys have expiration dates and are rotated; and spend limits are set.
1. How keys usually leak
- Hard-coded and pushed to a repository. OpenAI notes that committing keys to source code is a common way credentials are compromised. A public repository exposes them outright; a private one can leak them in a breach.
- Shipped in browsers or mobile apps. OpenAI advises never deploying keys in client-side environments; route requests through your own backend server.
- Passed around in chat, email, or screenshots. These records end up in many places and are hard to pull back.
- Written into an AI's system prompt. OWASP warns that credentials and connection strings should not be in system prompts, which can be extracted.
2. Four steps when a key leaks
- Revoke immediately. OWASP Secrets Management: exposed keys should be revoked immediately.
- Issue a new key. Generate a new one, update the systems that use it, and confirm it works.
- Review usage. Check the usage page for activity your team did not generate.
- Clean up the exposure. Remove the revoked key from repository history, chat logs, and system logs, and find out how it leaked so it does not happen again.
3. Seven everyday storage rules
Based on OpenAI's "Best Practices for API Key Safety" and the OWASP Secrets Management Cheat Sheet:
- One key per person and per system. OpenAI does not support sharing keys; permissions can be set per key.
- Set expiration dates and rotate. OpenAI project keys can have expiration dates, and administrators can cap key lifetime. Revoke the old key once the new one is confirmed.
- Store keys in environment variables or a secrets manager. Not in code. A dedicated key management service keeps keys separate from the application.
- Scan before commit. OWASP recommends enabling secret detection on the developer side to catch keys before commit; GitHub's push protection, for example, blocks a push when it detects a secret.
- Set spend limits with hard enforcement. OpenAI recommends monthly spend limits with hard enforcement to cap the cost of a leaked key; alerts alone do not stop traffic.
- Restrict source IPs. OpenAI offers IP allowlisting: only listed IPs can use the key, and other requests are rejected even with a valid key.
- Least privilege and audit logs. Give each key only the permissions it needs, and keep tamper-resistant records of who used which key and when.
One point often missed: keys should be issued under the company's own account. If a key belongs to a contractor's or an individual's account, the bill, usage logs, and power to revoke are not in the company's hands.
How Think BIG handles keys
Think BIG (Think BIG Make it Real Co., Ltd.) is an enterprise AI Agent deployment provider headquartered in Taiwan. Starting from protecting company data, we build AI Agents inside the client's own environment (company hardware, or a cloud server under the company's account). There are two deployment options: with the on-premises version, models and documents are processed on company hardware; with the cloud-assisted version, employees' questions and the document passages the system retrieves are sent to the model provider for processing.
- Clients apply for their own keys: AI model fees are paid by the client directly; the client applies for the API key with our engineers' guidance, and cloud accounts are opened under the client's name.
- Keys not exposed: keys stay only in permission-protected configuration files, never in the repository or in chat.
- Pre-delivery security review: before each system is delivered, its code and configuration go through a security review that includes confirming keys are not exposed; if it does not pass, it is not delivered.
The actual scope of Think BIG's services follows what both parties confirm.
FAQ
- Q1: What happens if an OpenAI API key leaks?
- Per OpenAI, a leaked key lets others use your account's quota without your consent, which can cause data loss, unexpected charges, a depleted quota, and interrupted API access.
- Q2: What should you do when an API key leaks?
- Revoke it immediately, generate a new key and update your systems, review usage logs, then remove the leaked key from repository history, chat, and logs and find the cause.
- Q3: Can an API key be written into code?
- Not recommended. OpenAI notes that committing keys to source code is a common leak path, and recommends environment variables or a key management service, and never placing keys in browsers or mobile apps.
- Q4: How can you limit the damage from a leaked key?
- Set monthly spend limits with hard enforcement, give keys expiration dates and rotate them, enable IP allowlisting, and grant each key only the permissions it needs.
- OpenAI Help Center, Best Practices for API Key Safety (no sharing, expiration and rotation, no client-side keys, no commits, environment variables, spend limits, IP allowlisting, consequences of a leak): help.openai.com
- OWASP, Secrets Management Cheat Sheet (least privilege, rotation, pre-commit detection, auditing, revocation on exposure): cheatsheetseries.owasp.org
- GitHub Docs, About push protection: docs.github.com
- OWASP, LLM07:2025 System Prompt Leakage (no credentials in system prompts): genai.owasp.org
This article summarizes public official documents, laws, and security standards to help companies evaluate AI adoption. It is not legal advice. For Taiwan law, the latest text on the Laws & Regulations Database prevails; external documents, prices, and specifications follow their original sources. The actual scope of Think BIG’s services depends on what both parties confirm.