Vibe Coding Security: The Risks You Ship With, and How to Catch Them

What is vibe coding?

Vibe coding is building software by prompting an AI agent in natural language instead of writing the code yourself. You describe the outcome ("add a checkout endpoint that charges the saved card"), the agent generates and edits the files, and you iterate by prompting again. The shift is that the author of the code is now the model, and the human is the reviewer of an output they often cannot fully read.

The term spread in early 2025 to describe a workflow where a developer, or increasingly a non-developer, leans into the agent and accepts what it produces as long as the result behaves. Tools like Claude Code, Cursor, Windsurf, OpenAI Codex and GitHub Copilot made it practical: they index a repository, edit across the tree, run commands, and produce functional features from a paragraph of intent. That is genuinely powerful. It is also where the security gap opens, because the speed that makes vibe coding attractive is the same speed that buries flaws.

Is vibe coding safe?

Vibe coding is safe for the things software has always been safe at by accident, and unsafe at exactly the things that require judgment a prompt does not carry. The agent reliably produces code that compiles and passes the happy path. It does not reliably produce code that resists an attacker, because security is an absence (of a missing check, of an unescaped input) that a "make it work" prompt never asks for.

The honest answer is that vibe coding is as safe as the controls around it, and most vibe-coding setups have none that act before the code lands. The model learned from a public corpus full of insecure patterns, so it reproduces them at machine speed. Independent testing keeps landing in the same place: a large share of AI-generated code fails security tests even when it is functionally correct, and the gap between "works" and "safe" is where the breach lives.

45%

of AI-generated code fails security tests (Veracode 2025)

10.5%

of AI coding-agent solutions were secure, vs 61% functionally correct (Carnegie Mellon SusVibes)

#1

prompt injection, the top LLM risk for the 3rd year running (OWASP LLM01)

The takeaway is not "do not vibe code." It is that functional-looking code is precisely the kind a hurried reviewer waves through, and that over 80% of functionally correct AI solutions in the Carnegie Mellon SusVibes benchmark still carried a vulnerability. Speed without a security control point is how you ship the flaw and the feature in the same commit.

What are the security risks of vibe coding?

The risks are not new vulnerability types. They are the OWASP Top 10 staples, reproduced faster than review can keep up, because the model writes the common pattern and the common pattern is often the insecure one. Here are the classes that recur, each anchored to its CWE.

Two of these deserve a closer look, because they show how ordinary the generated code is. Injection first. Ask for "a search endpoint that filters users by name" and the path of least resistance is concatenation.

# Vulnerable (CWE-89): user input concatenated into SQL
q = f"SELECT * FROM users WHERE name = '{name}'"
db.execute(q)

# Fixed: parameterized query, input never becomes code
db.execute("SELECT * FROM users WHERE name = %s", (name,))

Broken authorization is subtler, because the vulnerable version looks complete. It returns the right shape, passes the test that asks for "get order 42," and ships.

// Vulnerable (CWE-639 IDOR): any logged-in user reads any order
app.get('/orders/:id', auth, async (req, res) => {
  const order = await Order.findById(req.params.id)
  res.json(order)
})

// Fixed: scope the lookup to the caller who owns it
app.get('/orders/:id', auth, async (req, res) => {
  const order = await Order.findOne({ _id: req.params.id, userId: req.user.id })
  if (!order) return res.status(404).end()
  res.json(order)
})

The difference between the two versions is one clause. A reviewer reading 5,000 lines a day does not see the missing clause; they see an endpoint that returns an order and move on.

Why does vibe coding produce these flaws?

Because the prompt optimizes for behavior and the model optimizes for the most common pattern, and neither is the same as security. "Make the checkout work" is a functional spec. It contains no instruction to validate input, scope authorization, or parameterize a query, so the agent fills the gap with whatever its training corpus made statistically likely, which is frequently the insecure version.

There are three compounding reasons. First, the corpus problem: the model learned from public code that is full of the OWASP staples, so insecure-by-default is its prior. Second, the absence problem: security is usually a check that is present, and a model asked for a positive outcome does not add a negative guard nobody requested. Third, and most decisive, the reader problem.

“

The person prompting can tell whether the feature works. They usually cannot tell whether it is safe. That gap, between the author's intent and the reviewer's ability, is the whole security problem.

