Vibe coding security risks are outpacing AppSec controls

At a glance

What this is: Arnica argues that vibe coding is creating repeatable AppSec failures, including broken access controls, hardcoded secrets, and hallucinated dependencies that traditional review often misses.

Why it matters: This matters because AppSec, IAM, and secrets governance now need to control AI-generated code as a production risk, not just a developer productivity trend.

By the numbers:

• 38% of AI-generated code contained at least one security flaw, spanning injection vulnerabilities, hardcoded secrets, and broken authentication.
• LLMs hallucinate fake package names 20% of the time, creating slopsquatting attack opportunities.
• A controlled experiment measured a 37.6% increase in critical vulnerabilities after five rounds of AI-assisted code refinement.

Context

Vibe coding is the practice of generating software from plain-language prompts and then editing the output rather than writing every line directly. That shifts the security burden from code authorship to code governance, because the most common failures are no longer syntax errors but missing authorization checks, insecure defaults, and unsafe dependency choices.

The article frames this as an AppSec problem with identity implications: generated code can expose secrets, weaken access controls, and create uncontrolled trust in AI-suggested dependencies. For identity security teams, that means application logic, authentication paths, and credential handling must be treated as governed outputs, not assumed-safe artefacts.

The examples in the article are not edge cases. They show what happens when speed-to-ship culture outruns review, and that pattern is already visible in incidents the article cites.

Key questions

Q: What breaks when AI-generated code is reviewed without security gates?

A: What breaks is the assumption that a clean-looking diff is a safe diff. AI-generated code can hide unsafe defaults, dependency issues, and weak validation that basic review misses. Without CI-enforced tests and security checks, the merge process becomes a distribution channel for defects rather than a control point.

Q: Why do AI-suggested dependencies create supply chain risk?

A: AI-suggested dependencies create risk because the model can invent package names that appear plausible but are not trustworthy. Attackers can register those names and wait for the next automated or hurried install. The control gap is trust without verification, so teams need registry checks, provenance validation, and explicit approval before installation.

Q: What do security teams get wrong about vibe coding and mobile risk?

A: They assume speed and polish imply security. AI tools can produce a working interface in hours, but they do not reliably enforce secure coding, privacy, or compliance. Teams need explicit requirements, repeatable testing, and release gates that verify the app behaves safely under real mobile conditions.

Technical breakdown

Why AI-generated code produces semantic security gaps

LLMs are optimised to produce code that looks plausible and compiles, not code that enforces a threat model. That is why the most serious defects are often semantic, such as missing authorization checks, unsafe assumptions about user input, or logic that exposes data without ever triggering a syntax or pattern-based alert. In practice, the model can generate a working endpoint that still violates tenant isolation, authentication, or access-control requirements. The security gap is therefore not just code quality. It is a failure to encode policy into generation, review, and test stages.

Practical implication: review AI-generated code for missing controls, not just bad patterns.

Hallucinated dependencies and the slopsquatting attack path

When an LLM invents a package name, it creates a predictable opportunity for an attacker to publish malware under that name and wait for developers to install it. This is slopsquatting: the attacker does not need to compromise the model or the repository, only exploit the model's tendency to output plausible but nonexistent dependencies. The risk becomes more serious when the same hallucinated names recur across prompts, because repetition makes them easy to weaponise. Dependency security therefore has to move upstream into code generation and package approval.

Practical implication: validate every AI-suggested dependency before installation or merge.

Why traditional SAST misses vibe coding failures

Traditional static analysis tools are strong at recognising known unsafe functions and known bad sinks, but they struggle when the problem is omission rather than commission. If an AI-generated route lacks an authorization check, there may be no signature to flag. If the dangerous code is split across files, a single-file scanner can miss the broken relationship between endpoint, identity check, and data access. That is why point-in-time scanning is insufficient for AI-generated code. Security needs continuous analysis that understands data flow and access logic across files.

Practical implication: pair SAST with cross-file analysis and policy checks at commit time.

Threat narrative

Attacker objective: The attacker objective is to turn trusted AI-generated output into unauthorized access, data exposure, or code execution without needing a traditional exploit chain.

1. Entry occurs when a developer accepts AI-generated code or AI-suggested dependency names without security review.
2. Credential and access exposure follows when the generated code omits authentication checks, embeds secrets, or opens an administrative route to anyone who can reach it.
3. Impact is user data exposure or malicious dependency execution, with the attacker benefiting from code the developer trusted as functional output.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI-generated code has become a governance problem, not just a developer productivity problem. The key failure is that security teams still assume code review happens after the risky decision has already been made, while vibe coding collapses design, implementation, and trust into a single prompt-response loop. That changes the control point from manual inspection to issuance-time policy, with AppSec, IAM, and secrets governance all needing to inspect what the model produced before it becomes an application dependency.

