An exposed OpenAI API key can drain your billing account in minutes. Understanding how to store and protect your open ai api key properly is one of the most important steps when building with AI.
What is an OpenAI API key?
An OpenAI API key is a credential that identifies your account when your application calls the OpenAI API. It grants billing and usage access, so whoever holds the key can run requests charged to your account. Keys are created through the OpenAI platform dashboard and look like a long string starting with sk-.
Why does OpenAI API key security matter?
A leaked key causes two problems at once: someone else runs up charges on your account, and you may lose access to your own services if OpenAI rate-limits or suspends usage. GitGuardian found that 70% of secrets leaked to public repositories are still valid three years after exposure. Palo Alto Networks reported API attacks increased 41% year over year in 2025. In 2025, researchers found over 24,000 secrets in publicly accessible MCP configuration files on GitHub, with more than 2,100 confirmed active. A single exposed LLM key can hand an attacker access to dozens of models and months of undetected usage.
How do I secure an OpenAI API key?
The core rule is to keep the key out of your codebase entirely.
Use environment variables. Set the key in your shell or deployment environment rather than writing it in code. Most frameworks read OPENAI_API_KEY automatically. This keeps the value out of version control.
Use a secrets manager for production. Services like AWS Secrets Manager, HashiCorp Vault, or Google Secret Manager store credentials outside your application and inject them at runtime. This separates the secret from the code that uses it. For a comparison of available tools and how to choose between them, see How to Store API Keys Securely in AI Projects.
Create scoped keys. The OpenAI platform lets you create keys with specific project scopes. Use a separate key per project or environment so that a leak in one project does not expose everything.
Set usage limits. Configure spending limits in the OpenAI dashboard. A hard monthly cap prevents a leaked key from generating unbounded charges before you notice.
Rotate regularly. Treat API keys like passwords: rotate them on a regular schedule and immediately any time you suspect exposure.
Scan before committing. Use a pre-commit hook or a secrets scanner in CI to catch keys before they reach a remote repository.
What are common mistakes to avoid?
- Hardcoding the key directly in Python or JavaScript files
- Committing a
.envfile that contains live credentials - Logging the key for debugging and leaving those logs in production
- Using one key for all environments (dev, staging, production)
- Never checking whether the key has been exposed in a public repository
What do I do if my OpenAI API key is exposed?
If you find your OpenAI key in a public repository, log file, or commit history, treat it as compromised immediately. OpenAI keys can be abused to generate large charges within minutes — waiting to confirm the exposure before revoking is the most common mistake.
- Revoke the key now. Go to platform.openai.com/api-keys and delete the exposed key. Do not wait to investigate first — revoke first, then review.
- Check usage logs. Review your OpenAI usage dashboard for requests you did not make, particularly calls at unusual times or using models outside your normal usage pattern.
- Review your billing. Check your billing dashboard for unexpected charges. OpenAI has a process for disputing unauthorized usage — file a request if you find it.
- Scrub your git history. If the key was committed to a repository, deleting the file is not enough — the key still exists in every earlier commit. Use
git-filter-repoor BFG Repo-Cleaner to remove it from the full history, then force-push. - Generate a new key. Create a fresh key in the OpenAI platform, set a spending limit on it, and store it as the
OPENAI_API_KEYenvironment variable. Do not hardcode it. - Add monitoring. AgentGuard360 monitors your AI agent sessions and output for credential patterns — catching the next exposure before it appears in a public repository or log.