This is why vibe coding is structurally different from a junior developer writing the same code. The junior is slow enough that review keeps pace, and the reviewer is reading code a human wrote at human speed. Vibe coding removes both brakes: the output arrives at machine speed, and the person responsible for it often lacks the security literacy to evaluate it. The pull request, the place AppSec has always lived, becomes a transcript of decisions already made rather than a checkpoint.

How do you do secure vibe coding?

Secure vibe coding means putting a security control where the code is actually authored, which is the prompt, not the pull request. You keep the speed and add a layer that shapes what the agent writes before it writes it, plus the usual independent validation behind it. The principles below are what separate "we vibe code" from "we vibe code safely."

1. Give the agent the rules at prompt time. The model cannot follow a standard it never sees. Load your security requirements (parameterize queries, scope every lookup to the caller, never inline a secret) into the agent's context before each edit, so the safe pattern is the default it reaches for, not an afterthought a scanner flags later.

2. Keep secrets out of reach entirely. No plaintext credentials in the workspace the agent can read. Use a vault, inject at runtime, and add deny rules for .env files and credential stores so the agent cannot inline (CWE-798) what it cannot see. Rotate anything that ever appears in a transcript.

3. Treat every generated endpoint as unauthorized until proven otherwise. The single most valuable review habit for vibe-coded code is checking that each data-returning path scopes to the caller. Authorization (CWE-862, CWE-639) is the flaw the agent omits most reliably and the one no test catches.

4. Validate input as a hard requirement, not a nice-to-have. Require bounds, types and allowlists on every generated handler. CWE-20 is upstream of injection and deserialization, so closing it closes several classes at once.

5. Keep a human in the loop, and a SAST gate behind them. Route generated code through review with extra scrutiny on auth, queries and validation, and fail the build on high-severity findings. Functional tests pass a vulnerable-but-working endpoint; only a security-aware check does not.

6. Watch for business logic flaws explicitly. Scanners do not catch a negative-quantity discount or a stacked coupon. Mine the conventions your own code already encodes (money is Decimal128, refunds go through requireOwner) and enforce them as the agent writes. We go deep on this in business logic flaws in AI-generated code.

The pattern across all six is the same: stop relying on a control that arrives after the code is on disk, and move it to the moment the code is written.

Where scanning falls short: agent-time enforcement

Walk back through the risk classes and a single weakness in the standard approach stands out. SAST, secret scanners and code review all act on code that already exists. They cluster around the pull request, because that is where AppSec has always lived. But the PR was only ever a control point because a human read it, and at vibe-coding cadence nobody reads it end to end anymore. The scanner becomes a historian, documenting flaws after the agent has shipped them and moved on.

The place to enforce a rule is the prompt, before the unsafe line is written. Whatever rule you want the agent to follow has to be in its hands at the moment it writes, not waiting in a tool that arrives once the code is on disk.

Read the right column as the goal. Scanning is not wrong; it is late. Agent-time enforcement does not replace the scanner, the review or the CI gate. It puts a control in front of all of them, so the insecure line is rewritten before it is ever suggested, instead of caught three stages later by a tool reading a diff nobody had time to read.

What tools catch vibe coding vulnerabilities?

You need two kinds of control, and most teams only have one. The familiar kind is detection: SAST for injection and weak crypto, software composition analysis for vulnerable dependencies, and secret scanning for credentials in history. These are necessary, and they belong in CI on every pull request. They are also reactive, and at vibe-coding speed they arrive after the flaw has shipped.

The kind most setups are missing is prevention at the point of authorship: a layer that lives in the agent loop and shapes the code as it is written. That is the gap VibeDefend fills. It is a free npm CLI that installs in about five seconds and wires Claude Code, Cursor, Windsurf, OpenAI Codex and GitHub Copilot into three governance layers that run inside the agent loop, so the safe version of the code is the first version. For the full picture of how this sits across every AI coding agent, see our pillar on AI coding agent security.

npx -y @cybedefend/vibedefend@latest installPick EU or US, confirm your agentDrop .cybedefend/config.json in the repoNext prompt is governed

