239 model keys behind one hardcoded variable
The sharpest example in the LLM security report: a product hardcoded cloud API keys for 239 models in its frontend. Key leaks are not new, but LLMs amplify them — one key is a whole fleet of models and a bill.
Figure: gitleaks README (source: github.com/gitleaks/gitleaks, captured 2026-10-19)
The pattern is old: a developer needs the key in the browser, so it goes into the bundle. What changed is the blast radius. One key now reaches 239 models, and the bill is yours.
How keys end up in the frontend
Environment variables are inlined at build time; a “public” prefix is a suggestion, not a boundary. Anything in the bundle is public.
Scan your repos first
gitleaks detect --source . --verbose
trufflehog filesystem . --only-verifiedRun them in CI, not just locally.
What good key management looks like
- Keys live server-side only.
- One key per service, with scoped permissions.
- Short expiry where possible.
- Rotation is automated, not a calendar reminder.
After a leak
- Revoke the key.
- Rotate dependent keys.
- Check the provider’s usage logs.
- Add the pattern to secret scanning.
- Tell users if their data was reachable.
Why LLMs make it worse
A model key can spend money, call tools, and read data. A leaked map key shows a map; a leaked model key runs your product.
Finding keys in a bundle
Search for provider prefixes, long base64 strings, and sk- patterns. Minified code hides them but does not remove them.
Secret scanning in CI
Enable provider scanning plus a custom pattern for your own prefixes. Block the merge, not the deploy.
Rotate automatically
Rotation that depends on a human happens after the incident. Automate it and test it.
Do the math
One leaked key can burn a month of budget in hours. The cost of a secret manager is smaller.
Common mistakes
- Believing a public prefix makes a key safe.
- Rotating only the leaked key.
- Not checking provider logs.
My take
The frontend is public. Treat every byte shipped to the browser as published.
Comments
…