A founder bragged he shipped his startup without writing a single line of code. Days later, his production database was fully exposed. API tokens, emails, and private agent messages were all readable by anyone with a browser. He relaunched. It happened again.
He is the pattern, not the outlier. Veracode's GenAI Code Security Report found that 45% of AI-generated code samples failed security tests, and an analysis of 380,000 vibe-coded apps revealed more than 5,000 with no authentication. Around 40% exposed medical, financial, or strategy data. These apps sit outside every choke point AppSec relies on: no repo to scan, no PR to gate, no owner to email.
This article maps what actually breaks, why scanners miss it, and what governance requires. Post-breach governance is forensics. A faster paved road prevents exposure.
How AI-generated code fails: the core security gaps
AI coding models aim for runnable code and often omit attack-resistant design. Models generate syntactically correct code with no awareness of the environment's trust boundaries or the data classification and regulatory rules under which the code will operate. The model learned from vast codebases, including insecure ones, without the defensive instincts an experienced engineer builds over years.
The recurring failures fit a short list: missing access controls, database keys exposed in client-side JavaScript, dependencies that don't exist in any package registry, and production data readable by anyone with a browser.
Unreviewed software built with a large language model (LLM) is vibe coding; reviewed AI output is ordinary software development. Treating unreviewed AI-generated code as trustworthy creates an emerging risk.
Review must intervene before model output ships. Even the best-performing models still introduce vulnerabilities at meaningful rates, and independent testing shows pass rates plateauing rather than improving. The model's default output still carries defects that fall into a short, repeatable list.
The vulnerability classes vibe coding reliably produces
Vibe-coded apps don't fail in creative new ways. They fail in the same handful of ways, over and over, because the model draws on training patterns that treat "the code runs" as the finish line.
Five categories account for most of the exposure teams encounter in production, starting with broken access control, where unreviewed code treats a working endpoint as a safe endpoint:
Broken access control and authorization: Generated endpoints ship with missing authorization checks and insecure direct object reference patterns.
Hardcoded secrets: GitGuardian's Secrets Sprawl 2026 report counted 28.65 million hardcoded secrets added to public GitHub in 2025, a 34% year-over-year jump and the largest single-year jump in the report's five-year history. In GitGuardian's data, AI-assisted commits leak secrets at 3.2%, compared to a 1.5% baseline.
Injection flaws: Veracode's testing across 150+ models found LLMs failed to prevent cross-site scripting 85% of the time and log injection 87% of the time.
Cryptographic failures: Crypto failures also recur, often traceable to insecure patterns in training data.
Hallucinated dependencies: Models can hallucinate package names often enough to make attacker registration practical. The attack is slopsquatting.
These apps often reach production before engineering can establish the trail it normally relies on. These vulnerability classes compound because the usual remediation instinct (asking the AI to fix its own output) makes the code worse.
Why the risk compounds with every AI fix-it iteration
Prompting an LLM to iteratively improve its own code degrades security. A 2025 study ran 400 code samples through 40 rounds of AI "improvements" across four prompting strategies and measured a 37.6% increase in critical vulnerabilities after five iterations, a phenomenon the authors termed "feedback loop security degradation."
Developers may miss the feedback loop because the code appears to improve: "Each iteration generally produced code that appeared more sophisticated, despite being associated with new vulnerabilities. This creates a potential illusion of improvement that may lead developers to trust problematic code."
When security relies solely on soft prompts, the model drifts away from the security constraint. Models also repair their own mistakes poorly when asked to judge self-produced code.
Duplicated code spreads vulnerable patterns across files. When a developer asks the AI to "fix the SQL injection," the model patches the instance in context while identical copies survive elsewhere.
Shadow code: when AI-generated apps bypass security entirely
Non-developers who vibe code apps deploy straight to the public internet without ever passing through IT or security. Many vibe coding users work outside engineering, accidental programmers shipping working applications on their own. A production Supabase anon key traced back to an ownerless marketing app shows the shape of this problem.
RedAccess CEO Dor Zvi analyzed roughly 380,000 publicly accessible applications built on platforms like Lovable, Replit, Base44, and Netlify and found more than 5,000 apps with virtually no security or authentication; around 40% of those exposed sensitive data, including medical and financial information. Corporate strategy documents were exposed too.
The scale matters because modern enterprises typically connect dozens of internal systems through their automation layer; an ungoverned app can quietly plug into the same environment and access data it was never scoped to touch.
Full-lockdown approaches can push development toward spreadsheets and other ungoverned tools instead. A sanctioned path has to be fast enough to beat the workaround: if the approved route takes weeks and the shadow route takes an afternoon, builders will pick the afternoon every time.
That means the governed alternative has to match the speed of the app-builders it's replacing, expose the same kind of drag-and-drop composition for non-developers, and cover the common integrations (identity, HRIS, ticketing, data warehouse) out of the box. Otherwise the shadow layer keeps growing regardless of policy.
How to minimize vibe coding security risks
The failure modes above cluster around a handful of controls that either don't exist or aren't enforced. Teams that have reduced exposure without banning AI-generated code tend to apply the same short playbook:
Build the inventory first. You can't govern what you can't see. Combine network monitoring, endpoint telemetry, and platform-level reporting from the app builders your teams use (Lovable, Replit, Base44, Netlify, Supabase) so every AI-built app is recorded with an owner, the data it touches, and the date it was last reviewed.
Assign a named human owner to every app that reaches production. Ownerless apps are the ones that leak. The owner signs off on data access, gets the alerts, and is accountable for retiring the app when the use case ends.
Enforce non-bypassable gates on any code path that ships. Mandatory SAST on AI-touched files at pull-request time, dependency scanning for anything the model introduced, and secrets detection before merge. None of these should be overridable by the requester.
Prohibit DIY authentication and cryptography. Require every app to use a sanctioned identity provider (E.g., Okta or Entra) and vetted crypto libraries. Model-written auth is one of the most reliable sources of broken access control in this category.
Separate development from production, and require human confirmation for destructive operations. The database-deletion incidents in this category almost always involve an agent with production credentials and no confirmation step.
Cap iterative self-repair loops. Because feedback-loop degradation increases critical vulnerabilities across successive AI "improvements," treat any change beyond a small number of model iterations as requiring fresh human review rather than another prompt.
Give non-developers a governed build surface. The single highest-leverage control is offering an approved, fast alternative to public app-builders — one where credentials, integrations, audit trails, and approvals are enforced by the platform rather than by the builder remembering.
None of these controls are novel. What's new is applying them to code the organization didn't previously recognize as code.
What governing AI-generated code actually requires
Security teams need an inventory before they can set policy, because teams can't govern what they can't find. Lenny Zeltser, a cybersecurity executive and SANS Faculty Fellow who previously built the security program at Axonius, recommends automating discovery through network monitoring and endpoint agents, with platform-level reporting feeding the same inventory.
That inventory records who built each app and what data the app touches. It also records the date someone last updated it. SecurityWeek's assessment of the block-it instinct is blunt: "That instinct is wrong. AI-driven development is not something organizations can or should block."
Fragmentation is the second problem. Governance controls scattered across a dozen tools rarely add up to a policy anyone can enforce; each tool covers a slice of the lifecycle, ownership sits in different teams, and the gaps between them are where unreviewed apps quietly accumulate.
Mature programs converge on a small set of non-negotiable gates:
Mandatory static analysis on every AI-touched file at pull request time.
Dependency scanning covering anything the model introduced.
Secrets detection before merge, with no bypass option.
No DIY authentication or cryptography — sanctioned identity providers and vetted libraries only.
AI agents confined to dev and test, with a named human owner on every line that ships to production.
Governance holds when the sanctioned build surface enforces it by default, rather than asking builders to remember. In practice, that means the platform where non-developers build internal apps handles credentials centrally rather than embedding them in client bundles, records every run in an audit trail, keeps test and live environments separate, and requires human-in-the-loop approval at the steps that touch production data or write back to systems of record.
Deterministic automation and AI-driven agentic steps should run on the same surface under the same controls, so the guardrails don't disappear the moment an AI step enters the workflow. The point isn't the tool. The point is that governance has to be a property of the environment, not a checklist for the builder to remember.
Closing the velocity-capacity gap
AI code output outpaced security review capacity, and the gap filled with unreviewed apps holding real data. The flaws that matter most — authorization logic and business rules — are the ones scanners were never built to catch, which means closing the gap means changing where building happens, not just how carefully it's reviewed.
An AI-native environment built for this handles the part that's hard to bolt on afterward: someone who would otherwise vibe-code an app on an ungoverned platform builds it instead on a surface where credentials stay out of client bundles, every run lands in an audit trail, and human approval sits at the steps that touch production data. Builders keep the hours-not-months speed. Security keeps visibility over who owns each app and what it touches.
Post-breach governance is forensics. A faster, governed path is what actually prevents the exposure. See how it works.
Frequently asked questions
What separates vibe coding from AI-assisted development?
Review. Once someone reads the diff, tests it, and can explain how it works to a colleague, the work stops being vibe coding and becomes ordinary development. Practitioners run reviewed AI output through normal AppSec processes and add extra controls for unreviewed output.
How does AI-generated code compare to human-written code on security?
Veracode's GenAI Code Security Report found high rates of flaws in AI-generated code, with 45% of samples failing security tests. Humans write insecure code, too; in practice, review separates the two bodies of work.
What do standard SAST tools miss in AI-generated code?
Authorization and business logic flaws, the largest category in vibe-coded apps. Standard SAST and dynamic application security testing (DAST) tools consistently miss these categories. Teams need custom rule sets for AI-touched changes, plus dependency and secrets scanning. Runtime validation has to sit on top of static tooling.
How does the EU AI Act affect governance of AI-generated code?
The EU AI Act treats AI systems used in critical infrastructure, employment, and financial services as high-risk, which raises the documentation and human-oversight bar for any AI-generated code operating in those contexts. Practical implication: the inventory, named-owner, and audit-trail requirements described above stop being best practice and start mapping to compliance obligations. Teams operating under NIS2 or DORA face parallel requirements around secure development lifecycle and operational resilience for automated systems.
How should organizations respond to vibe coding tools?
Blocking tool categories pushes workarounds. Programs that hold up start with an inventory: every AI-built app that touches company data needs a named owner. The inventory should also record what systems the app reaches and when someone last checked it. Teams gate high-risk changes after the inventory exists, not before.