TL;DR: Vibe coding ships unreviewed AI-generated code into production at a rate traditional AppSec tooling was not designed to handle. The CSA's 2026 state-of-cloud report names it a first-tier supply chain risk. The specific threat: hallucinated package names (slopsquatting), insecure defaults deployed without audit, and AI-generated security logic that no human validated. When that code powers an agentic AI system with tool access, the blast radius of each unreviewed pattern multiplies. Standard SAST catches some of it. Adversarial testing of the deployed AI application stack catches what SAST misses.

What vibe coding actually ships

Vibe coding is prompt-driven software development: describe what you want in plain language, and a tool like Cursor, GitHub Copilot, or Claude Code generates working code almost instantly. The productivity gains are real. The security implications are getting less attention than they should.

The Cloud Security Alliance's 2026 State of Cloud and AI Security report, authored by Thomas Nuth of Tenable, names vibe coding directly as a supply chain risk: "developers frequently trust and integrate AI-generated or community-sourced code with minimal technical scrutiny." The report's guidance is explicit: treat every AI-generated snippet and third-party library as an untrusted component and apply zero-trust verification before it enters production.

The term "slop code" captures what gets through when that review does not happen: syntactically correct, functionally plausible code that contains hidden risks. The risks are not random. They cluster in predictable categories.

Three attack surfaces slop code creates

1. Slopsquatting: when the package does not exist

Large language models hallucinate package names. They suggest libraries that sound authoritative, match naming conventions, and do not exist. Security researcher Seth Larson coined the term "slopsquatting" for the resulting attack class: an adversary registers the hallucinated name on PyPI or npm before the developer notices the package is fictional, then waits for copy-paste adoption.

A USENIX-published analysis of 576,000 generated Python and JavaScript code samples found that roughly 20% referenced packages that did not exist. Commercial models hallucinate less frequently (ChatGPT-4 at approximately 5%), but open-source code models log significantly higher rates. More critically, 43% of hallucinated package names were reproduced consistently across repeated runs of the same prompt, making the attack surface predictable and therefore exploitable at scale.

The attack chain is short: AI generates code referencing ai-utils-secure → ai-utils-secure does not exist on PyPI → attacker registers ai-utils-secure with a credential harvester payload → developer runs pip install from the AI-generated snippet without checking → production system is compromised. The developer never typed the package name themselves. The AI did.

2. Insecure defaults deployed without audit

The Veracode 2025 GenAI Code Security Report tested over 100 LLMs across 80 coding tasks in Java, Python, C#, and JavaScript. The headline finding: 45% of AI-generated code samples failed security tests and introduced OWASP Top 10 vulnerabilities. When given an explicit choice between a secure and insecure implementation, models chose the insecure path 45% of the time. For specific vulnerability classes, the failure rate was higher: cross-site scripting (CWE-80) was left undefended in 86% of cases; log injection (CWE-117) in 88%.

A concrete example surfaces in the Moltbook case. Security researchers at Wiz discovered a misconfigured Supabase database in a production application where the AI scaffold had set the database to public read and write access by default. The founder had not reviewed the infrastructure code before deployment. The permissive setting was not intentional; it was what the AI generated, and it shipped.

Across a dataset of 5,600 vibe-coded applications, researchers identified over 2,000 distinct vulnerabilities, more than 400 exposed secrets (API keys, tokens, credentials embedded in code), and 175 instances of exposed PII. Each of those was a pattern the AI generated and a human did not review.

3. AI-generated security logic in AI applications

The most consequential category for security engineers is also the least discussed: AI-generated code that handles authentication, authorization, input validation, or cryptographic operations in AI-powered applications. These are not edge cases. Vibe coders building AI assistants, RAG pipelines, and agentic tools are generating the security-critical logic that governs what the AI application can access and what it can do.

Injection flaws and broken authentication are consistently the top two categories in AI code security failures, and they are exactly the categories where LLMs produce plausible-looking code that fails under adversarial conditions. An authentication check that works for happy-path inputs may collapse when an attacker crafts a specifically malformed token. Prompt injection in the application layer is often a direct consequence of unreviewed input handling code in the AI system itself.

The agentic multiplier

A buffer overflow in a CLI utility is a contained problem. The same class of vulnerability in an AI agent with access to email, calendar, file systems, and external APIs is not.

The CSA report documents a machine-to-human identity ratio of 100:1 in enterprise environments in 2026. These machine identities include AI agents, many of which were built with AI coding assistants and deployed at speed. A Dark Reading survey found 48% of security professionals identify agentic AI and autonomous systems as their top attack vector heading into 2026. The MIT AI Agent Index puts 40% of deployed AI agents at zero safety monitoring.

When vibe-coded agents write code autonomously and that code itself becomes part of the codebase, the risk compounds. An agent generating 1,000 pull requests per week at a 1% vulnerability introduction rate ships 10 new vulnerabilities weekly, none of them reviewed by a human. Each vulnerability in an agentic system with tool-call access represents a potential path to privilege escalation, data exfiltration, or cross-agent injection.

The MCP protocol, which vibe coders routinely wire up without security review, introduces additional attack surface: malicious tool descriptions, cross-server privilege escalation, and remote code execution through schema manipulation. An agent built with vibe-coded MCP integrations that are not adversarially tested before deployment is an open invitation.

What traditional AppSec tooling misses

Static analysis tools (SAST) catch categories of vulnerability they were trained to detect: SQL injection, hardcoded secrets, known insecure function calls. They do not catch prompt injection vulnerabilities embedded in AI application logic. They do not validate whether an agentic system's tool-call authorization logic holds under adversarial inputs. They do not test whether a RAG pipeline is poisonable through its retrieval layer.

