Vibe coding security vulnerabilities are creating a new AppSec blind spot

At a glance

What this is: Kusari argues that vibe coding is creating a new AppSec blind spot because AI-generated code is arriving faster than review, scanning, and dependency controls can keep up.

Why it matters: This matters because security teams need to govern AI-assisted code as a supply-chain and identity-of-origin problem, not just a developer productivity trend.

By the numbers:

• AI coding assistants have been adopted by 85% of organizations, yet only 9% treat AI-driven AppSec analysis as a must-have capability.

Context

Vibe coding is a development pattern where natural language prompts generate production code with less human review than traditional coding. The security problem is not the use of AI itself, but the loss of context, author intent, and dependency scrutiny before code reaches the repository and build pipeline.

For IAM and AppSec teams, the governance gap is familiar even if the trigger is new: security decisions are being embedded earlier in the software supply chain and then accepted as code. That creates exposure across access control, dependency integrity, logging, and the handling of secrets inside application logic.

Key questions

Q: What should teams do first before relying on AI to write production code?

A: Start with low-risk use cases such as boilerplate generation, test scaffolding, and documentation drafts. Establish a review process for every AI-generated snippet, define which code types are out of bounds, and train developers to verify logic rather than copy output blindly. The first control is not wider usage. It is disciplined oversight and clear boundaries.

Q: Why do AI coding agents increase supply-chain risk?

A: AI coding agents can choose tooling, install packages, and edit lock files in ways that may bypass the controls humans expect in a managed environment. That widens the blind spot around untracked software and makes package provenance harder to enforce. The practical response is to restrict agent permissions, inventory their workspaces, and review their install behaviour like any other privileged automation.

Q: What are the signs that vibe coding controls are failing?

A: Common warning signs include new dependencies appearing without review, repeated insecure patterns in generated code, and AI-authored changes reaching merge without security feedback. A mature team should also watch for inconsistent prompt discipline and low use of AI-supported code review. Those are symptoms that verification is lagging generation.

Q: Should engineering teams treat AI-generated code differently from human-written code?

A: Yes. AI-generated code should pass the same security and quality standards, but it often needs stricter provenance, deeper review on sensitive paths, and stronger automated controls because volume and ambiguity increase the chance of missed defects. The right response is not special treatment, but stronger governance where risk is highest.

Technical breakdown

How AI-generated code bypasses normal review assumptions

AI coding assistants can generate whole functions or modules from a prompt, which means the first executable version of a feature may be produced without the developer reasoning through every control decision. Traditional review assumes a human author has made the key design choices and that scanning catches implementation mistakes later. With vibe coding, the implementation can contain insecure defaults, missing authorization checks, or unsafe data handling before anyone has inspected the logic in detail. That shifts the security problem from isolated code defects to a broader question of provenance, intent, and verification.

Practical implication: treat AI-generated code as untrusted input until it passes automated and human review.

Why hallucinated dependencies create supply chain exposure

Large language models sometimes invent package names or outdated library references. In a normal workflow, a developer would notice that a dependency does not exist or would question whether it is current and trusted. In vibe coding workflows, that check is easy to skip, which creates a clear supply chain opening. Attackers can register phantom package names and wait for someone to install them, turning a model hallucination into a delivery path for malicious code. This is less a language problem than a trust-path problem between prompt output and package installation.

Practical implication: block unvetted dependencies at pull request time and require explicit approval for new packages.

Where AppSec tooling needs to move in the pipeline

Static analysis and software composition analysis still matter, but their value depends on when they run. If they only execute after merge or in periodic scans, AI-generated defects can reach shared branches before any feedback appears. The article’s core operational point is that AI code needs review at the pull request boundary, where a bad dependency, insecure pattern, or missing control can be stopped before release. That is the point at which AppSec becomes preventative rather than forensic.

Practical implication: enforce SAST and SCA on every pull request and gate merge on critical findings.

Threat narrative

