If you are building a website or application with the help of artificial intelligence, chances are that at some point you have come across something called an API Key.

The AI asks you for a key, you copy it, you paste it, and suddenly everything starts working.

Perfect.

The problem is that many times we keep building without asking ourselves something important:

what is that key really, and what happens if someone else manages to see it?

An API Key is not simply one more line of text inside your project. In many cases it works as a credential that allows your application to use external services.

And depending on the service, exposing it can mean anything from consuming your balance to allowing someone to use resources associated with your account.

What is an API Key?

An API Key is a key that identifies and authorizes your application when it tries to use another service.

For example, your project might need to connect to:

  • an artificial intelligence model,
  • a maps service,
  • an email platform,
  • file storage,
  • a database,
  • or any other external API.

You can think of it as an access key.

Your application presents that key and the external service responds:

“Yes, this project has permission to use me.”

The problem appears when that key ends up in the hands of someone who should not have it.

What can happen if an API Key gets exposed?

It depends entirely on the service and the permissions associated with the key.

In some cases, someone could use it to make requests on your behalf.

That could lead to:

  • unnecessary consumption of your quota,
  • exhaustion of usage limits,
  • unexpected charges,
  • abuse of services associated with your account,
  • or access to features that should be restricted.

Not all API Keys carry the same level of risk.

There are keys designed to be used publicly and others that must be kept completely private.

That is why it is not enough to think:

“It is an API Key, so I must hide it.”

What matters is knowing what type of key it is and what permissions it has.

The common mistake when building with AI

This scenario is quite common.

You are building an application and the AI tells you something like:

Add your API Key here.

You copy the key.

You paste it into the code.

The feature starts working.

And you keep building.

At that moment, everything seems fine.

The problem may appear later, when that code ends up published in a repository, deployed to the internet, or sent directly to your users’ browsers.

The application can work perfectly while at the same time exposing a sensitive credential.

Where should I store my API Keys?

When a key must remain private, it normally should not be written directly inside the source code.

A common practice is to use environment variables.

Instead of writing something like:

sk-123456789

directly in your code, your application uses a reference like:

API_KEY

and the actual value is configured outside the code.

This allows you to separate sensitive configuration from your application’s logic.

But here another important point comes up.

Using .env does not automatically mean your key is safe

This is one of the most common mistakes.

Many tools, tutorials, and even AI assistants tell you:

Put the key inside a .env file.

That can be correct.

But storing a key in .env does not by itself guarantee that it stays private.

It all depends on how it is used afterwards.

If you are working on a frontend application and that variable ends up included in the code the browser receives, any user could end up seeing it using the developer tools.

That is why a private key should normally be used from a part of the system that the user does not receive directly, such as a backend or a server-side function.

The mental rule can be simple:

If the browser needs to receive the key for your code to work, the user can probably see it too.

Frontend and backend: an important difference

When someone starts building with AI, these concepts may seem unnecessarily technical.

But to understand API Keys, you only need to know one basic difference.

The frontend is the part of your application that reaches the user’s browser.

The backend works behind the scenes and can execute operations without directly handing its code or credentials to the user.

That is why, if you need to use a key that must remain private, a common architecture would be:

User ↓ Frontend ↓ Backend ↓ External service

The backend uses the API Key.

The browser never needs to know it.

What should I check before publishing my project?

Before putting a website or application on the internet, it is worth reviewing a few basic things.

Ask yourself:

  • Do I have keys written directly inside the code?
  • Did I upload any .env file to the repository?
  • Is my repository public?
  • Am I using a private key from the frontend?
  • Does any sensitive variable end up reaching the browser?
  • Do I know what permissions each key has?
  • Do I know whether the service can generate charges?
  • Do I have usage limits configured when the provider allows it?

You do not need to become a security specialist to start applying these practices.

What matters is developing the habit of reviewing what you are publishing.

What do I do if I already published an API Key?

If you discover that a private key was exposed, it is not enough to delete it from the file and publish again.

You must assume that someone could have copied it while it was available.

The safest option is usually:

  1. Revoke or deactivate the exposed key.
  2. Generate a new key.
  3. Update your application to use the new credential.
  4. Review the usage or activity of the previous key.
  5. Fix the way you are storing it.
  6. Verify that it no longer appears in other files or public configurations.

And there is another important detail: if a key was committed to Git, deleting it from the current file may not remove it from the repository’s history.

Building with AI also means reviewing what is behind it

Artificial intelligence tools can help you make enormous progress on a project.

But the fact that something works does not automatically mean it is ready to be published.

When your application starts handling external services, data, users, or credentials, responsibilities appear that are worth understanding.

You do not need to memorize every technical concept.

But you do need to know that an API Key can be an important credential and that copying it, pasting it, and forgetting about it is not always enough.

Before publishing, review your access.

Protect your keys.

And make sure you understand what information you are sending to the browser and what should stay behind the scenes.

Not sure if your project is exposing sensitive information?

At Stalloy we help review AI-built projects to identify keys, configurations, and other elements worth fixing before going to production.

You create. We help you take care of what’s behind it.