Supply chain risk from hallucinated packages is particularly difficult to catch with standard SCA tooling: if the package does not yet exist in a vulnerability database, the scanner has nothing to match against. The attacker-registered package looks like a valid dependency until it executes.

Security debt from vibe coding is a distinct category of exposure. It requires adversarial testing of the deployed application stack, not static analysis alone.

What security teams can do

Inventory what AI coding tools are in use

Before you can audit vibe-coded code, you need to know where it is coming from. Shadow AI in the developer toolchain, including engineers using personal Cursor subscriptions, browser-based AI coding assistants, or unauthorized LLM APIs, creates an attack surface that is invisible without active discovery. Repello's AI Inventory discovers AI assets across the organization, including which AI tools are operating in engineering workflows, and builds an AI Bill of Materials that makes the generated code surface auditable. You cannot apply zero-trust to code you do not know exists.

Treat AI-generated code as untrusted third-party input

The CSA recommendation is operational: apply the same scrutiny to every AI-generated snippet that you apply to open-source dependencies. That means automated integrity verification, vulnerability scanning, and human review for security-critical components. Authentication modules, payment logic, infrastructure scripts, and the security layer of any AI application should not ship unreviewed regardless of how they were generated. The Veracode data makes the risk concrete: a team shipping 100 AI-generated functions per sprint is statistically shipping 45 with OWASP Top 10 vulnerabilities, unless those functions are reviewed.

Red team the deployed AI application stack

SAST tells you what is in the code. Adversarial testing tells you whether it is exploitable. For AI applications built using vibe coding, the attack surface that matters most is the one that activates under attacker-controlled inputs: prompt injection through the application's input handling, RAG poisoning through its retrieval layer, tool-call hijacking through its agentic integrations, guardrail bypass through encoding variations the generated code does not handle.

ARTEMIS tests the full deployed application stack against all five attack surfaces: input/output, retrieval, tool-call and agentic, model, and runtime. For teams that built AI applications using vibe coding and have not run adversarial testing on the result, ARTEMIS surfaces what SAST and manual review missed: real exploitable vulnerabilities in the live system, including attack paths specific to the application's context, system prompt, and tool integrations. The output is an attacker-perspective report with reproducible exploitation evidence and prioritized remediation steps.

Apply runtime protection to production AI systems

Pre-deployment testing closes known gaps. Runtime monitoring catches what was not anticipated. ARGUS, Repello's runtime security layer, monitors AI applications in production and blocks malicious inputs before they reach the model, operating in under 100ms with zero user-facing latency. For applications that were built fast and deployed before thorough adversarial testing, ARGUS provides a defensive layer against active exploitation attempts while the underlying code is being audited and hardened.

The combination reflects the correct security posture: AI risk assessment and AI Inventory to understand the exposure, ARTEMIS to validate the full application stack against the actual threat model, and ARGUS to protect production systems against active exploitation.

Frequently asked questions

What is vibe coding and why is it a security risk?

Vibe coding is prompt-driven software development where developers describe desired functionality in natural language and AI tools generate the implementing code. The security risk is that AI-generated code frequently contains OWASP Top 10 vulnerabilities: Veracode's 2025 GenAI Code Security Report found 45% of AI-generated code samples failed security tests. Developers building AI applications with these tools are shipping unreviewed code into systems that may have administrative-level access to sensitive data and infrastructure.

What is slopsquatting?

Slopsquatting is a supply chain attack that exploits hallucinated package names in AI-generated code. When a developer copies an AI-generated pip install or npm install command, the referenced package may not exist or may have been registered by an attacker. A USENIX-published study found that roughly 20% of AI-generated code samples referenced non-existent packages, and 43% of hallucinated names were reproduced consistently, making them predictable targets for pre-registration by attackers.

Does static analysis (SAST) catch vibe coding vulnerabilities?

SAST catches known vulnerability patterns in source code. It does not catch prompt injection vulnerabilities in AI application logic, poisonable retrieval pipelines in RAG systems, insecure agentic authorization patterns, or supply chain risk from hallucinated packages that have not yet been registered in vulnerability databases. AI applications built with vibe coding need adversarial testing of the deployed stack, not only static analysis.

How does vibe coding interact with agentic AI security?

When vibe-coded code powers an autonomous AI agent with tool access, the blast radius of each unreviewed vulnerability increases substantially. An agent writing 1,000 pull requests per week at a 1% vulnerability rate ships 10 new vulnerabilities weekly. An agent with email, calendar, and file system access that contains a prompt injection vulnerability is exploitable for zero-click data exfiltration and unauthorized action execution. The OWASP Agentic AI Top 10 documents the attack classes that emerge specifically in agentic architectures built without adversarial testing.

What is the right process for securing vibe-coded AI applications?

Start with inventory: know which AI coding tools are in use across your engineering organization. Apply zero-trust code review to AI-generated components, especially security-critical logic. Run adversarial testing on the deployed application stack to find what static analysis misses. Apply runtime monitoring to production systems to block active exploitation attempts against vulnerabilities not yet remediated. The AI risk assessment process is the starting point for mapping which of these layers you already have covered.

Audit the AI application stack your team just shipped

The question is not whether your engineering team is using AI coding tools. They are. The question is whether the AI applications they built with those tools have been tested against the attack surface those tools introduce.

ARTEMIS runs adversarial testing across the full AI application stack: prompt injection, RAG poisoning, tool-call hijacking, guardrail evasion, and agentic attack paths specific to your deployment. If your team has shipped AI applications built with vibe coding and has not run this class of testing, book a demo with Repello to see what the current attack surface looks like.