API keys: a password that can cost you money

A simple definition

When a program calls an API, the provider needs to know who is asking, so it can apply the right limits and send the bill to the right account. That’s the API key’s job: a long string of characters, created in the provider’s developer console, that the program attaches to every request. At Anthropic, for instance, it goes in the request’s Authorization header.

OpenAI’s documentation is blunt: your API key is a secret; don’t share it with others or expose it in client-side code such as browsers or apps.

A concrete example

A developer builds a small assistant for her team and pastes her key straight into the code, “just for testing”. She then pushes the project to a public repository. Anyone can now read the key, copy it and use it, and the charges pile up on her account. OpenAI itself names keys committed to source code as a common way credentials get compromised. The right approach: store the key in an environment variable (such as OPENAI_API_KEY or ANTHROPIC_API_KEY, which the official SDKs read automatically) and never write it into a file you publish.

Security best practices

• Never share or publish it: not in an email, a screenshot, a forum post, a code repository or a web page.
• Keep it server-side. A key embedded in a mobile app or website can be extracted by any visitor.
• Use environment variables or a secrets manager, as both OpenAI and Anthropic recommend.
• One key per person or per use case, so you can revoke one without breaking everything.
• Set an expiration and rotate keys regularly; Anthropic lets you choose an expiration when you create a key.
• Cap spending in the console and monitor usage: it’s your safety net alongside rate limits.
• Revoke immediately any key you suspect has leaked.

These rules matter even more for autonomous agents: a broadly scoped key handed to a poorly supervised agent, or exposed to prompt injection, can lead to unwanted spending or actions. Our Can I trust an agent with this? tool helps you weigh those risks.

Common myths

• “My repository is private, so the key is safe.” A private repo can be made public, shared or cloned; the key doesn’t belong there.
• “I’ll delete the key later.” A published key can be copied very quickly, and a repository’s history keeps it even after you delete the file: revoke it right away.

Related terms: API, rate limit, price per million tokens, prompt injection, sandboxing.