How do you keep API keys out of a vibe-coded app?

Why is a key in front-end code public?

Front-end code is the JavaScript your site sends to every visitor's browser, and anyone can open it. Build tools copy some environment variables straight into that code, so "it was in an environment variable" does not mean it stayed private.

The Vite documentation (v8.3.4, read 16 October 2026) says variables prefixed with VITE_ "will be exposed in client-side source code after Vite bundling" and that "VITE_* variables should not contain sensitive information such as API keys. The values of these variables are bundled into your source code at build time." Next.js (page last updated 25 August 2026) does the same with the NEXT_PUBLIC_ prefix: the value is inlined "into any JavaScript sent to the browser."

This is the trap in vibe-coded apps. You ask for a page that calls an AI or payment API, the assistant makes the call from the browser because that is the shortest route, and the key goes out with the page. Simon Willison's post on vibe coding puts it plainly: if your code involves secrets, you need to understand how it works to avoid exposing them.

Which keys are safe to expose?

Some services issue two kinds of key on purpose: a public one for the browser and a secret one for the server. Stripe's API keys page (read 16 October 2026) is a clear example:

Key or variable	Safe in the browser?	Source
Stripe publishable key pk_...	Yes; it "can't perform sensitive operations such as creating charges"	Stripe docs
Stripe secret key sk_...	No; "unrestricted permissions on all Stripe APIs"	Stripe docs
Stripe restricted key rk_...	No; permissions you control, still server only	Stripe docs
Vite VITE_NAME	Only if the value is not secret	Vite docs
Vite NAME without the prefix	Not exposed to client code	Vite docs
Next.js NEXT_PUBLIC_NAME	Only if the value is not secret	Next.js docs
Next.js NAME without the prefix	Server only by default	Next.js docs

Most AI model APIs issue only secret keys. If the provider's docs do not say a key is safe to expose, treat it as secret.

How do you move the key to the server?

1. Find every key. Search the project: grep -rnE "sk_|api[_-]?key|secret|token|password" --exclude-dir=node_modules .
2. Create a server route. A small function on your host (a serverless function, which is code the host runs on request without you managing a server) receives the browser's request, adds the key, calls the API and returns only the result. In Next.js that is a Route Handler such as app/api/route.js, which can read process.env.MY_KEY.
3. Put the key in the host's secret settings, or in a local .env file for development. Stripe's advice is to use a secrets vault where your platform offers one, and environment variables if not, and not to put keys "in source code or configuration files checked into version control."
4. Ignore the env files. Add .env and .env*.local to .gitignore. Vite's docs say .env.*.local files "can contain sensitive variables" and should be ignored, and Next.js notes that create-next-app adds .env files to .gitignore for you.
5. Rebuild and check the bundle. Build the site, then search the output folder (dist/ or .next/) for the first characters of your key. No match is the result you want.
6. Limit the key. Give it the fewest permissions the job needs and a spending limit where the provider offers one, so a leak costs less.

What should you tell the assistant?

Put the rule where every session reads it, such as AGENTS.md (see what goes in a rules file):

## Secrets
- Never write an API key, token or password in code, config or tests.
- Call paid or secret-key APIs only from server code; the browser calls our own route.
- Never use the VITE_ or NEXT_PUBLIC_ prefix for a secret.
- Read secrets from environment variables and name the variable you need.

Also keep secrets out of the folders an agent can read. An assistant connected through the Filesystem MCP server can open an .env file like any other; the Filesystem sandbox thread covers that.

How do you catch a key before it is pushed?

• Push protection. GitHub's push protection docs say the feature "blocks pushes that contain secrets before they reach your repository." Push protection for users is on by default and "Stops you from pushing secrets to public repositories on GitHub." Repository-level push protection is off by default and needs GitHub Secret Protection.
• A local scanner. Gitleaks scans a repository's history with gitleaks git -v and can run as a pre-commit hook. Its README says the project is now feature complete and will get security patches only.
• Your own eyes. GitHub suggests git diff --cached to review exactly what a commit will contain, and avoiding git add . so stray files are not swept in.

The CodeLifter desk article on vibe coding security has the wider routine.

Short version

• Anything in the browser bundle is public, including VITE_ and NEXT_PUBLIC_ variables.
• Call secret-key APIs from a server route; the browser calls your route.
• Keep keys in a vault or environment variables, and .env files in .gitignore.
• Put a no-secrets rule in AGENTS.md and turn on push protection or a scanner.
• If a key was ever pushed or shipped, rotate it.