Broken access control is the most revealing failure mode in this article. The Tea app and Moltbook examples show that the issue is often not sophisticated exploitation but absent authorization logic in code that appeared to work. That makes this an identity problem as much as an application problem, because the first broken trust boundary is often who can reach what data, route, or admin function.

Slopsquatting is a supply-chain risk created by model behaviour, not by package ecosystems alone. The article's package-hallucination examples show how AI can invent the exact dependency that an attacker later publishes. That means dependency governance now has to account for generated artefacts, not just human-selected packages, and the practitioner conclusion is to treat AI-suggested dependencies as untrusted until validated.

Continuous analysis beats retrospective scanning when code is generated at machine speed. If iterative prompting increases critical vulnerabilities, then the control objective cannot be to catch the same flaws later with a larger rule set. The field needs policy enforcement, secret detection, and cross-file analysis at the point of commit, because once AI output reaches production the blast radius is already set.

Named concept: prompt-to-production trust gap. This article describes the gap between what developers assume an AI-generated code path has checked and what the code actually enforces. The practical implication is that organisations need explicit governance over AI-generated code paths, dependency suggestions, and access-control logic before deployment.

From our research library:

• Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to the State of Secrets in AppSec.
• Read next: AI Coding Agents Security Guide

What this signals

Prompt-to-production trust gap: The practical problem is not that AI writes code quickly, but that it creates a false sense of review coverage around code that has not yet been governed. Teams should assume generated code can bypass ordinary developer intent and force security checks at the point where code becomes deployable, not after.

AppSec teams need to reframe AI-generated code as an identity and access-control issue when it touches authentication, authorization, or secrets. The next governance step is to align application review with identity policy so that generated endpoints cannot quietly weaken data boundaries.

The article also signals that dependency governance must expand beyond known package reputation into validation of model-suggested artefacts. When hallucinated package names become predictable, the attack surface moves upstream into the coding assistant itself, and the control has to follow.

For practitioners

• Treat AI-generated code as untrusted input Require human review, test coverage, and security scanning before any AI-generated code reaches a protected branch or production build.
• Block hallucinated dependencies before installation Validate every package name suggested by coding assistants against approved sources and deny installs for names that are not present in your allowlist or software inventory.
• Add secret detection at commit time Scan for hardcoded credentials and API keys as code is written and committed, not only during periodic repository reviews.
• Enforce human review on access-control paths Require senior review for generated endpoints that touch authentication, authorization, tenancy, or user data handling, because these are the places AI output most often skips a control.
• Use cross-file analysis for generated logic Look for broken relationships between routes, data access, and identity checks across multiple files instead of relying on single-file pattern matches.

Key takeaways

• Vibe coding is turning AI-generated output into an AppSec and identity governance problem because missing controls can ship even when the code appears to work.
• The article ties the risk to measurable evidence, including 38% flawed generated code, 20% hallucinated package names, and a 37.6% rise in critical vulnerabilities after repeated AI iteration.
• The most effective control shift is to treat generated code and AI-suggested dependencies as untrusted until review, scanning, and access-control validation are complete.

Key terms

• Vibe Coding: A software development approach where natural-language prompts drive much of the implementation and AI produces the code. In practice, the term covers a wide range of control levels, from no-review prototyping to structured engineering with tests, review, and architecture held by humans.
• Slopsquatting: Slopsquatting is a supply-chain attack that exploits hallucinated package names suggested by AI systems. An attacker registers the invented name in a public registry and waits for a developer or build pipeline to install it. The risk sits at the intersection of model error, dependency trust, and software delivery speed.
• Broken Access Control: Broken access control occurs when a system fails to restrict what an authenticated user, service, or workload can do. The issue often appears as missing checks, inconsistent enforcement, or excessive permissions. It is a structural weakness because attacks exploit the gap between verified identity and permitted action.
• Hallucinated Dependencies: Hallucinated dependencies are fake packages, libraries, or registries that an AI model invents while trying to solve a coding task. They create real security risk because attackers can register those names on public package managers and place malicious code there, turning a model error into a software supply chain compromise.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and identity lifecycle controls that help teams govern machine and agent-adjacent access paths. It is designed for practitioners who need to connect identity control to broader security programmes.