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

Is vibe coding safe?

No, not by default. Researchers audited 200 publicly deployed vibe-coded applications for a 2026 arXiv study and found at least one vulnerability in 91.0% of them, with 65.8% of the 1,186 issues they logged rated Critical or High. Vibe coding produces working software reliably and secure software only by accident.

91.0%

of 200 audited vibe-coded applications carried at least one vulnerability (Deng, Fan and Meng, arXiv 2606.23130)

11.8%

of agent solutions were secure, against 57% functionally correct (SusVibes benchmark, Carnegie Mellon and partners)

65.8%

of the 1,186 vulnerabilities in that audit were rated Critical or High severity

The audit is Understanding the (In)Security of Vibe-Coded Applications, by Junquan Deng, Zhiyu Fan and Ruijie Meng, first posted in June 2026 and last revised in September 2026. The authors collected 9,041 open-source applications built with popular agents, Claude Code and Lovable among them, then audited 200 that were publicly deployed. They trace the 1,186 findings back to eight recurring failure modes and three limitations of the agents themselves: memory defects, objective defects and knowledge defects.

The benchmark evidence points the same way. Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks, from a Carnegie Mellon led team, built SusVibes out of 186 feature-request tasks taken from real open-source projects where a human had committed a vulnerable implementation. Across 12 widely used agent settings, 57% of the solutions from SWE-Agent with Claude 4 Sonnet were functionally correct and 11.8% were secure.

So 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. Functional-looking code is precisely the kind a hurried reviewer waves through. Speed without a security control point is how you ship the flaw and the feature in the same commit.

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, the agent generates and edits the files, and you iterate by prompting again. The author of the code is the model, and the human reviews 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.

What are the security risks of vibe coding?

The risks are the OWASP Top 10 staples, reproduced faster than review can keep up. The 2026 arXiv audit found them concentrated in broken access control, injection and authentication failures. Four of these classes sit in the 2025 CWE Top 25: SQL injection at rank 2, missing authorization at 4, OS command injection at 9, unsafe deserialization at 15.

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 moves on. The same pattern repeats across every language the agent writes, which is the subject of our wider look at whether AI-generated code is safe.

One risk class does not come from the code at all. An agent reads files, dependency documentation and tool descriptions, and any of those can carry instructions aimed at the agent rather than at you. Prompt injection is LLM01, the first entry in the 2025 OWASP Top 10 for LLM Applications, and it is why step 10 of the checklist below asks what the agent ran, not only what it wrote.

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. A request to make checkout work 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.

Two mechanisms compound. The corpus problem: the model learned from public code that is full of the OWASP staples, so insecure-by-default is its prior. 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. Telling it to be careful does not fix either one. The SusVibes team tested exactly that, augmenting the feature request with vulnerability hints, and reported that the strategy did not mitigate the security issues.

A third mechanism decides the outcome, and it sits on the human side.

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.

What goes on a vibe coding security checklist?

Ten steps, ordered by payoff per hour spent. The first steps close the classes agents omit most often, according to the 2026 arXiv audit: broken access control, injection and authentication failures. The rest are the guardrails that keep the next prompt from reopening them. Run them in order on any repository an agent has touched.

1. Rotate every credential the agent could have read, then scan the history. A hardcoded key is exploitable without finding a bug, which is why it comes first. CWE-798 survives in the git history and in every fork long after you delete the line, so rotation comes before deletion, not after it.

2. Scope every data-returning endpoint to its caller. Open each generated handler and check that the lookup filters on the authenticated user, not only on an id taken from the URL. CWE-862 and CWE-639 are rank 4 and rank 24 in the 2025 CWE Top 25, and they are the flaws the agent omits most reliably because no functional test asks for them.

3. Parameterize every query and every shell call. Grep the generated files for string interpolation inside a query or a command. CWE-89 is rank 2 of the CWE Top 25 and CWE-78 is rank 9, and both are one mechanical edit away from being closed.

