How to Protect API Keys When Vibe Coding

AI-assisted coding makes it quick to connect an app to an API, but it can also make it easy to paste a credential into source code, prompts, a browser bundle, or a public GitHub repository. Protect API keys by keeping privileged credentials on the server, storing them in an approved secret manager, and checking every change before it is committed or deployed.

Know what must stay secret

API keys, access tokens, database passwords, signing keys, and private certificates can grant access to data or services. Treat credentials as secrets unless the issuing provider explicitly documents them as public. Some products issue separate public and secret keys; a key intended for browser use may still need domain, scope, or quota restrictions.

A value is not protected merely because its variable name sounds private. If code ships to a browser, its bundled values can be inspected by users. Keep privileged keys in server-only code and make the client call your backend when it needs an operation that requires that key.

Use local environment variables without committing them

Follow the framework and provider documentation for loading environment variables. A common pattern is to store local values in a file such as .env.local, read them through the server-side runtime, and keep that file out of Git. Add the precise local file name to .gitignore:

.env
.env.*
!.env.example

This is only an example pattern. Check your project's existing .gitignore and keep a placeholder template such as .env.example free of real values. Ignore rules do not untrack a file already committed, so check the repository before pushing:

git status --short
git check-ignore -v .env.local

Never paste live credentials into an AI prompt

When asking an AI tool to integrate an API, describe the variable name and expected behavior rather than sharing the real key. For example, ask it to read a server-side environment variable and explain how to configure that variable locally. Review the generated code to ensure the secret is not printed in logs, returned in API responses, committed to a test fixture, or exposed through client-side configuration.

Configure secrets separately for deployment

Add production credentials in your hosting platform's environment settings or approved secret manager—not in GitHub source files. Limit each key to the permissions, services, and environments it actually needs. Use separate credentials for local development, staging, and production when the provider supports it, and restrict spending or usage where possible.

CI workflows can access secrets only through the platform's protected secret settings. Avoid printing secrets in workflow output or exposing them to untrusted pull request code. Review which branches and jobs can access each credential.

Review for accidental exposure before pushing

Before you commit AI-generated changes, inspect the files and staged diff:

git status --short
git diff
git diff --cached

Look for credentials in source, configuration, logs, screenshots, and example requests. Automated secret scanning can catch some mistakes, but it does not replace careful review or guarantee that every secret is detected.

If a key has already been exposed

Treat a committed or shared key as compromised. Revoke or rotate it with its provider first, check for unexpected use, then remove the value from the current code and replace it with secure configuration. Deleting the line or file does not erase it from Git history or make the old key safe. Follow these steps for an API key exposed on GitHub and coordinate history cleanup with anyone using the repository.