TL;DR
- AI editors keep hardcoding API keys and secrets directly into source files
- That single pattern is an automatic fail on SOC 2, PCI-DSS, and HIPAA reviews
- Solo founders and small teams now get enterprise security questionnaires before they've ever hired a security person, and this is the first thing reviewers grep for
A solo founder I've been advising pinged me two weeks before his first SOC 2 readiness review. He'd built his entire product in Cursor over four months, shipping fast, iterating with customers, doing exactly what you're supposed to do at that stage. He asked me to sanity-check the codebase before the auditor did.
Ten minutes in, I found a Stripe secret key sitting in a config file that had been committed to the repo since month one. Not in an env file. Not in a secrets manager. Just sitting there in plaintext, referenced directly by three different services.
This wasn't sloppy work. He's a good engineer. It's just that when you're one person shipping a product solo, you're leaning on the AI editor to move fast, and the AI editor doesn't know your repo is about to be audited.
The Pattern
Ask Cursor, Claude Code, or Copilot to wire up a new API integration, and you'll frequently get something like this:
const STRIPE_SECRET = 'sk_live_51H8xK2eZvKYlo2C...'; // ❌
const client = new Stripe(STRIPE_SECRET);
instead of:
const STRIPE_SECRET = process.env.STRIPE_SECRET_KEY; // ✅
const client = new Stripe(STRIPE_SECRET);
CWE-798, Use of Hard-coded Credentials. It's one of the oldest, most well-documented vulnerability classes there is, and AI editors reproduce it constantly.
Why This Keeps Happening
Every tutorial you've ever read that shows "how to connect to Stripe in 5 minutes" hardcodes the key inline, because pulling in dotenv and explaining environment variables breaks the flow of a blog post. That's the training data. The model learned "working example" from thousands of docs that optimized for readability over security, and it reproduces that pattern by default unless you tell it not to.
Here's the part that matters if you're small: compliance frameworks don't care about intent. SOC 2's CC6.1 control is explicit about protecting access credentials. PCI-DSS 8.2.1 requires cryptographic material to never be stored in plaintext. HIPAA's 164.312 technical safeguards require the same for anything touching PHI. A single hardcoded key in git history is enough for an auditor to flag the entire control as failed, and rewriting git history to purge a leaked secret is its own multi-hour headache.
Enterprise customers now push this requirement down to vendors of any size. If you're a two-person startup trying to close a deal with a company that has an actual security team, you're getting a vendor security questionnaire, and "do you store credentials in plaintext" is question one.
The Fix
Move every secret to environment variables and a .env file that's git-ignored from day one:
echo ".env" >> .gitignore
// .env (never committed)
STRIPE_SECRET_KEY=sk_live_...
JWT_SECRET=...
// app code
const STRIPE_SECRET = process.env.STRIPE_SECRET_KEY;
If a secret already made it into git history, rotate it immediately, then scrub the history with git filter-repo or BFG Repo-Cleaner. Rotating the key matters more than cleaning history. History cleanup doesn't undo exposure if the key is already live.
For anything beyond a single developer, a proper secrets manager (AWS Secrets Manager, Doppler, Infisical) beats .env files long-term, but .env + gitignore is the floor, not the ceiling.
I've been running SafeWeave for this specifically because it ships with SOC 2, PCI-DSS, and HIPAA compliance profiles out of the box, which matters if you're a solo founder or a five-person team trying to pass an enterprise security review without a dedicated compliance hire. It hooks into Cursor and Claude Code as an MCP server and flags hardcoded secrets before I move on to the next file. That said, even a basic pre-commit hook with gitleaks will catch most of what's in this post. The important thing is catching it before it ships, whatever tool you use.
Top comments (1)
Hardcoded secrets are a good example of AI code passing the demo and failing the organization. The fix is not just “tell the model not to.” The environment needs secret scanning, review gates, and examples where unsafe convenience is explicitly rejected.