4. Validate every request body against a schema at the edge. Bounds, types, allowlists, rejected on failure. CWE-20 sits upstream of injection and deserialization, so closing it closes several classes at once, and it is the cheapest step on this list to automate.

5. Replace any deserializer that runs on untrusted bytes. pickle, yaml.load and native object deserializers turn a stored blob into remote code execution. CWE-502 is rank 15 of the CWE Top 25, and the safe replacement is usually a typed parser you already have.

6. Take credential stores out of the agent's reach. No plaintext credentials in the workspace it can read. Use a vault, inject at runtime, and add deny rules for .env files so the agent cannot inline what it cannot see. Rotate anything that ever appeared in a transcript.

7. Write your security rules down where the agent reads them at each edit. NIST's Secure Software Development Framework (SP 800-218, version 1.1) puts documenting security requirements in its Prepare the Organization group, before any code is produced. The next section covers what those rules should say.

8. Put a SAST gate in CI and fail the build on high severity. Functional tests pass a vulnerable but working endpoint, and only a security-aware check does not. This is detection rather than prevention, which is why it sits here and not at the top.

9. Write one abuse test per money path and per ownership path. A negative quantity, then someone else's id. Business logic flaws have no signature to match, so a test that encodes the rule is the only mechanical defense. We go deeper in business logic flaws in AI-generated code.

10. Review what the agent ran, not only what it wrote. Keep the commands it executed in a log you can read back. Destructive shell calls and ad-hoc database access against a live host never appear in a diff, so a code review alone will not surface them.

Steps 1 to 5 are remediation you can finish in an afternoon on a small repository. Steps 6 to 10 are what stop the same classes from coming back with the next prompt.

What should a vibe coding security prompt say?

It should state the rules as constraints the agent checks before writing, not as a wish. Name the query interface, the authorization helper and the input schema your codebase already uses, and tell the agent to refuse the edit if it cannot satisfy them. Rules that live outside the agent's context do not apply.

The useful form is specific and mechanical. Vague instructions ("write secure code") give the model nothing to check against. Named interfaces do.

# Security rules for this repository

- Every database read goes through `db.query(sql, params)`. Never interpolate a
  value into SQL. If you cannot parameterize it, stop and say so.
- Every handler that returns a record filters on `req.user.id`. An id taken from
  the URL is never sufficient on its own.
- Every request body is parsed by its zod schema before use. Reject on failure.
- Never write a credential into a file. Read it from the environment.
- Money is Decimal128. Quantities are integers strictly greater than zero.

Where you put that file matters more than what is in it. In CybeDefend's controlled study of 24 August 2026, which ran 30 developer tickets in triplicate for 90 autonomous runs and 93 independent security scans, the arm that kept these rules in a hand-maintained file in the repository averaged 2.27 rule deviations per rule-bearing ticket. The arm with no tool at all averaged 2.28. Writing the rules down and doing nothing else changed almost nothing. The arm that received the same rules injected at the moment of the edit averaged 0.28.

The same study is candid about the limit. On one ticket the relevant rule was served thirteen times and the agent still dismantled its own safeguards under the pressure of the task. Injection informs, it does not enforce, which is why the checklist above keeps a CI gate and a human behind it.

Does a SAST scanner catch vibe coding vulnerabilities?

Partly. A SAST scanner catches a meaningful slice, especially injection and weak crypto, and it belongs in CI on every pull request. What it misses is business logic: a negative quantity that credits the cart is syntactically perfect and has no signature to match. It also acts after the code is written.

That second limit is the structural one. SAST, secret scanners and code review all read code that already exists, and 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. The scanner becomes a historian, documenting flaws after the agent has shipped them and moved on.

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 being caught three stages later by a tool reading a diff nobody had time to read.

What should you look for in a vibe coding security tool?

