Topic starter
18/08/2026 3:02 pm
TL;DR: Hallucinated dependencies and broken access controls are showing up in AI-generated code 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. Review and scanning have to treat generated output as untrusted until security checks and access-control validation finish.
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: 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.
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.
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.
Glossary terms: Vibe Coding, Slopsquatting, Broken Access Control, Hallucinated Dependencies
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
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: AI-generated code is creating repeatable AppSec and IAM failures
This post was modified 1 day ago by NHI Mgmt Group