Vibe coding security: The gap between “It works” and “It’s safe”

Here is a number worth sitting with. In a recent Carnegie Mellon University benchmark, 61% of the code generated by an AI agent running on Claude 4 Sonnet passed functional tests. Only 10.5% of that same code passed security tests.

For every 10 working features an AI agent ships, roughly 9 carry exploitable security vulnerabilities. That is the state of vibe coding security today.

What vibe coding is

Andrej Karpathy coined the term in early 2025.

The vibe coding workflow is simple. Use natural language to describe what you want, and the AI coding assistant writes the code, runs it, fixes errors, and iterates until it looks right.

Tools like Cursor, Claude Code, and GitHub Copilot have made this mainstream across teams of all sizes. A 2025 survey found that 75% of developers use some form of vibe coding, and 90% find it useful.

The problem is that “it works” and “it’s safe” are two very different standards. And in software development, they diverge most dangerously when nobody checks.

Vibe coding security: The lay of the land

“Fast starts, harder finishes” — this description captures the security posture of vibe coding pretty well. Early progress feels smooth, but fragility accumulates beneath the surface.

Zhao et al. (2025) tested AI coding agents on 200 real feature requests drawn from open-source projects. These are the kinds of tasks that historically led human developers to introduce bugs. The research team found that over 80% of functionally correct solutions contained security vulnerabilities.

Waseem et al. (2025) scanned 7 vibe-coded MVPs using an agentic AI security scanner. They found 970 security issues, among which were the usual suspects:

• Path traversal
• Hardcoded secrets
• Command injection
• Missing authentication checks
• Cross-site scripting

801 of the weaknesses were high-severity security vulnerabilities.

CodeRabbit (2025) found that AI-generated pull requests introduce improper password handling — including hardcoded credentials — at nearly twice the rate of human-written code. It also revealed that security findings overall are 1.57 times higher.

Veracode’s “October 2025 Update: GenAI Code Security Report“ tested over 100 LLMs on coding tasks that forced a choice between secure and insecure implementations. It found that models chose the insecure option in 45% of cases — and in over 70% of Java tasks specifically.

Research from Invicti (Calin, 2025) revealed that AI models consistently produce hardcoded secrets:

• API keys
• Database passwords
• JWT signing secrets

Each model reuses the same values repeatedly across different generated apps. For instance, the string supersecretkey appeared in 1,182 of the 20,000 apps analyzed.

The problem is that a predictable JWT secret, like GPT-5’s most common value, supersecretjwt, lets an attacker forge admin tokens and walk straight into protected dashboards — a complete authentication bypass. And common credentials like user@example.com:password123 make account takeover trivial.

However, Invicti, which generated and analyzed more than 20,000 vibe-coded web applications, adds useful nuance. AI models have improved at avoiding classic security vulnerabilities like SQL injection and XSS. Currently, the picture is uneven:

• The situation with basic, well-known vulnerabilities is improving.
• But context-dependent security flaws — timing side channels, broken access controls, improper session expiration, and missing input validation — remain stubbornly common.

The latter are security flaws that appear correct in source code but break in production under attack conditions in the wild.

Researcher Reya Vir sheds some light on why this happens. Coding agents are optimized to eliminate errors, not to understand what caused them. For instance, if an app throws a “Permission Denied” error during a database query, the agent resolves it by setting the access policy to USING (true). That clears the error by making the entire database readable by anyone on the internet.

The app runs, the error disappears, and nothing in the code indicates any issue. The agent did exactly what it was supposed to do. The developer has no obvious reason to look deeper. The vulnerability ships…

Why telling the AI to be secure is not the solution

The natural response from developers is to add security instructions to prompts. “Write secure code.” “Follow security best practices.” “Avoid common vulnerabilities.”

The Carnegie Mellon University study mentioned earlier tested exactly this approach. The researchers added generic security guidance, gave agents full lists of Common Weakness Enumerations (CWEs), and even told agents the exact vulnerability type they needed to avoid.

None of it worked reliably. Worse, when agents focused more on security, functional correctness dropped — they overprioritized security checks and missed functional requirements. The researchers describe it plainly: prompting is not enough. Security must be a first-class objective tested independently against the running application.

This finding matters for anyone responsible for coding security at scale. An AI coding assistant generating insecure code is not a prompt engineering problem. It is a problem in application security testing.

Attacking the tool that generates the code

There is a separate category of vibe coding security risk that gets less attention but is arguably harder to defend against. It encompasses cyberattacks that don’t target the generated code but the AI agent that generates it.

When developers import external resources into their editors — coding rule files, forked repositories, MCP server configurations — the agent reads them as trusted context. Attackers have learned to hide instructions in those files.

Liu et al. (2025) studied this pattern, indirect prompt injection, and found attack success rates of up to 84% against Cursor and GitHub Copilot, with commands ranging from SSH key theft to privilege escalation.

Another technique called “Lies-in-the-Loop” exploits the gap between what an agent describes in its confirmation dialog and what it actually executes. In such a scenario, developers can approve malicious commands because the UI summary appears plausible.

Supply chain attacks have adapted too. AI models often invent package names that sound plausible but don’t exist. Attackers pre-register those names on PyPI and npm and fill them with malware. Spracklen et al. (2025) studied 16 popular models and found that:

• At least 5.2% of packages suggested by commercial models were fabricated.
• 43% of those hallucinated names appeared consistently across repeated runs, which makes them predictable targets.

Incidents in the wild confirm the stakes:

• In Moltbook, a vibe-coded AI social network, a missing Supabase security configuration exposed:

  • 1.5 million API authentication tokens
  • 64,000 user email addresses
  • 4,060 private messages, some containing plaintext OpenAI API keys
  • Full write access to all posts
