API key security in 8 practices that actually matter

An API key works like a bank card with no PIN. Anyone who holds it spends on your account, at list price and at the speed of a script. Good API key security is still nothing like an expert project, because eight good practices, nearly all of them free and quick, cover the vast majority of real incidents. They are ranked from the most urgent to the most comfortable.

The topic concerns everyone and not only developers. As soon as a tool asks for your key, the question of where it lives and who can read it becomes yours. The answer deserves five minutes of attention. That is roughly what the checklist at the end asks of you. It applies to every account you hold.

01Key takeaways

• The risk of an exposed key is financial and immediate. Someone else's spending lands on your bill.
• Rule number one is that the key never goes into code the public can see, whether that is a web page or a Git repository.
• Use one key per use and per tool. The split limits the damage and makes any leak traceable.
• A spending cap at the provider is the safety net for the absent-minded, since it limits the worst case to an amount you chose.
• In a serious BYOK tool, the key stays stored on your side. That is a selection criterion and far more than a detail.

02What you really risk with an exposed key

Incident stories all look alike. A key gets copied into published code, a bot scans public repositories around the clock and massive calls follow within hours. The owner finds out from an alert email or from the bill. The scenario is anything but theoretical, since the providers themselves deactivate keys they detect in the wild because it happens so often.

Protection sits at the heart of the model described in the full guide to AI without a subscription. Bringing your own key means taking care of it. The good news is that this care comes down to a few simple habits that you adopt once, then apply without thinking about them again each time a new tool asks for a key.

03The eight good practices, in order

1. Never in code the public can see

A key written into a web page, a mobile app or a public Git repository is a key given away, because anything sent to the user or out in public can be read. Calls go through a server or through private local storage. Google's documentation and OpenAI's help both open their recommendations with this rule, which says a lot about its rank.

2. Environment variables instead of copies

On a server or on your own machine, the key lives in an environment variable or in a dedicated file excluded from version control, never duplicated across three scripts. Keep a single storage location per key. If you know where your keys are, you also know where they are not. Half of security comes down to that inventory.

3. One key per use

The website, the writing tool and the weekend experiment each get their own key, clearly named in the provider's console. A leak then compromises only one scope, shows up on its own usage line and can be revoked without breaking anything else. For work in a team, sharing access across a team extends this principle one person at a time.

4. Least privilege

When the provider allows it, restrict what the key can do. Limit the allowed models and accessible services, with read-only permissions where that applies. A key that can only generate text will never pay for a fraudulent fine-tuning job. The restriction costs one checkbox and removes whole scenarios from the list of things that can go wrong.

5. Regular rotation

A key that has been in circulation for two years has had two years of chances to end up lying around somewhere. Replacing it periodically resets the exposure counter to zero. You plan the change so nothing gets interrupted. Renewing a key smoothly gives the full procedure of creation, switchover and revocation.

6. The spending cap

This is the practice that forgives all the others. A hard limit set at the provider turns the worst case into an interruption at a known amount. If only one recommendation were to stay with you, it should be this one. Setting a spending limit takes one minute per account.

7. Usage monitoring

A weekly look at the usage page catches the anomaly nothing else catches, which is consumption that doesn't match your activity. Monitoring your key's usage details the routine. It takes two minutes a week with a breakdown per key. Any unusual profile should raise an alert in your mind.

8. Always encrypted, always HTTPS

The key travels only over encrypted connections. It never goes into a URL parameter, where it gets written into access logs. It never goes by email or chat to help out a colleague. Provider consoles give you everything you need to generate a fresh key on demand, so there is no good reason to send one anywhere.

04The three slips behind nearly every incident

The same trio comes up in incident after incident. First comes the key in published code, the mistake of launch night. Bots that scan public repositories find it in minutes rather than days. Next comes the key shared by chat, the kind of message where a colleague offers to lend theirs, which ends up in a conversation history that can still be searched years later.

Last comes the orphan key. It was created for a test, then forgotten and never revoked, so it hangs around with full powers while nobody watches it anymore. All three are neutralized by practices 1, 8 and 3 above. None of them requires tooling, while all of them require hygiene. Key security is a matter of habits far more than of technology.

05In a BYOK tool, the key stays with you

When a tool asks for your key, ask it about its architecture and where it stores the key. The healthy answer is that the key stays in your browser and never reaches the company's servers. Keeping the key in the browser examines that setup in detail, with its guarantees and its limits. OpenTahr chose exactly this architecture and the account is free. Your keys don't leave your device, so the tool never even sees them.

This criterion separates services better than any promise does. A service that centralizes thousands of keys is a target, while a service that stores none has nothing to steal. The security of a key is judged by who can read it. The right answer fits in one word, which is you.

06The five-minute checklist

1. List your existing keys in each console. Delete the ones you no longer use.
2. Check that none of them lives in public code, a repository or a shared document.
3. Set the spending cap and a threshold alert on every provider account.
4. Rename each key after its use. Create one per tool starting now.
5. Write down the date, because the next rotation gets planned instead of improvised. For a new key, getting a provider key guides you step by step.

07Frequently asked questions

How do I protect my API key?

Eight habits cover the ground. Keep keys out of public code, store them in environment variables, use one key per use, restrict permissions, rotate periodically, set a spending cap, check usage weekly and transmit keys only over encrypted channels. The cap is the safety net that catches every oversight.

Where should I store my API key?

On your machine or on a server, use an environment variable or a dedicated file excluded from version control, with a single copy per key. In an online tool, insist that the key stays stored in your browser instead of on the service's servers. Never put it in a visible web page or a Git repository.

What happens if a key leaks?

Someone spends on your account at the pace of an automated script, up to the cap if you set one and until you notice if you didn't. The response comes down to three immediate steps, which are revoke, check usage and replace. Responding when a key leaks sets out the full emergency procedure.

Is an API key enough to access my account?

No. The key lets someone consume the API, but it does not let them log in to your account or change its settings, which are protected by your password and two-factor authentication. That is what makes the spending cap effective even with a stolen key. The thief can spend, but the thief cannot get into the account.

Transparency. The recommendations follow the official security guides of the providers cited as sources, consulted on June 13, 2026. Exact screens and options change. Those pages are the reference. No incident figures are cited because no verifiable source was available on the day of writing. None of the providers mentioned pays us.

08Sources

1. OpenAI official help on API key safety best practices
2. Google Cloud official best practices for managing API keys
3. Anthropic official API documentation (authentication)