Keeping API Keys Safe: The Vibecoder's Handbook Rules

How do you keep API keys and secrets safe when you're vibe coding?

Keep every secret out of your codebase from day one: store API keys, passwords, and tokens in a local .env file that your version control system never sees, read them into your code by name instead of typing them in directly, and rotate any key the instant it leaks. That is the entire discipline. It matters more when you are vibe coding because your AI agent reads, rewrites, and pastes your code constantly. A key sitting inside a file does not stay put: it ends up in chat transcripts, pull requests, shared screenshots, and every repository you ever push to.

I'm Mahmoud Zalt, an independent senior AI systems architect. I've been building and shipping production software since 2010, that's 16 years, and I founded Sista AI (sistava.com), where autonomous AI agents run in production, not in a demo video. Secrets management is one of the first things that goes wrong when people move fast with AI agents, because the agent has no instinct for what should never leave your machine. This is the short version of a rule I teach in full in The Vibecoder's Handbook.

What actually counts as a secret

Not everything in your project's settings is dangerous, and treating all of it as equally sensitive just slows you down. A secret is any value that lets someone act as you or as your app: a database password, an API key, a payment provider token, a signing key used to issue auth sessions. The test is simple. If someone getting hold of this value could spend your money, read your users' data, or impersonate your app, it is a secret. This distinction matters practically, not just theoretically. Once you can tell secret from config in a couple of seconds, you stop second-guessing every settings file and start applying the .env rule only where it actually protects you.

Everything else is plain config: a page title, a feature flag, the name of a storage bucket, a public URL. Config is safe to commit and safe to share. Secrets never are. Vibecoders get into trouble when they mix the two into one settings file and treat the whole thing as harmless because most of it happens to be.

Why a key typed into your code is already a liability

The rule professionals never break is that a secret is never written inside the code itself. It sounds obvious until you are three hours into a vibe coding session, the agent asks for an API key to test something, and pasting it straight into a file feels like the fastest way to keep moving. It is fast, and it is also the mistake that causes the most damage, because code does not stay where you wrote it.

Code gets pushed to a repository, copied to a teammate's machine, pasted into your agent's chat window as context, screenshotted for a bug report, and quoted back to you in the agent's own output. A key hardcoded anywhere in that file travels to every one of those places, and you usually will not notice until someone else does, often by draining your API credits or reading your database.

The fix is environment variables: values your app reads from its surroundings when it starts, by name, instead of having them typed into the file. Your code asks for the database password, it never states the password itself. This one habit removes almost every accidental leak before it happens.

The .env file and .gitignore, in plain English

The standard place for those values is a file named .env sitting in your project folder, one KEY=value pair per line. Your app reads this file when it starts up and loads each value into memory. Nothing about it is complicated: it is a plain text file, and the only rule is that it must never be committed to version control.

You enforce that with .gitignore, a file that tells git which files to skip entirely when you commit or push. Add .env to it once, and git will never track it, never upload it, never include it in anything you share. If you are unsure whether it is already ignored, ask your agent to check, do not guess.

One more file completes the setup: .env.example. It lists the same key names as your real .env, but with the values left blank or filled with placeholders like sk-xxxx. You commit this one. It tells anyone working on the project, including your future self reopening the repo in six months, exactly which keys the app needs without exposing a single real value.

• .env: the real secrets. Never committed.
• .gitignore: makes sure .env is never tracked.
• .env.example: the same key names, empty values. Always committed.

If a secret leaks, rotate it immediately

Secrets leak, and it happens to careful people too: a key ends up in a screenshot you shared for help, a commit you pushed before you got around to adding .gitignore, a log file you pasted into a support ticket or into your agent's chat. The moment you notice, treat that key as burned and rotate it: go to the provider, whether that's Stripe, OpenAI, your database host, or whoever issued it, generate a new key, and replace the old one everywhere it is used. Rotating instantly makes the leaked copy useless, no matter how many places it already spread to.

Watch out: deleting the line from your code does not remove the secret from your repository's history. Git keeps every version of every file it ever tracked, so a key that was committed even once, then deleted, is still sitting in your git history for anyone who clones the repo. Rotating the key is the only fix that actually works. Deleting the line and hoping is not a fix.

This is also why speed matters more than embarrassment. A rotated key costs you a few minutes of updating a config value. A leaked key that goes unrotated for a week can cost you a surprise bill, a data breach, or both.

Common mistakes vibecoders make with secrets

Most leaks trace back to a small set of repeatable mistakes, and every one of them is avoidable once you know to look for it. Watch for these:

• Pasting a key directly into a prompt or chat window "just to test something," then forgetting it is still sitting in the conversation history.
• Committing .env before adding it to .gitignore, then adding .gitignore too late; the key is already in history.
• Hardcoding a key inside client-side code, anything that ships to the browser, where anyone can open dev tools and read it.
• Reusing the same key across a personal project and a client's production system, so one leak compromises both.
• Sharing a screenshot of a terminal or config file without checking what else is visible in it.
• Never rotating a key after a contractor, teammate, or freelancer who had access moves off the project.

Do this now: the prompt that sets it up correctly

You do not need to build this by hand. Hand your agent a clear instruction and check its work. Something close to this does the job:

Act as a senior engineer setting up secret handling for
my project. Create a .env file for my stack and add it to
.gitignore so it is never committed. Create a .env.example
with the same keys but empty values. Move any keys already
sitting in my code into .env and read them from there.
Tell me what each key is for.

My stack: [describe your stack]

Read what it changes before you accept it. Confirm .env actually shows up in .gitignore, confirm .env.example has no real values in it, and confirm the keys are genuinely gone from your source files, not just duplicated. Do this once, at the start of a project, and you remove the single most common way vibecoded projects leak real credentials.

Frequently Asked Questions

Is it safe to paste an API key into an AI coding agent's chat?

Treat it as effectively public. Chat history, logs, and context windows can retain what you paste, and agents sometimes echo values back into generated code or explanations. Store the key in .env and let your agent reference it by name instead of ever seeing the raw value in chat.

What's the difference between an environment variable and a secret?

An environment variable is just the delivery mechanism, a way for your app to read a value from its surroundings at startup. A secret is a category of value, one that grants money or access if it leaks. Not every environment variable is a secret, some hold plain config, but every secret should be stored as one.

I already committed a .env file with real keys. What do I do?

Rotate every key in that file first, right away, at each provider. Then remove .env from git tracking, add it to .gitignore, and commit a .env.example instead. Deleting the file alone does not remove it from your repository's history, rotating is what actually neutralizes the leak.

Do I need a secrets manager, or is a .env file enough?

For a solo project or an early-stage product, a git-ignored .env file is enough. Dedicated secrets managers, like a cloud provider's secret store, start to earn their complexity once you have a team, multiple environments, or compliance requirements to satisfy. Start with .env, upgrade when the project actually needs it.

Can I put secrets in client-side code if I obfuscate or minify them?

No. Obfuscation and minification do not hide values, they just make them slightly more annoying to find, and a determined person needs seconds in browser dev tools. Anything that ships to the browser should be treated as fully public. Secrets belong only in server-side code, read from environment variables that never reach the client bundle.

Keep this boring, and it stays safe

None of this is exciting, and that is the point. Secrets management is not a place to be creative: put every key in a git-ignored .env file, never in your code, and rotate anything that leaks the moment you notice. Do that consistently and you remove the single most common way vibecoded projects get compromised.

This article covers the short version. The full chapter in The Vibecoder's Handbook has the exact prompt to hand your agent to set this up correctly, and walks through the rest of getting a project's setup right before you start building. Read the free chapter ->