The three layers handle the failure modes this guide named. Business Rules are the conventions mined from your own repo (money is Decimal128, authorization goes through requireOwner), loaded into the agent before each edit so business logic flaws never get written. Security Rules bring OWASP Top 10, SOC 2, GDPR and ISO 27001 into the code as it is written, so injection, missing validation and broken authorization meet a rule at authorship instead of an audit-time checkbox. Action Guard intercepts destructive calls (a sudo rm -rf, a raw read of a secret-shaped env var, an ad-hoc psql against a production host) before they fire, warning or blocking per rule with every interception in the audit trail. Crucially, nothing about your code crosses the wire: decisions happen locally next to the agent, and only structured governance metadata (the rule that fired, the file path, the severity, a timestamp) reaches the backend. EU and US tenants are physically separate, and you pick the region at install time, so the control sits this close to the code without becoming a data-exfiltration risk of its own.

Frequently asked questions

Is vibe coding safe?

Vibe coding is safe for producing working software and unreliable at producing secure software, because a "make it work" prompt never asks for the missing security check. Independent testing keeps finding that a large share of AI-generated code fails security tests even when it is functionally correct. It becomes safe to do when you add a control that acts at authorship time, give the agent your security rules in its context, keep a human in the loop, and gate pull requests with SAST. Without those, vibe coding ships the OWASP Top 10 at machine speed.

What are the most common vibe coding vulnerabilities?

The recurring classes are hardcoded secrets (CWE-798), broken authorization and IDOR (CWE-862, CWE-639), injection (CWE-89 for SQL, CWE-78 for commands), missing input validation (CWE-20), insecure deserialization (CWE-502), and business logic flaws. None are new. They are the OWASP staples, reproduced faster than review can keep up, because the model writes the most common pattern and the most common pattern is frequently the insecure one.

Why does AI-generated code have so many security flaws?

Three reasons compound. The model learned from a public corpus full of insecure patterns, so insecure-by-default is its prior. Security is usually a guard that is present, and a model asked for a positive outcome does not add a negative check nobody requested. And the person prompting can tell whether the feature works but often cannot tell whether it is safe, so the flaw passes review. The result is functional-looking code that ships the vulnerability with the feature.

Can a non-developer vibe code securely?

Only with a control that does not depend on the person reading the security implications, because that is exactly the skill a non-developer lacks. A linter or a scanner that produces findings to triage assumes the reader can interpret them. An agent-time layer that loads the rules into the agent and rewrites the unsafe line before it lands removes that dependency: the safe pattern is the default the agent reaches for, so security does not rest on the prompter's ability to spot a missing authorization check.

How is vibe coding different from using an autocomplete like old Copilot?

Old autocomplete suggested a block of code a human chose to accept; the blast radius was one snippet a developer still had to paste in. Vibe coding lets the agent take actions: it edits across the tree, runs commands, and ships functional features from a paragraph of intent, at a volume no reviewer can read. The security model has to move from reviewing a draft a human accepts to constraining and shaping what an agent writes in the first place.

Does a SAST scanner catch vibe coding vulnerabilities?

A SAST scanner catches a meaningful slice of them, especially injection and weak crypto, and it belongs in CI on every pull request. What it largely misses is business logic flaws, because a negative-quantity discount or a refund that skips the ownership check is syntactically perfect and semantically wrong, with no signature to match. It is also reactive: it acts after the code is written, which at vibe-coding speed means after the flaw has shipped. Pair detection in CI with prevention at authorship time.

What is the single most effective control for secure vibe coding?

Moving the security control point from the pull request to the prompt. Detection that runs after the code exists is always reading history at agent cadence, because nobody reviews thousands of generated lines end to end. A layer that loads your security and business rules into the agent before each edit, and rewrites the unsafe line before it lands, prevents the flaw instead of finding it later. Everything else (SAST, review, CI gates) is defense in depth behind that.

Where do I start securing an existing vibe-coded project?

Start by closing the two classes the agent omits most: scan history for hardcoded secrets and rotate anything exposed, then audit every data-returning endpoint for a caller-scoped authorization check. Add a SAST gate to CI that fails on high-severity findings, and put an agent-time layer like VibeDefend in front so new code is governed as it is written. The goal is to stop adding flaws first, then work down the backlog the early prompts left behind.