• A Base44 platform flaw allowed any user to access private applications using only a publicly visible app ID.
• A vibe-coded sales app suffered a breach because the AI agent omitted authentication and rate-limiting controls.

Vibe-coded apps break at the API layer

The security flaws discussed so far—hardcoded credentials, broken access control, missing input validation, and incomplete authentication logic — eventually materialize at the API layer. This is where the generated code meets actual users, requests, and attackers. A vulnerability buried in source code becomes exploitable the moment it is reachable through an endpoint.

Vibe-coded apps generate predictable endpoints — login routes, data retrieval paths, and admin functions, among others. Attackers know this. They also know that access controls behind these can be incomplete, sensitive data handling can be inconsistent, and user input can be unvalidated.

And that is where continuous adversarial testing becomes invaluable, as it embodies the approach and mindset attackers use to target your vibe-coded applications.

Equixly’s Agentic AI Hacker is built on this premise. It runs continuous AI penetration testing at scale against APIs, using adversarial tactics, techniques, and procedures to discover the same security vulnerabilities malicious actors seek:

• Business logic flaws
• Broken access controls
• Authentication bypasses
• Subtle, insecure code patterns that look plausible in a source review but fail under attack conditions

Vibe coding security best practices

Vibe coding is not going away, and neither are the security risks it introduces. What development and security teams can do is close the gap between fast code generation and safe software development.

1. Review the generated code before it ships

AI-generated code requires the same scrutiny as human-written code, arguably more so. Developers who do not write the code lack the instinct to spot where it breaks. Therefore, a human reviewer who understands the context and the threat model is the most important first check.

2. Scan for hardcoded secrets automatically

Secret scanning should be the default in CI/CD pipelines, not an optional step. Hardcoded secrets are among the most consistent findings across all vibe coding security research. At the same time, they are among the easiest security issues to catch automatically before insecure code reaches production.

3. Test the running application

Static analysis tools are largely ineffective on AI-generated code. The Invicti study mentioned earlier found that manual review confirmed only a handful of true positives among SAST findings.

Dynamic application security testing and continuous penetration testing catch what static tools miss, especially business logic issues, access control gaps, and sensitive data exposure.

4. Treat APIs as the primary attack surface

A vibe-coded app is as secure as its API layer. For this reason, you must:

• Test authentication logic, access control rules, and data handling with an adversarial mindset.
• Probe for Broken Object Level Authorization.
• Send unexpected user input and observe what the application does.
• Check what leaks through error messages.

5. Define security requirements before generation

Write down security acceptance criteria before prompting an AI coding tool, not after. Threat-model the feature. And write security tests alongside functional tests.

Those are standard software development best practices. What makes them matter more now is that AI-assisted development moves so quickly that it outpaces the checks teams might otherwise catch naturally.

6. Apply least-privilege to the agent, not only the app

Restrict what AI agents can access and execute. Agents should only reach development and test environments, not production.

Auto-execution requires human confirmation. Separation of duties applies to AI tools just as it does to human operators.

7. Know what model-layer security improvements can and cannot do

Security reasoning in LLMs is concentrated in a small set of neurons. When you fine-tune those neurons selectively, the secure code generation rate increases dramatically — from 6.1% to 86.6% on C++ for CodeLlama-7B. It also preserves general coding ability, with an average drop in reasoning of only 0.84% (Thang et al., 2026).

The honest take

Vibe coding lowers the barrier to building software. That is genuinely useful. It also lowers the barrier to shipping insecure code faster and at a greater scale than before.

The gap between functional and secure is not a problem that generative AI is close to closing on its own. Current research makes that clear. Until AI coding tools handle security reasoning as well as they handle syntax, the responsibility falls on the teams building applications and the security tools they use to test them.

The good news is that the best practices for vibe coding security are not new. They are the application security practices that rigorous engineering teams have always followed. The difference now is the cost of skipping them.

The EU AI Act’s Article 14 mandates human oversight of AI systems used in high-risk contexts, and the UK is aligning with similar principles through its existing UK GDPR obligations, which require human involvement in automated decision-making processes. Legal analysts have been clear: “I didn’t write it, the AI did” is not a defense.

The entity that ships the software owns the risk. And when the software is vibe-coded, tested by no one, and deployed quickly, the risk is as palpable as it gets. Every unreviewed deployment is an invitation. Continuous adversarial testing is how you answer it before attackers do.

Vibe coding moves fast. Equixly keeps pace. Book a demo and find out what your last deployment left open.

FAQs

Can better prompts fix vibe coding security problems?

No, as research shows that prompts focused on security reduce functional correctness but do not reliably prevent serious vulnerabilities.

What is the single biggest security risk in a vibe-coded app?

The most consistent risk is the combination of hardcoded secrets—API keys, database passwords, and tokens baked directly into generated code—alongside weak access controls in the API layer.

What should developers do before prompting an AI coding tool to add a new feature?

Define security acceptance criteria, threat-model the feature, and write security tests alongside functional tests. And before deploying, test the running application with continuous adversarial testing because static analysis tools miss context-dependent flaws.

Zoran Gorgiev

Technical Content Specialist

Zoran is a technical content specialist with SEO mastery and practical cybersecurity and web technologies knowledge. He has rich international experience in content and product marketing, helping both small companies and large corporations implement effective content strategies and attain their marketing objectives. He applies his philosophical background to his writing to create intellectually stimulating content. Zoran is an avid learner who believes in continuous learning and never-ending skill polishing.

Gavin Sutton

Head of Marketing

Gavin is marketing leader with more than a decade of experience in the cybersecurity industry helping startups and scale ups grow internationally. He has a passion for working with disruptive technology companies who can reshape the security landscape with their innovative solutions.