Topic starter
18/08/2026 3:02 pm
TL;DR: AI-generated code now produces security flaws, hallucinated dependencies, and broken access controls at scale, with one study finding 38% of generated code contained vulnerabilities and another showing 19.7% of samples invented package names, according to Arnica. The governance problem is not speed alone, but that unreviewed code and AI-generated dependency choices expand the attack surface faster than traditional review and scanning can reliably cover.
Editorial analysis by NHI Mgmt Group, based on content published by Arnica: “Vibe Coding Security Risks You Can't Ignore (June 2026)”.
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.
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.
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.
Q: What do security teams get wrong about vibe coding and mobile risk?
A: They assume speed and polish imply security.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:41 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Vibe coding security risks are outpacing AppSec controls