Managing API keys and secrets

An API key is a credit card without a PIN. With agents that read your files and write code, there are more keys lying around than ever.

After this lesson you have: your keys in a safe place, a separate key with a limit per project, push protection on, and a plan for the first 15 minutes after a leak.

How keys leak

In 2025, GitGuardian counted around 29 million new secrets in public GitHub commits (+34%). Keys for AI services rose by 81%, and in MCP server config files they found 24,008. Of the valid secrets from 2022, 64% still worked four years later.

Where	How it goes wrong
Git	A key in the code or a committed .env file. Deleting it in a later commit doesn’t help: it’s in the history.
Frontend	A key in JavaScript or an app bundle. Anyone can read it out.
Agent files and logs	MCP configs, session logs and .env that your coding agent reads. Infostealers specifically look there.
Stored with third parties	In the OpenCode Console hack (Oct 2026), users’ stored AI keys were abused; some users reported damages of more than $1,000.
Screenshots and chats	A key on screen during a demo, or pasted into a chat with an AI assistant or colleague. Vapi literally lists logs, screenshots and agent chats as places where a key must never appear.

What it costs: a Mexican startup that normally spent $180 a month on Gemini got a bill of $82,314 in about 48 hours in February 2026, after a stolen key. Google pointed to the shared responsibility model.

Where keys do belong

Situation	Place	How it works
Your own laptop	Password manager with a CLI	1Password CLI or Bitwarden Secrets Manager only puts the key into an environment variable at startup. Your project contains just a reference.
Server or VPS	Environment variables from a file outside your repo, or sops + age	sops encrypts your config file, so it can safely go into git.
Hosting, CI, serverless	The platform’s secret manager	GitHub Actions secrets, Vercel/Netlify environment variables, cloud secret managers.

With 1Password your .env looks like this (no secret, just a reference):

OPENAI_API_KEY="op://Werk/OpenAI/credential"

And you start your app like this:

op run --env-file=.env -- npm start

With Bitwarden Secrets Manager it’s bws run -- npm start (with your access token in BWS_ACCESS_TOKEN).

Setting it up properly

1. One key per project, client or agent. Give each key a name (“klant-bakkerij-chatbot”) and only the permissions it needs: read-only where possible, one repo for a GitHub token, an expiry date. If one leaks, you revoke only that one. Working for clients? Keep the key on the client’s account.

2. A spend limit per project or key. Every major provider has one now, but they work differently: OpenAI per organisation and per project (only a hard stop if you turn on Enforce a hard limit), Anthropic per organisation and per workspace, Google per project in AI Studio (with up to about 10 minutes’ delay) and OpenRouter per key. Set it low and turn off automatic top-ups. As of November 2026; check the official pages: OpenAI, Anthropic, Google Gemini, OpenRouter.

3. .env in .gitignore, before your first commit.

   echo ".env" >> .gitignore

4. Push protection on. For your personal account, GitHub turns on push protection for yourself by default for public repos; check it under Settings → Code security, heading “User”. Per repo: Settings → Advanced Security → Secret Protection → Push protection → Enable. Free for public repos; for private repos you need the paid GitHub Secret Protection.

5. Scan what’s already there. gitleaks searches your entire git history:

   gitleaks git -v

   Getting unknown command "git"? Then you have a version older than 8.19 (for example via apt on Ubuntu 24.04); use gitleaks detect -v instead.

   Keys you find are burned, even if they were only “briefly” in an old commit. Revoke them.

Your coding agent reads your .env without asking

In Claude Code, read-only commands like cat run without an approval prompt in every mode, so cat .env does too. Whatever the agent reads then sits in your session and logs. Work with references (1Password, Bitwarden) so there’s nothing to read, or add a deny rule under permissions in .claude/settings.json: “deny”: [“Read(./.env)”, “Read(./.env.*)”].

A 'public' Google key can suddenly open Gemini

For years Google said keys for things like Maps aren’t secrets. In February 2026 Truffle Security found 2,863 such public keys that could also use Gemini, because the Gemini API was enabled in the same project. Put Gemini in its own project and restrict every Google key to the APIs it needs (API restrictions).

The first 15 minutes after a leak

1. Revoke and replace (minute 0-5). In the provider’s dashboard: revoke the old key, create a new one, put the new one in your password manager and your apps. This first, clean up afterwards. Bots find public keys within minutes.

2. Put the brakes on costs (minute 5). Lower the limit, turn off automatic top-ups. For voice services: temporarily disable outbound calling.

3. Check logs and costs (minute 5-10). Usage per key or project: unknown models, regions or times? For cloud keys, also check for new users or keys in IAM, because attackers often create a spare. Did the leak come from malware on your computer? Then all keys and sessions on that machine are suspect.

4. Clean up git history (minute 10). Remove the key from the code. If it was in a pushed commit, follow GitHub’s guide Removing sensitive data (with git filter-repo). Clones and forks keep it anyway, so this is cleanup, not a fix.

5. Report (minute 10-15). Ask the provider’s support to waive the unjustified charges; OpenAI refunded affected OpenCode users, while Google held to shared responsibility in the $82k case. Working for a client: tell them right away. Could someone access personal data? Then report it within 72 hours to the Autoriteit Persoonsgegevens (the Dutch Data Protection Authority), unless it’s unlikely to pose a risk to people (how the notification duty works).

Security

• What can go wrong: a key in git, your frontend or a chat gets found within minutes and used on your bill.
• What you do: keys only in a password manager or secret manager, one key per project with a spend limit, and push protection on.
• Keys and agents: give an agent only the key it needs for this task, never your main key (malicious skills and MCP).

Checklist

0/7

• My keys are in a password manager or secret manager, not in code
• Every project or client has its own key with minimal permissions
• Every key or project has a low spend limit, without automatic top-ups
• .env is in .gitignore
• Push protection is on
• I've scanned my git history for old keys
• I know what to do in the first 15 minutes after a leak

Your progress is only stored in this browser.

Test yourself

1. 1You notice you pushed an API key to a public repo. What do you do first?

   Delete the commit and force-pushRevoke the key and create a new oneWait and see if anything happens

2. 2Why one key per project or client?

   Because providers require itBecause if there's a leak you only revoke that one, with its own limitBecause it's cheaper per token

3. 3What is the safest place for an API key on your laptop?

   A .env file in your projectA note in your chat with the AI assistantA password manager that only passes the key on at startup

Next lesson: hardening your server. Not self-hosting anything? Continue to the security check for your app.