Two capabilities, and most tools only have one. Detection finds known patterns in code that already exists. Prevention shapes the code as the agent writes it, by loading your rules into the agent's context before each edit. Ask a vendor when its control acts, because at agent speed that is the whole question.

The detection half is a solved market. SAST, software composition analysis and secret scanning are mature, and the established vendors in that space, Snyk, Checkmarx and Semgrep among them, do it well. What they have in common is the moment they act: in CI, on a diff, after the agent has moved on. CISA's secure-by-design guidance, Shifting the Balance of Cybersecurity Risk, published with 17 international partners, frames the test differently and better: a vendor should take ownership of customer security outcomes rather than hand the customer a list to work through.

That is the gap VibeDefend fills. It is a free npm CLI that installs with one command and wires Claude Code, Cursor, Windsurf, OpenAI Codex and GitHub Copilot into four governance layers that run inside the agent loop, so the safe version of the code is the first version. For the full picture 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 four layers map onto 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 carry the OWASP Top 10 and the compliance rule families you enable 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 before they fire; across the August study it checked 1,769 shell commands and refused 17, of which 1 was a real attempt to reach a stored credential, 3 were policy-correct and 13 were false positives costing a turn each. Live Findings wires the agent into CybeDefend's platform, with SAST carrying reachability, SCA, secrets, IaC and CI/CD running continuously, so the agent also triages and fixes the vulnerabilities you already have. As for where your code goes: the action guards decide on your laptop, before a command runs; to serve the rules that fit the line being written, VibeDefend sends a short excerpt of that code to the CybeDefend backend, and the scan before the commit sends the changed files, both in the EU or US region you pick at install. The two regions are physically separate, and your code is never used to train a model.

Measured on the same 30 tickets, the layer left 0.033 new static-analysis findings per task against 0.10 with no tool, and every one of those findings was fixed inside the task that introduced it. One honest caveat travels with that number: the study measured codebases that started clean, so it describes staying at zero, not working down a backlog you already have.

Frequently asked questions

Is vibe coding safe?

Not by default. A 2026 arXiv audit of 200 deployed vibe-coded applications found at least one vulnerability in 91.0% of them, and the SusVibes benchmark found that only 11.8% of agent solutions were secure while 57% were functionally correct. Vibe coding 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, it 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. The 2026 arXiv audit found its 1,186 findings concentrated in broken access control, injection and authentication failures. None of these are new: they are the OWASP staples, reproduced faster than review can keep up.

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

Two mechanisms compound and a third decides. 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. Then the person prompting can tell whether the feature works but often cannot tell whether it is safe, so the flaw passes review. Adding vulnerability hints to the request did not fix it in the SusVibes tests.

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 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 becomes the default the agent reaches for, so security does not rest on the prompter's ability to spot a missing authorization check.

Is vibe coding safe for a production application?

Not without the controls on the checklist above. The 2026 arXiv audit looked specifically at applications that were publicly deployed, not at toy projects, and 91.0% of the 200 it audited carried at least one vulnerability, with roughly two thirds of the findings rated Critical or High. Production raises the stakes on exactly the classes agents omit: an unscoped endpoint exposes real customer records, and a hardcoded key in a public repo is exploitable the moment it is pushed.

Does a SAST scanner catch vibe coding vulnerabilities?

It catches a meaningful slice, especially injection and weak crypto, and it belongs in CI on every pull request. What it largely misses is business logic, 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. In CybeDefend's controlled study, rules kept in a repository file left 2.27 deviations per rule-bearing ticket against 2.28 with no tool at all, while the same rules injected at the moment of the edit left 0.28. Everything else is defense in depth behind that.

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

Start with steps 1 to 3 of the checklist above: rotate any credential the agent could have read and scan the history for more, then audit every data-returning endpoint for a caller-scoped authorization check, then close the injection points. Add a SAST gate to CI that fails on high severity, and put an agent-time layer in front so new code is governed as it is written. Stop adding flaws first, then work down the backlog the early prompts left behind.