What is an AI API key, and why shouldn't I share it or commit it to my repository?

A few weeks ago a client messaged us at eleven at night, pretty rattled: he’d just gotten an alert from his AI provider saying usage had spiked in the last hour, something like two hundred dollars in forty minutes. Nobody at his company had touched anything. When we checked the project’s GitHub repo — public, because he’d pushed it himself without asking us, “to show a partner” — there it was, in a commit from three weeks earlier: the API key pasted straight into the code, no environment variables, nothing. Someone, or some scraping bot, had found it and was using it to generate who knows what on his dime.

An AI API key is basically a password that identifies your account to the model provider (OpenAI, Anthropic, Google, whoever) every time your app asks it for something. If that key ends up in someone else’s hands, they can use the model as if they were you, and the bill lands on you: the provider has no way of knowing it wasn’t you, unless you catch it fast enough to revoke the key.

What we did with this client was the usual playbook: revoke the key from the provider’s dashboard the moment we saw the alert, generate a new one, and this time put it in the server’s environment variables instead of code that gets pushed to a repo. That part took ten minutes. What took longer was convincing him that his partner didn’t need to see the actual source to understand what we’d built — a recorded demo would’ve done the job — and that a “private but with the key baked in” repo isn’t as private as it sounds, since any future collaborator, or a badly handled fork, inherits it just the same.

The bill, for what it’s worth, got refunded after we filed a fraud claim with the provider. That doesn’t always happen. It depends on the provider’s policy and how fast you report it, so it’s not something worth counting on.

Since then we’ve applied one rule on every project that we used to just assume everyone already knew, without actually checking: no key ever goes in the code, all of them live in an environment file that Git itself ignores, and production keys get stored separately, in the host’s secrets manager, never in a shared document or a WhatsApp thread about the project (we’ve seen that last one more than once). It’s the same lesson we took away from auditing our own server’s security: most scares don’t come from a sophisticated attack, they come from a key someone left lying around without noticing.

What I still haven’t figured out is how to explain this to a client without it sounding like a scolding, especially when the mistake came from someone with good intentions who just wanted to show off their project.