Attacker objective: The attacker objective is to get malicious or vulnerable code into production by exploiting trust in AI-generated dependencies and implementation output.

1. Entry occurs when a developer accepts AI-generated code or a suggested dependency with limited manual review.
2. Credential or code trust is abused when the model introduces insecure patterns, outdated libraries, or phantom packages that look legitimate.
3. Impact follows when the flawed code merges into production and expands attack surface, supply chain exposure, or privilege escalation risk.

Breaches seen in the wild

• Sentry MCP Agentjacking 2026: Researchers showed a fake Sentry error, posted with a public DSN, could make AI coding agents run attacker code with developers' credentials.
• Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).

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

Vibe coding security vulnerabilities create a provenance problem, not just a code-quality problem. The issue is not limited to bad syntax or weak coding style. When the author of record becomes an AI assistant, security teams lose the normal human accountability that review processes assume, and that changes how code must be governed. Practitioners should treat generated code as a distinct trust class with its own controls.

Hallucinated dependencies are a supply chain control failure hiding inside developer convenience. The article shows how a model can invent packages that attackers then weaponise by registering the names first. That means software integrity can fail before the code even compiles, which makes dependency approval and package policy part of AppSec, not just software hygiene. Practitioners should move package trust decisions to the pull request boundary.

AI code review gap is the right name for this blind spot. The article’s 85% adoption versus 9% must-have gap shows that organisations have adopted generation faster than verification, creating a structural imbalance in the software pipeline. That imbalance is exactly where insecure patterns, prompt-shaped shortcuts, and dependency mistakes compound. Practitioners should align review automation to where AI code enters the build, not where defects are discovered later.

AI-generated code should be governed like third-party code with identity-sensitive impact. Even when the underlying issue is application security, the identity angle is real because generated code often touches authentication, authorization, tokens, and secrets. That means the security team is not only reviewing code, but also reviewing who or what authored it, how it was validated, and whether its trust path is acceptable. Practitioners should fold AI code provenance into IAM, AppSec, and supply chain controls.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• Read next: AI Coding Agents Security Guide

What this signals

AI code review gap: the market is already showing that code generation has outpaced code verification, and that imbalance will keep producing preventable AppSec findings until teams change the merge boundary. Security leaders should assume the next wave of software risk comes from trusted automation, not just human mistakes.

Vibe coding also changes how security teams should think about provenance. If a model can invent a dependency or propagate an insecure pattern into production, then the question is not only whether the code runs, but whether its trust path is acceptable across build, review, and release.

For practitioners

• Enforce pull request gates for AI-generated code Run SAST and SCA on every pull request and block merges when generated code introduces critical vulnerabilities or unapproved dependencies.
• Block unvetted package installation Require approval for new dependencies and flag phantom packages or unusual package name patterns before they can enter the build.
• Tag and track AI-authored changes Use commit metadata, IDE signals, or repository conventions to identify code that came from AI assistants so reviewers know where extra scrutiny is needed.
• Add secure prompt standards for developers Document prompts that require parameterized queries, explicit authorization checks, secure defaults, and no hardcoded secrets when developers use coding assistants.
• Treat generated code as third-party code Apply the same review discipline to AI-generated code that you would use for external libraries, especially in authentication, authorization, and data handling paths.

Key takeaways

• Vibe coding turns AI-generated code into a governance problem because insecure logic, missing checks, and bad dependencies can enter the pipeline before human review catches them.
• The clearest evidence is the adoption-security gap, where AI coding tools are widely used but AI-driven AppSec analysis is still treated as optional in most organisations.
• Teams need to push verification left with pull request gates, dependency approval, and code provenance tracking or the blind spot will keep growing.

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.
• 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.
• AI-generated code: Software produced wholly or partly by an AI model or agent rather than a human developer. The security concern is not authorship alone, but whether the resulting logic, access control, and dependency choices have been independently verified before release.
• Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is built for teams that need to connect identity, access, and governance decisions across modern security programmes.