Vibe coding turns natural-language prompts into running software faster than most organisations can review it, and the security gaps it creates are predictable. Collins Dictionary, which named the term its Word of the Year 2025 and credits Andrej Karpathy with it, describes it as using AI prompted by natural language to write computer code. This list ranks the ten risks we see most often when developers, product teams and non-developers ship AI-generated code, what each looks like in practice and the first control to put in place. It is written for AppSec leads, platform teams and anyone approving AI coding tools. For the full control set, see the Vibe Coding Security Guide.
The Top 10 at a glance
The table ranks the ten security risks that vibe coding most often introduces, what goes wrong in each case and the first control that reduces it. Each risk is explained in its own section below, with detection signals and fixes.
| # | Risk | Typical weakness | First control |
|---|---|---|---|
| 1 | Insecure code accepted without reading it | CWE-79, CWE-89, CWE-78 | SAST and a human review gate on every merge |
| 2 | Missing authorisation and open backends | CWE-862, CWE-306 | Deny-by-default data access, tested before release |
| 3 | Hard-coded and client-side secrets | CWE-798 | Secret scanning with push protection |
| 4 | Hallucinated and unvetted dependencies | Slopsquatting | Internal registry proxy and new-package review |
| 5 | Coding agents with production access | Excessive agency | Separate dev and prod credentials |
| 6 | Poisoned instructions and repository content | Indirect prompt injection | Treat instruction files as code, with owners |
| 7 | No provenance for AI-generated changes | Untraceable changes | Label AI changes and require extra approval |
| 8 | Insecure defaults shipped to production | Debug modes, exposed metadata | Hardened deployment templates and pre-release checks |
| 9 | Sensitive code and data sent to AI tools | Data leakage | Approved tools with enterprise data terms |
| 10 | Unowned apps built outside engineering | No inventory, no patching | Registration and a named owner before go-live |
1. Insecure code accepted without reading it
The issue: the defining habit of vibe coding is accepting generated code because it runs, not because anyone has read it. Injection flaws, unsafe deserialisation and weak input handling go straight to the main branch.
Why it matters: Veracode's 2025 study of more than 100 models on 80 tasks reported that generated code introduced an OWASP Top 10 weakness in 45% of test cases, with cross-site scripting (CWE-80) failing 86% of the time; these are vendor figures. A user study by Perry et al. found participants with an AI assistant wrote significantly less secure code and were more likely to believe it was secure.
What to do: run SAST on every pull request, block merges on high-severity findings and keep a human approval step. See the AI-Generated Code Review Guide and the CWE Top 25 Guide.
2. Missing authorisation and open backends
The issue: AI app builders wire a front end straight to a hosted database or API. The app works in a demo because every request is allowed, and nobody adds the access rules.
Why it matters: CVE-2025-48757 (CVSS 3.1 base score 9.3) records that an insufficient Row-Level Security policy in Lovable through 15 April 2025 let unauthenticated attackers read or write arbitrary tables of generated sites. In the Moltbook database exposure, a Supabase key in client-side JavaScript plus no RLS exposed about 1.5 million agent API tokens. Missing Authorization (CWE-862) is ranked fourth in the 2025 CWE Top 25.
What to do: enforce authorisation server-side or in the database (OWASP ASVS 5.0 V8.2.1, V8.2.2, V8.3.1), enable RLS on every exposed table, and test with an unauthenticated and a second-tenant account before launch. See the AI App Builder Security Guide.
3. Hard-coded and client-side secrets
The issue: prompts such as "connect to my Stripe account" produce code with the key pasted inline, and builders often place service keys in browser code.
Why it matters: anything in a repository or a JavaScript bundle should be treated as public. A leaked key is a non-human identity with no owner and no expiry.
What to do: enable secret scanning with push protection, which blocks secrets in command-line pushes, web commits, uploads and API requests on GitHub, and restrict who can bypass it. Keep secrets in a vault (ASVS V13.3.1) with rotation (V13.3.4). See the Git Secret Scanning Guide.
4. Hallucinated and unvetted dependencies
The issue: models suggest packages that do not exist, or obscure ones nobody has vetted, and the developer installs them on trust.
Why it matters: Spracklen et al. (USENIX Security 2025) generated 576,000 code samples from 16 models and found average package hallucination rates of at least 5.2% for commercial models and 21.7% for open-source models, with 205,474 unique invented names. Attackers can register those names (slopsquatting), a scenario described in OWASP LLM09:2025 Misinformation and MITRE ATLAS AML.T0060 Publish Hallucinated Entities.
What to do: install only through an internal registry proxy, use lock files, and review any first-time dependency. See the Slopsquatting and Package Hallucination Guide.
5. Coding agents with production access
The issue: agents that run commands hold the same database URLs, cloud tokens and CLI sessions as the developer, including production.
Why it matters: in the Replit agent database deletion, a code freeze existed only as an instruction, so nothing stopped the agent deleting a live database. OWASP LLM06:2025 Excessive Agency names excessive functionality, permissions and autonomy as root causes.
What to do: give agents their own scoped, short-lived credentials, keep production out of the development environment and require human approval for destructive commands. See the AI Coding Agents Security Guide.
6. Poisoned instructions and repository content
The issue: coding agents read READMEs, issues, rules files and tool output, and treat some of it as instructions.
Why it matters: in the Amazon Q Developer extension compromise, an over-scoped GitHub token let an attacker commit a prompt telling the agent to wipe files and cloud resources; it shipped in version 1.84.0 before removal. Indirect injection maps to OWASP LLM01:2025 and ATLAS AML.T0051.001.
What to do: put rules and instruction files under CODEOWNERS, review changes to them like code, and run agents with approval for shell and network actions on untrusted repositories. See the AI IDE and Coding Agent Security Guide.
7. No provenance for AI-generated changes
The issue: nobody can tell which changes came from a model, which prompts produced them or who approved them.
Why it matters: reviewers cannot apply extra scrutiny, and incident responders cannot scope which code to re-check when a tool or model is found to produce a flaw.
What to do: follow the OpenSSF guidance to flag AI-generated code and record the tools used; GitHub rulesets also offer "Require an additional approval for unattributed Copilot pull requests". See the Secure Code Review Guide.
8. Insecure defaults shipped to production
The issue: generated scaffolding leaves debug mode on, permissive CORS, verbose errors and source control folders in the deployed build.
Why it matters: these are quick wins for attackers and fall under A02:2025 Security Misconfiguration.
What to do: deploy through hardened templates and check ASVS V13.4.2 (debug modes disabled in production) and V13.4.1 (no .git or .svn metadata exposed) before release.
9. Sensitive code and data sent to AI tools
The issue: developers paste proprietary code, customer records or credentials into consumer AI tools, or connect tools that index whole repositories.
Why it matters: data may be retained or used under terms the organisation never agreed, which maps to OWASP LLM02:2025 Sensitive Information Disclosure.
What to do: publish an approved-tools list with enterprise terms, block personal accounts where feasible and set rules in a Vibe Coding Policy Template. See the Top 10 Shadow AI Risks.
10. Unowned apps built outside engineering
The issue: analysts, marketers and founders publish working apps from AI builders with no repository, no pipeline and no owner.
Why it matters: these apps never receive dependency updates, penetration tests or access reviews, and they often hold real customer data and API keys.
What to do: require registration and a named owner before an app touches production data, and route it through the same release checks as engineering code. See the Citizen Developer and Internal AI App Governance Guide.
Mapping to OWASP
| Risk | OWASP Top 10:2025 | OWASP Top 10 for LLM Applications 2025 | OWASP ASVS 5.0 |
|---|---|---|---|
| 1. Insecure code accepted unread | A05 Injection, A06 Insecure Design | LLM09 Misinformation, LLM05 Improper Output Handling | V1.2.4, V1.2.5, V1.3.2 |
| 2. Missing authorisation | A01 Broken Access Control | None directly | V8.2.1, V8.2.2, V8.3.1 |
| 3. Hard-coded secrets | A04 Cryptographic Failures, A07 Authentication Failures | LLM02 Sensitive Information Disclosure | V13.3.1, V13.3.2, V13.3.4 |
| 4. Hallucinated dependencies | A03 Software Supply Chain Failures | LLM03 Supply Chain, LLM09 Misinformation | V15.1.2, V15.2.4 |
| 5. Agents with production access | A01 Broken Access Control | LLM06 Excessive Agency | V13.3.2 |
| 6. Poisoned instructions | A08 Software or Data Integrity Failures | LLM01 Prompt Injection | None directly |
| 7. No provenance | A08 Software or Data Integrity Failures | LLM09 Misinformation | None directly |
| 8. Insecure defaults | A02 Security Misconfiguration | None directly | V13.4.1, V13.4.2 |
| 9. Data sent to AI tools | None directly | LLM02 Sensitive Information Disclosure | None directly |
| 10. Unowned apps | A06 Insecure Design | None directly | V15.1.1, V15.2.1 |
CWE references use the 2025 CWE Top 25 where the weakness appears there; CWE-798 and CWE-80 sit outside it. See the OWASP Top 10 for LLM Applications Guide and the OWASP ASVS Guide.
Where to start
If you can only do three things this quarter, close the paths to a public breach first. Turn on secret scanning with push protection across all repositories (risk 3). Make a pull request with one human approval, passing SAST and a passing dependency check mandatory for every branch that deploys, including those created by AI builders (risks 1, 4 and 7). Take production credentials away from coding agents and development environments (risk 5). Then register every AI-built app with an owner (risk 10) and write the rules down in a policy. Track two numbers from day one: the share of merged changes that bypassed review, and the count of secrets blocked at push.
Related NHI Mgmt Group resources: Vibe Coding Security Guide · AI Coding Agents Security Guide · Secure Coding Guide · CWE Top 25 Guide · Vibe Coding Policy Template