TL;DR: Vibe coding is widening security blind spots as AI-assisted development moves from prompt to production, according to Pluto Security, with weak authentication, over-permissioned components, missing logging and hardcoded credentials among the recurring risks. The control gap is not the code generator itself but the loss of design review, ownership and visibility around AI-produced software.
At a glance
What this is: Pluto Security argues that vibe coding speeds up software delivery but pushes security decisions into code that teams often do not fully understand or govern.
Why it matters: For IAM and security practitioners, the key issue is that AI-generated software can bypass normal control design, creating brittle authentication, privilege and accountability assumptions that later spread into production.
Context
Vibe coding is the practice of building software from intent and prompts rather than from fully specified design and implementation work. That shift matters because security assumptions that used to be captured in architecture reviews and code review can disappear when code is produced quickly by AI tools or non-developers.
The governance problem is not just speed. It is the gap between who creates the software, who understands its security properties, and who is accountable when AI-generated code ships with missing controls or broad access paths. That gap becomes sharper where development workflows intersect with AI coding agents and CI/CD automation.
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 does vibe coding increase application security risk?
A: Because it increases the volume and speed of code changes faster than traditional review and scanning can absorb. That compresses decision time, expands dependency usage, and makes exposure harder to track. The risk comes from scale and timing, not from AI alone.
Q: What are the signs that AI-assisted development is being used without adequate security controls?
A: Common warning signs include high volumes of generated code, limited human review, security checks arriving late in the SDLC, and developers shipping faster because security feels optional. The article also points to insecure or incorrect generated output and teams relying on AI for prototyping and production without compensating controls. Those conditions usually mean risk is being shifted downstream.
Q: How should organisations govern AI tools that analyse source code?
A: Set evidence thresholds, require secondary validation for high-impact findings, and define who owns the final decision. Governance should cover prompt scope, output format, reviewer sign-off, and auditability. That keeps AI in an advisory role and prevents noisy model output from becoming an unreviewed security decision.
Technical breakdown
How AI-generated code changes the security control surface
Vibe coding changes the control surface because the software is no longer authored through a slow, inspectable engineering process. The article points to inherited vulnerabilities, missing architecture controls and over-permissioned defaults as the main failure modes. In practice, this means the security problem shifts from finding a single bug to governing the entire path from prompt to deployed artifact, including how code is produced, reviewed, tested and promoted. When developers do not fully understand generated logic, traditional assurance checks become thinner and less reliable. See the Secure Software Development Lifecycle (SSDLC) Guide.
Practical implication: Treat AI-generated code as a distinct assurance class and require security review before it reaches production.
Why visibility fails when AI tools sit inside the SDLC
Visibility breaks when teams cannot reliably tell which parts of the codebase were generated, which tools were used, and what security assumptions those tools introduced. The article’s recommended controls, such as inventorying AI usage and tagging AI-generated artefacts, are essentially provenance controls for software. Without them, teams cannot target review effort, detect risky patterns consistently, or separate human-authored code from machine-produced output. That makes downstream monitoring necessary, but not sufficient, because runtime controls only see symptoms after deployment.
Practical implication: Build provenance and traceability into the SDLC so security teams can govern AI-generated artefacts before release.
Why AI-generated software can create identity and privilege risk
The identity angle appears when AI-generated code defaults to broad permissions, weak authentication logic or missing authorization checks. Those choices are not merely coding defects; they are access-control decisions embedded into software at scale. In identity terms, the result is often over-permissioned application behaviour, hidden trust assumptions and access paths that no one explicitly approved. That is why least privilege, strong authentication and runtime inspection matter here even when the primary problem looks like software quality rather than identity governance. See the Secure Coding Guide.
Practical implication: Review application-generated permissions and authentication paths as identity controls, not just as code quality issues.
Threat narrative
Attacker objective: The attacker aims to exploit insecure AI-generated software to gain access, bypass controls or abuse exposed application and cloud resources.
- Entry occurs when AI-assisted development introduces code that inherits insecure patterns, omits security checks or provisions overly broad access by default.
- Escalation follows when those weaknesses reach production, where missing authentication, broken authorization or hardcoded credentials expand what an attacker can access.
- Impact occurs when exposed applications, endpoints or cloud resources become easier to abuse, creating an enterprise-wide security gap rather than a single isolated flaw.
Breaches seen in the wild
- Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
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 creates governance debt, not just engineering debt: the core issue is that speed-intensive AI development shifts security decisions into workflows that are often under-reviewed and poorly attributed. When teams cannot explain who approved a generated control path, they also cannot prove that the path is trustworthy. That makes software governance a first-class security problem, not a follow-on review task.
Security visibility now has to include code provenance: inventorying AI tools and tagging AI-generated artefacts is more than documentation hygiene. It is the minimum condition for knowing where security controls were machine-shaped rather than human-designed, which is crucial when different artefacts carry different trust assumptions. Practitioners should treat provenance as an operational control, not a reporting convenience.
Identity failures in vibe coding are often default-state failures: the article shows how over-permissioned components, weak authentication and absent authorization emerge when functionality outruns design discipline. That is an identity governance issue because the code itself is making access decisions without the same scrutiny applied to human-built systems. Teams should assume access design is leaking into software unless they explicitly govern it.
AI-assisted development should be governed like a new software class: comparing it with ordinary development underestimates the combined effect of model inheritance, prompt-driven generation and low-friction deployment. The right response is not a ban, but a new control model for review, ownership, logging and runtime monitoring. Organisations that keep using legacy assurance assumptions will keep discovering the gaps only after production exposure.
From our research library:
- 96% of security operations teams report critical blind spots, most commonly in cloud infrastructure (74%) and identity and access behaviour (67%).
- Read next: Secure Software Development Lifecycle (SSDLC) Guide
What this signals
Provenance control becomes the new baseline: the more software is generated from prompts, the more security teams need to know which artefacts were created by AI, which were edited by humans, and which controls were assumed rather than tested. Without that chain of custody, governance turns into guesswork rather than assurance.
The visibility problem is already measurable in adjacent identity and cloud operations: only 5.7% of organisations have full visibility into their service accounts, which shows how quickly asset sprawl outruns oversight once ownership and inventory are weak. Vibe coding risks creating the same pattern in software delivery, only faster.
Control design has to move upstream: if security waits until production monitoring to compensate for weak review, it is already reacting too late. The better model is to bake review, tagging, scanning and ownership into the delivery path so that generated code cannot silently escape policy.
For practitioners
- Inventory every AI development workflow Map which teams, tools and pipelines are generating code so you can apply the right review and scanning controls to the right systems. See the AI Coding Agents Security Guide.
- Tag AI-generated code and commits Label repositories, pull requests and build artefacts that include generated code so reviewers can trace provenance and separate human-authored logic from machine-authored logic.
- Add mandatory security review to generated changes Require peer review and security review for AI-generated code before merge, with special attention to authentication, authorization, logging and error handling.
- Enforce secrets and dependency scanning in CI/CD Run SAST, SCA and secrets detection on every build, because AI-generated code can embed vulnerable patterns or credentials that developers do not notice during prompt-based creation.
- Assign clear ownership for AI-generated systems Make one accountable owner responsible for the behaviour, maintenance and security of each AI-generated application so accountability does not disappear when the code was generated quickly. See the Agentic AI Security Policy Template.
Key takeaways
- AI-assisted development can create software that works functionally while still carrying unresolved authentication, authorization and secrets risk.
- The article’s central warning is about visibility and accountability, not just code quality.
- Strong review gates, provenance tracking and runtime monitoring are the controls most likely to limit the blast radius of AI-generated software.
Related NHI Mgmt Group resources: AI Coding Agents Security Guide · Agentic AI Security Policy Template · Secure Software Development Lifecycle (SSDLC) Guide · Firebase misconfiguration exposure 2024
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | AI-assisted coding tools can generate insecure logic and inappropriate control paths. |
| ASI03 — Identity & Privilege Abuse | The article highlights over-permissioned components and missing authorization in generated code. | |
| Recommendation — Constrain agent and assistant tool use so generated code cannot bypass security review or approved patterns. Review generated code for overbroad permissions and enforce least privilege before release. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | AI-generated workloads and components often default to excessive permissions and access scope. |
| Recommendation — Audit AI-created service accounts and runtime identities for excessive privileges before production. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article’s core issue includes broad permissions and weak authorization controls in generated code. |
| Recommendation — Apply PR.AA-05 to constrain permissions and verify authorization paths in AI-generated software. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Hardcoded credentials and secrets exposure map directly to credential lifecycle control failures. |
| Recommendation — Use IA-5 to govern, rotate and revoke credentials embedded in AI-generated artefacts. | ||
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.
- 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.
- Code provenance: Code provenance is the verifiable history of where code came from and who or what created it. In security practice, it combines authorship, timestamps, signatures, and build lineage so teams can prove a change was trusted before it reached production.
- Security Visibility: Security visibility is the ability to see what software, identities, dependencies, and behaviours exist across an environment well enough to make informed decisions. It includes knowing what code is being generated, what tools are in the stack, and where trust assumptions can fail before they become incidents.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity and secrets management. It helps security and IAM practitioners build the governance skills needed to control machine-generated access and automation.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org