The Vibe Coder's Security Checklist: 5 Ways Your AI IDE Is Leaking Secret Keys
Your agent can ship a Stripe secret to public GitHub in one confident commit. Local hygiene is not enough — you need merge-gate checks on every pull request.
A founder pasted a Stripe live secret into Cursor, asked the agent to wire up checkout, and merged the pull request before lunch. The diff looked clean. The tests passed. Two hours later, GitHub Secret Scanning emailed about a live key in a public repository. The agent had not "forgotten" the secret — it had done exactly what vibe coding rewards: move fast, commit the working path, and ship.
This is a merge-gate problem, not a vibes problem
Most secret-leak advice still sounds like personal hygiene: do not paste keys into chat, rotate after exposure, use a password manager. That advice is true and insufficient. Agent mode generates hundreds of lines per session, reads files you did not mean to share, and commits with the same confidence whether it is renaming a component or embedding `sk_live_` in a config stub. Individual developers cannot reliably eyeball every token-shaped string in a 2,000-line diff.
Mature teams already run gitleaks or GitHub Advanced Security on the default branch. That catches disasters after merge. The gap is the pull request: the only place where you can reject a leak before it becomes permanent history, forkable code, and searchable CI output. Secure AI coding means the merge gate inspects agent output the same way it inspects human output — with automated secret detection on the diff, not a hope that someone noticed the key in line 847.
Five ways your AI IDE leaks secret keys
Each row is a failure mode we see in real agent-written pull requests. Treat the merge-gate column as required, not optional.
| Leak path | How it happens | Merge gate |
|---|---|---|
| 1. Hardcoded keys in diffs | The model inlines `process.env.STRIPE_SECRET` as a string literal because the local run failed without it, or it "temporarily" hardcodes a test key that is actually live. | Run gitleaks (or equivalent) on the PR diff only. Block merge on any high-confidence secret match — no "I will fix in a follow-up." |
| 2. `.env` in model context | You opened `.env` to copy one variable. The IDE indexed it, the agent read it, and now the key lives in chat logs, suggested edits, or a committed `.env.example` that is too faithful to the original. | Keep `.env` out of agent context entirely. Use `.cursorignore` and never `@`-mention env files. Scan for accidental `.env` commits and env-shaped strings in examples. |
| 3. Agent mode bypasses `.cursorignore` | Ignore rules protect some tools, not all agent paths. Terminal commands, broad repo search, and "read the config that makes this work" can still pull secrets from paths you thought were excluded. | Treat ignore files as necessary, not sufficient. Add PR-level secret scanning because agents can reach files your local ignore list never anticipated. |
| 4. `NEXT_PUBLIC_` client bundling | Next.js inlines `NEXT_PUBLIC_*` into the browser bundle. Agents often "fix" missing env errors by prefixing secrets — turning a server key into public JavaScript anyone can read from `_next/static`. | Block new `NEXT_PUBLIC_` variables without owner review. Flag any PR that moves server-only keys into client-accessible names or config. |
| 5. Git history and CI logs | Even after you delete the key from HEAD, it remains in commits, fork clones, and CI logs that printed env vars for debugging. Agents love adding `console.log(process.env)` when tracing failures. | Scan diffs before merge. Rotate any exposed credential immediately. Never log raw env in CI — and review agent-added debug statements as secret-bearing code. |
Rotation alone does not undo public git history. Prevention at the PR boundary is cheaper than incident response.
What to run on every agent-written pull request
- 1Does the diff introduce any new string that looks like a credential?Run gitleaks or GitHub secret scanning on the PR patch, not just the default branch. High-confidence matches should fail the check before a human approves.
- 2Did the agent touch env files, config, or `NEXT_PUBLIC_` names?Require explicit review for `.env*`, `*.local`, deployment manifests, and any rename that moves values into client bundles. Agents treat visibility as correctness.
- 3Could model context have included live secrets?If `.env` or production config was in chat or agent context during the session, assume compromise: rotate affected keys even if the diff looks clean.
- 4Will CI or tests print sensitive values?Reject new logging of env objects, debug dumps, or "temporary" test harnesses that echo secrets into GitHub Actions output.
- 5Who owns the merge decision when checks fail?Automated scanners catch patterns; a human owner decides rotation scope and whether an agent session contaminated other branches or forks.
Where Critique fits
Critique reviews pull requests where agent speed makes manual diff review unreliable. It inspects the change in repository context, surfaces security findings with evidence, and fits into the same GitHub workflow as gitleaks — except the review also catches the adjacent mistakes agents make around secrets: unsafe env handling, client-exposed keys, and debug logging that turns CI into a leak channel. Pair deterministic secret scanning with repo-aware review so the merge gate catches both the literal key and the path that put it there.
FAQ
Catch secret leaks before they hit main
Install Critique on GitHub, run it on your next agent-written PR, and pair it with gitleaks on the diff so merge gates block keys — not just regret.
Start free