How to Secure AI-Generated Code: The Vibe-Coding Security Checklist

Most of the code shipping in 2026 wasn't typed by a human. It was generated by an agent — Claude Code, Cursor, Copilot, v0 — from a prompt, reviewed at a glance, and merged. "Vibe coding," where you describe the outcome and let the agent write it, has gone from a meme to how a lot of real products get built.

The productivity is real. So is the security debt. AI agents are excellent at producing code that works and quietly average at producing code that's safe — and they do it at a speed and scale no human reviewer keeps up with. This is a practical checklist for securing AI-generated and vibe-coded apps, including the neat trick of using an AI agent to audit its own output.

Why AI-generated code fails differently

AI-generated code isn't uniquely bad. It fails in specific, predictable ways:

• It reproduces the patterns in its training data — including the insecure ones. There are more string-concatenated SQL queries on the internet than parameterized ones, so that's often what you get unless you ask otherwise.
• It optimizes for "works," not "safe." The happy path runs, the demo passes, and the missing authorization check doesn't show up until someone changes an ID in the URL.
• It fails at scale and consistently. When an agent scaffolds twenty endpoints, it tends to make the same omission on all twenty. One review miss becomes twenty vulnerabilities.
• It looks right. This is the real danger. Insecure AI code is plausible. It reads like competent code, so it slides through review in a way that obviously-sketchy code wouldn't.

The upshot: you can't eyeball your way to confidence. You need a structured audit.

The vibe-coding security checklist

Here's what to check in any AI-generated codebase, in rough priority order. Each maps to a free threat-modeling prompt you can run with your agent (more on that below).

1. Authorization on every data endpoint

The single most common AI-generated flaw: an endpoint takes an object ID and returns the object without checking the caller owns it (BOLA/IDOR). Check that every route reading an ID also filters by the current user or tenant. → authorization, API security

2. Injection sinks

Look for string-built SQL, exec/child_process with user input, template rendering from user data, and file paths built from request params. Agents produce these constantly. → injection

3. Hardcoded secrets

Agents love to inline an API key "to make it work." Grep your repo and your git history for keys, tokens, and connection strings — and rotate anything you find. → secret & API-key hygiene

4. Authentication and sessions

Rate limits on login, secure session cookie flags, single-use password-reset tokens, MFA that can't be skipped. Generated auth flows are often missing the boring-but-critical protections. → authentication

5. CORS and CSP

Agents reach for Access-Control-Allow-Origin: * and skip Content-Security-Policy because it's the fastest way to stop the browser complaining. Both are security holes. → XSS / CSRF / CORS

6. Rate limits and resource caps

Unbounded queries, no pagination limits, no throttling — the ingredients for denial-of-service and denial-of-wallet. → rate limits & abuse

7. Dependencies the agent added

Every package an agent npm installs is supply-chain surface. Check for unpinned versions, known CVEs, and typosquatted names. → supply chain & CI/CD

8. LLM-feature risks (if your app uses AI)

If your generated app itself calls an LLM, you've inherited a new attack surface: prompt injection, insecure output handling, and denial-of-wallet. → AI / LLM features

Use an AI agent to audit its own output

Here's the leverage: the same kind of agent that wrote the code is very good at auditing it — as long as you give it a structured prompt instead of "is this secure?"

The workflow:

npm install securenow

Go to /threat-modeling, copy the prompt for a category from the checklist above, and paste it into your agent opened at your project root. It reads your generated code, enumerates the threats, and writes a report with every weakness pinned to a file:line, plus the runtime detections to catch exploitation. It runs locally — your code never leaves your machine — and it's free.

Do this one category at a time, starting with authorization and injection (the two that bite vibe-coded apps hardest). For the full walkthrough, follow the AI Security Auditing series or read the overview, how to audit your app's security with AI.

Make it a habit, not a one-off

The reason AI-generated code accumulates security debt is that generation is continuous and review isn't. Close that gap:

• Audit before you ship, category by category, not just once at the end.
• Re-audit the category you touched whenever the agent generates new code in it.
• Wire it into CI — the prompts are free and local, so a category audit on every pull request costs nothing but a little time.
• Turn the findings into runtime detections so exploitation attempts get caught even on the code you haven't re-audited yet. (Part 5 of the series shows how.)

The bottom line

Vibe coding isn't going away, and it shouldn't — it's too productive. But "the agent wrote it and it works" is not the same as "it's safe." Insecure AI code is plausible code, which is exactly why it needs a structured audit rather than a glance. The good news is that the audit is now as fast and cheap as the generation: point an agent at your code, one threat category at a time, and let it find what it — or another agent — missed.

Start with the free threat-modeling prompts →