The public prefix means public
grep -rnE "NEXT_PUBLIC_[A-Z_]+|VITE_[A-Z_]+" app/ src/ components/ | grep -viE "url| site| ga_| pixel"grep -rlE "sk_live_| eyJ[A-Za-z0-9_-]{20, }" . next/ static/ dist/ 2>/ dev/ null
Get every Fix AI Slop Code episode
The code it wrote, the code it should have written and a check, for every episode
What is going on
NEXT_PUBLIC_ and VITE_ are build instructions. The value is inlined into the JavaScript that every visitor downloads. The model reaches for the prefix because it makes the variable "work" in the browser, which is precisely the problem.
Where it bit
Not in our repos. In the research: 39 of 50 audited apps had a secret under NEXT_PUBLIC_. Moltbook leaked 1.5 million API tokens and 35,000 emails through a Supabase key hardcoded that way, with no RLS behind it.
The practice
Only values that are safe on a billboard get the prefix. Secrets sit behind an API route. Anything already prefixed gets rotated, because it has shipped.
Get this check as a script you can run tonight
The coding agent never holds production credentials
An agent with a production database URL will sooner or later run a migration or a cleanup against it, so production secrets never enter its env
Keys go in headers, never in URLs
A URL is written to server logs, CDN logs, browser history and error trackers, so an API key in a query string is a key in five places
Backups the app cannot reach, and one restore you have actually done
A backup on the same account the app or an agent can delete from is not a backup, and a restore you have never run is a number you do not have
If this check came back with more than you expected, that is worth a conversation