Notifications
Clear all
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.
NHIMG editorial — based on content published by Arnica: Vibe Coding Security Risks You Can't Ignore (June 2026)
By the numbers:
- 38% of AI-generated code contains security flaws like injection vulnerabilities and hardcoded secrets.
- LLMs hallucinate fake package names 20% of the time, creating slopsquatting attack opportunities.
- Iterating with AI increases critical vulnerabilities by 37.6% instead of fixing existing flaws.
Questions worth separating out
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 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.
Q: How can security teams tell whether AI-generated code is actually safe?
A: They should look for security regression evidence, not just test pass rates.
Practitioner guidance
- Implement mandatory human review for access-control code Require manual sign-off on any AI-generated path that creates, changes, or checks authentication, authorisation, session handling, or tenant isolation logic.
- Block unverified dependencies from AI-assisted builds Add policy gates that reject package names not present in an approved allowlist, internal mirror, or provenance-verified software catalog.
- Run security analysis before merge, not after release Use real-time SAST and secret detection on every AI-generated commit so hardcoded credentials, injection patterns, and missing controls are found while changes are still small.
What's in the full article
Arnica's full blog post covers the operational detail this post intentionally leaves for the source:
- Study examples of broken access control and exposed admin paths in AI-generated applications.
- Review the vulnerability classes Arnica maps to real AppSec workflows, including hardcoded secrets and insecure dependencies.
- See the discussion of real-time security checks for AI-generated commits and how they fit into developer pipelines.
- Use the source article's incident examples and mitigation framing when you need implementation detail beyond governance analysis.
👉 Read Arnica's analysis of vibe coding security risks and AI-generated code flaws →
Vibe coding risks: are your AppSec controls keeping up?
Explore further
18/08/2026 3:41 pm
AI-generated code now behaves like unreviewed third-party code. Once a model writes application logic, the security team can no longer assume the code reflects internal design standards or identity checks. That changes the AppSec model from defect detection to trust verification, because the real question is whether the generated code preserves access boundaries at all. Practitioners should treat every AI-produced change as externally sourced logic until proven otherwise.
A question worth separating out:
Q: Who is accountable when AI-generated code creates licence exposure?
A: Accountability usually spans engineering, legal, and security, because each owns part of the workflow that allowed the code to enter the codebase. The organisation remains responsible for the output it ships, so policy, review, and escalation paths need clear ownership before developers rely on AI at scale.
👉 Read our full editorial: Vibe coding security risks are outpacing AppSec controls
