Vibe Coding and API Keys: How to Keep Secrets Out of the Chat and the Repo

In the repository. The agent writes the key into a config file so the code runs. You commit. If the repository is on GitHub, anyone who can see it, including a contractor you add next year, has your backend. If the repository is public, automated scanners find the key in minutes.

In the chat. You paste the token into the conversation to "just make it work". It is now in the session history, in every export of that session, and in whatever the agent's provider retains under your plan. You cannot un-paste it.

Neither of these feels like a mistake at the time, because the integration works. That is the problem: the failure is silent.

Four rules. They take ten minutes to set up and they hold for the life of the project.

Keep secrets in an environment file the repository ignores. One file, listed in the repository's ignore list before the first key goes in it. The code reads keys from there by name.

Give the agent the name, never the value. The agent needs to know that a variable called, say, the backend key exists and where the code reads it from. It does not need the key itself to write that code. When it asks for the value, do not paste it; tell it the value is set in the environment.

Manage the backend-to-app connection outside the chat. Creating the project on your backend provider, generating keys, setting what an anonymous user can read and what a logged-in user can write: do this in the provider's dashboard, in your own account, not by pasting dashboard screenshots and tokens into the agent.

Ask the agent for the safe setup before the integration. One prompt, before any backend code: "Before we integrate the backend, tell me how to keep the keys out of the repository and out of this conversation, and set that up first." The agent knows the answer. It will not volunteer it unless you ask.

Backend providers give you two kinds of key, and mixing them up is the second silent failure.

A client key (Firebase's web config, Supabase's anon key) is designed to ship inside the app. Anyone who unpacks your app can read it, and that is fine, because what it can do is limited by the rules you set in the provider's dashboard. Those rules are your real security boundary. An app shipped with a client key and no rules is an app where every user can read every other user's data.

A server key (a service-role key, an admin key) bypasses those rules. It never goes in the app, never goes in the repository, never goes in the chat. If an agent suggests putting one in the app "to make the query work", that is the moment to stop and ask why the rules are blocking the query instead.

A developer who has done this before knows which key is which and where each one lives. The agent will do whatever gets the build green, and "paste the admin key into the app" gets the build green. The person who has to know the difference is you, and the whole point of this piece is that you can, with four rules and one prompt.

The same applies to any tool that runs an agent on your behalf. Whatever you build in, your backend stays under your own account, with your own keys, and the rules you set in its dashboard are what protect your users. Cheapest way to build a mobile app covers why the backend costs the same in every tool; the security setup is the same in every tool too.