I asked Cursor to wire up Stripe billing for a side project last week. It gave me working code in about ten seconds. It also gave me this:
const stripe = require('stripe')('sk_live_51Abc...realkey...xyz');
const JWT_SECRET = 'super-secret-key-change-me';
The code ran. Payments worked. And I almost committed a live Stripe key to a public GitHub repo without noticing, because everything looked fine.
This is not a Cursor problem specifically. Claude Code, Copilot, and Windsurf all do it. The pattern is everywhere in the training data, so the model reproduces it.
Here is the kind of thing AI editors generate constantly:
// Hardcoded secret - CWE-798
const stripe = require('stripe')('sk_live_51Abc...xyz');
const JWT_SECRET = 'super-secret-key-change-me';
const DB_URL = 'postgres://admin:hunter2@db.prod.internal:5432/app';
Three secrets, three liabilities. Once this hits a repo, the secret is in your git history forever, even if you delete the line in a later commit. Public repos get scraped by bots within minutes. There are reports of freshly committed AWS keys getting used by attackers in under five minutes.
LLMs learn from public code: tutorials, StackOverflow answers, sample apps. A huge amount of that code hardcodes secrets because it is meant to be illustrative, not production-ready. The model has no concept of "this value is sensitive." To it, the key string is just an argument like any other.
The model also optimizes for code that runs immediately. Reading from process.env requires the developer to set up a .env file first, so the path of least resistance for a working snippet is to inline the value.
Move every secret to an environment variable and load it at runtime:
// Secrets from environment - CWE-798 resolved
const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY);
const JWT_SECRET = process.env.JWT_SECRET;
const DB_URL = process.env.DATABASE_URL;
Then keep the file out of git and scan before committing:
echo ".env" >> .gitignore
npx gitleaks detect --source . --verbose
If a secret already made it into git history, changing the code is not enough. Rotate the key at the provider immediately, then scrub history with git filter-repo or BFG. Assume any committed secret is already burned.
A pre-commit hook is the real win here. The goal is to never let a secret reach a commit in the first place, because cleanup after the fact is painful and rotation is the only safe assumption.
I have been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and flags hardcoded secrets the moment the code is generated, before I move on to the next prompt. Its secrets scanner is built on Gitleaks and runs on the free tier with no signup. That said, even a plain pre-commit hook with gitleaks will catch most of what is in this post. The important thing is catching secrets early, whatever tool you use.