Vibe coding security risks are outpacing AppSec controls

At a glance

What this is: This is Arnica’s analysis of vibe coding risk, showing that AI-generated code repeatedly introduces vulnerabilities, broken access controls, and hallucinated dependencies when it ships without security review.

Why it matters: It matters to IAM, AppSec, and platform teams because AI-written code can skip authorization logic, expose secrets, and create new access paths that identity and security controls must detect before release.

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.

👉 Read Arnica's analysis of vibe coding security risks and AI-generated code flaws

Context

Vibe coding is a software delivery model where natural-language prompts generate production code, but that speed creates a governance gap when security review does not keep pace. In application security terms, the problem is not only that AI writes insecure code, but that it can generate missing controls, unsafe dependencies, and weak access logic that compile cleanly and still fail in production.

For identity and access teams, the most important issue is that AI-generated code can create or bypass authorization paths without the normal design scrutiny. That makes broken access control, secret exposure, and dependency trust part of the IAM-adjacent attack surface, especially when teams use AI to build apps that touch authentication, APIs, and data storage.

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 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: 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. A codebase is safer only when the agent’s output survives threat-informed checks, review of privileged paths, and validation against the vulnerability classes most likely to recur in that repository.

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.

Technical breakdown

How AI-generated code creates missing authorization controls

LLMs optimize for plausible code completion, not for a threat model. That means they can generate functional endpoints, data handlers, and CRUD paths while omitting the authorization checks that would normally enforce tenant isolation or per-user access. The result is not always obviously malicious code. More often, it is a missing decision that leaves data exposed through an otherwise valid workflow. Static analysis tools catch unsafe patterns well, but they struggle when the control is absent rather than incorrect. In practice, this makes broken access control one of the most dangerous AI-generated failure modes because it often survives compilation, tests, and code review when review is shallow.

Practical implication: require explicit authorization review for every AI-generated code path that touches identity, access, or data retrieval.

Hallucinated dependencies and slopsquatting risk in AI coding

Hallucinated dependencies occur when an LLM invents a package name or library that does not exist. The risk becomes exploitable when attackers register that phantom name and publish malicious code under it, a pattern known as slopsquatting. This is different from ordinary supply chain risk because the attacker is not waiting for a typo or compromised maintainer. They are weaponising a predictable output from the model itself. Dependency scanning helps with known packages, but it does not protect against names that only become real after the AI suggests them. That creates a new procurement and trust problem for development teams using coding assistants.

Practical implication: block unapproved package installation paths and verify every AI-suggested dependency against a maintained allowlist.

Why iteration can amplify critical defects instead of removing them

Repeated AI refinement does not guarantee safer code. In controlled testing, iterative prompting can bury defects deeper by changing surrounding logic while leaving the underlying security failure intact. This matters because teams often assume that another prompt or another pass through the assistant will naturally improve the output. In reality, each revision can increase complexity, reduce human readability, and make the original flaw harder to notice. That pattern is especially dangerous for security-sensitive functions such as authentication, session handling, and access control, where small changes can have wide blast-radius effects.

Practical implication: treat AI refinement as an editing step, not a remediation step, and re-review the whole control path after every iteration.

Threat narrative

Attacker objective: The attacker objective is to turn AI-generated development shortcuts into practical access to data, credentials, or privileged application functions.

1. Entry occurs when AI-generated code is merged into an application without a full security review, often because the output appears to work and satisfies the functional requirement.
2. Escalation happens when missing authorization logic, exposed admin routes, or hardcoded secrets create unauthorised access paths that attackers can use without sophisticated exploitation.
3. Impact follows when exposed data, privileged endpoints, or malicious dependencies reach production and enable user-data leakage, account compromise, or downstream supply chain abuse.

NHI Mgmt Group analysis

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.

Broken access control is the most operationally dangerous vibe coding failure because it is often a missing control, not a bad control. That makes it harder to detect with signatures and easier to ship through ordinary CI/CD paths. In IAM terms, the issue is a failure to enforce authorisation decisions at the point of use, which is why identity logic must be reviewed alongside application logic. Practitioners should inspect AI-generated CRUD paths with the same scepticism they would apply to public API exposure.

Hallucinated dependencies create a new trust boundary around package names. The model may invent a library that looks normal enough to pass code review, but the security meaning is that a trusted build process can be redirected toward attacker-controlled code. This is a software supply chain problem with an identity angle: the build system is making an access decision about code it has not authenticated. Practitioners should tighten dependency approval and tie package admission to verified provenance.

Vibe coding makes security debt compound faster than governance can retire it. The combination of speed, repeated iteration, and shallow review means the control gap widens every time a team asks the model to refine a feature. That is not just a developer productivity issue. It is an operating model issue for AppSec, IAM, and platform teams that now need review gates for code, dependencies, and embedded access logic. Practitioners should assume the blast radius grows with each unattended iteration.

Named concept, AI control omission risk: the central failure mode here is that AI-generated code can omit security decisions entirely while still satisfying the functional requirement. That should become a first-class governance category, not a generic code-quality concern. Security leaders should classify missing controls in generated code as a production risk with identity implications, especially where the code handles authentication, session state, or data access.

What this signals

Vibe coding pushes application teams into a world where security review has to move closer to code generation. That creates a practical governance shift for AppSec programmes, because the control point is no longer only at merge or release. The review model now has to catch missing access checks, credential leakage, and untrusted dependencies while the change is still being authored.

Control omission risk: when an AI writes functional code without a security model, the safest interpretation is that identity and access controls may be absent rather than merely imperfect. That is why organisations should align development workflows with NIST SP 800-53 and the NIST Cybersecurity Framework 2.0, especially for authentication, authorisation, and secure configuration practices.

For practitioners

• 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.
• Review prompt input as a security boundary Prohibit pasting secrets, architecture diagrams, and privileged workflow details into assistants that can persist context or echo sensitive material into generated output.

Key takeaways

• Vibe coding turns missing security logic into a repeatable production risk, especially where access control and secrets handling are concerned.
• The evidence is not anecdotal: published studies and real incidents show that AI-generated code can leak credentials, invent dependencies, and expose user data.
• Security teams need review gates, dependency controls, and identity-aware code inspection before AI-generated changes can reach production.

Key terms

• Vibe Coding: A software development approach where natural-language prompts generate application code with minimal manual writing. The security challenge is that the output may be functional but still omit access controls, safe defaults, or trust checks that human authors would normally add.
• Hallucinated Dependency Provenance Gap: The hallucinated dependency provenance gap is the difference between a package name that appears credible and a package origin that has never been verified. It becomes dangerous when model suggestions, automation, and install-time execution let plausibility outrun source validation.
• 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.
• 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.

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.

👉 Arnica's full post covers the incident examples, vulnerability patterns, and mitigation steps in more implementation detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to modern development and deployment workflows.