How do I know whether I am handling one?

As soon as you plug in an outside service — payments, email sending, maps, databases, AI — it gave you a key. A long string of characters, often preceded by a short prefix.

Is deleting the key from the code enough?

No, and this is the part everyone misses. A key published even briefly must be treated as compromised. The only action that settles it is revoking it at the service and creating a new one.

My project is private, am I at risk?

The risk drops, it does not vanish. A repository flips to public by mistake, a collaborator is added, a backup gets shared. The right habit does not depend on a visibility setting.

What can someone do with my key?

Anything you can do yourself with that service, billed to your account. Depending on the key: send emails in your name, read your database, spend your budget.

What an API key is, and why you must hide it

People mention secret keys, environment variables, a file you must never publish. You nod without understanding. Your AI wrote one somewhere inside your project, and you know neither where it sits nor what happens the day somebody else happens to find it there.

An API key is a password your site presents to a service in order to act in your name. Published in your code, it is spotted by bots within minutes. And removing it fixes nothing: until it is revoked, it stays usable by whoever copied it.

The closest image

An API key is a password your site uses on your behalf.

When your site sends a confirmation email, you are not the one signing in to the sending service: your site is, with a key proving the request really comes from you. Same for taking a payment, showing a map, querying a database or calling an AI.

In practice it looks like a long, meaningless string of characters, often preceded by three or four letters naming the service. You received one the day you plugged in your first outside tool, and you probably did not notice it.

Why it must never end up in the code

Your site’s code is made to be shared, backed up, uploaded, sent to someone helping you. That is normal and useful.

A key sitting inside it follows every one of those paths. It ends up in backups, in version history, in the file you sent a friend to take a look at.

And above all, if that code reaches a public space, it becomes readable by anyone. This is not hypothetical: bots continuously trawl public repositories looking for exactly these strings. The documentation of the platforms hosting that code says so outright — a publicly exposed credential is located within minutes, and exploitable within hours.

What a stranger can do with it

Anything you can do with the service, billed to your account.

An email-sending key lets someone send email in your name, which permanently damages your address’s reputation. A database key opens what it contains, including your subscribers’ addresses. An AI key spends your budget, and that is the most frequent scenario: the bill arrives before you understand.

None of these uses raises an alert on your side. Nothing breaks. Your site keeps working normally while somebody helps themselves.

The mistake that always follows the first one

This one deserves its own paragraph, because almost everybody makes it.

You realise the key was in the code. You delete it. You save. You tell yourself it is dealt with.

It is not dealt with. The official documentation is categorical: removing it from the codebase, pushing a new version, or even deleting and recreating the project does not prevent it being exploited. What was published may have been copied, and your key still works.

The only action that genuinely settles it has two steps: revoke the key at the service that issued it — it then stops working for everyone, the copier included — then create a new one and store it properly.

Treat any key that has been visible even for a moment as permanently compromised. That is severe, and it is the only position that holds.

The reflex before publishing

It comes down to one question, asked at every upload: does anything in what I am sending look like a password?

Three places cover most accidents. Configuration files, where keys naturally land. Files you created in a hurry to test something and never cleaned up. And the screenshots you share: a key legible in an image is a published key, and nobody thinks of it.

If you work with an AI, there is one more trap. A key pasted into a conversation so it can “see the problem” has just entered somewhere you do not control. Never paste one into a conversation — describe the problem, not the credential.

The difference between remembering and being protected

Everything above is a good habit, and a good habit has one flaw: it depends on your vigilance on a Friday evening when you are in a hurry to publish.

That is exactly the kind of risk a frame is built to absorb: a written rule states the prohibition, an automatic check refuses the action. The first reduces how often accidents happen, the second decides what happens on the day you forget.