Vibe coding coverage focuses on insecure code, but the bigger exposure is organizational: AI lets anyone build and deploy working software outside the software development lifecycle (SDLC), with no owner, no inventory, and no way to retire it.
Consider Moltbook. It launched as an AI social network whose founder publicly stated he "didn't write a single line of code." Three days later, Wiz Research found the app had exposed its entire production database, including 1.5 million API tokens and 35,000 email addresses.
The headline read like a code failure, but the underlying breakdown was organizational: no owner, no inventory, no review. That is the pattern this article unpacks, and the governance model that closes it.
What are vibe coding risks?
Vibe coding risk is the organizational exposure created when AI lets anyone build and deploy working software outside the SDLC, without formal inventory or accountability. Insecure code is its most visible symptom. The term was originally coined to describe throwaway weekend projects, but the enterprise version has since expanded far beyond that scope.
SecurityWeek's reporting describes staff in marketing, operations, and finance building live applications connected to production systems with little involvement from IT or security. Hostinger's data show non-developers make up the majority of vibe coding users, and Gartner projects citizen developers will substantially outnumber professional engineers.
Veracode's GenAI Code Security Report found that a substantial share of AI-generated code failed security checks even as syntactic correctness rose sharply. The code compiles while the security profile stays flat. RedAccess found thousands of publicly accessible applications and assets with virtually no security or authentication. As Danelle Au put it in SecurityWeek, the employee here is deploying a live application beyond the detection capabilities of the existing security stack.
This is the "wild code" problem: ungoverned AI-built applications spreading through shared API keys, unsanctioned data uploads, and shadow IT nobody signed off on.
Three vibe coding risks most guides overlook
Most vibe coding guides stop at code quality and skip the three risks that actually determine whether AI-built software survives its first year in production.
Each one compounds the last: applications ship without a governance boundary, the reviewers meant to catch problems lack the depth needed to do so, and the institutional knowledge behind those applications leaves the moment a builder changes roles. They explain why "the code works" is the wrong finish line.
1. Shadow IT that ships live applications
The Cloud Security Alliance draws the distinction: traditional shadow IT meant adopting approved-category services through unapproved vendors. Vibe coding "changes its character" because the artifact is a live application.
It also helps to separate two behaviors that get lumped together. Shadow AI is the use of an unapproved tool. Shady AI is the use of an approved tool in unapproved, unexpected, or poorly governed ways, e.g. ChatGPT is sanctioned for employee use, but an employee feeds it sensitive customer data. One is an unapproved tool; the other is approved tool, unapproved use. Both feed the wild code problem, but they need different controls: shadow AI calls for discovery, while shady AI calls for usage policy and monitoring inside tools the organization already owns.
The distinction between shady AI and wild code matters too. Shady AI is ungoverned behavior, what people do with sanctioned tools. Wild code is ungoverned output, the artifacts of ungoverned building that compound over time. Wild code may originate from shady AI, from sanctioned vibe coding, or from AI-assisted development inside the SDLC. The behavior and the artifact each need their own governance response.
Network monitoring designed to flag subscriptions may miss it. Many CIOs have already discovered unsanctioned AI use for work tasks, and because prototypes that once took weeks now take hours, the window for AI governance review is shrinking toward zero.
The cost appears in the breach data. Shadow AI incidents are increasingly common in breached organizations and are associated with higher recovery costs, and most affected organizations have no AI governance policy in place at all. Unauthorized AI services can also remain active for long stretches before anyone notices.
In practice, discovery often begins with an invoice line item or a link a colleague drops in Slack. It may also arrive as an outage in something live that no team provisioned and no one can find in the configuration management database (CMDB).
2. Skills erosion in the people who must review the output
Anthropic's randomized controlled trial found developers using AI coding assistance scored 17% lower on comprehension tests than those coding manually. GitClear's longitudinal data from 2022 to 2026 show maintainability signals sliding backward, with refactoring line moves down by 70%.
Review gates only work if reviewers still understand what they approve. Review volume is climbing while comprehension lags. The effect is cumulative rather than immediate. Engineers who used to trace an unfamiliar function back to its dependencies now approve pull requests where the AI's rationale is opaque and the reviewer's own mental model of the codebase has thinned.
Junior engineers, in particular, skip the debugging cycles that once built pattern recognition, and senior engineers stop investing time in reviews they trust the model to have handled. The result is a review process that looks unchanged on paper but produces weaker decisions, which is exactly the failure mode governance controls are supposed to catch.
3. Knowledge loss: apps that outlive their builders
AI-assisted coding has become one of the most common uses of AI at work, yet only a minority of organizations have established governance and accountability frameworks for it. Teams usually find the app when it breaks, because it stopped writing to a table nobody documented and the person who built it moved to another org months ago.
Autonoma AI's study of millions of pull requests found that technical debt rose substantially after AI coding tool adoption, with the increase concentrated in duplicated logic and "functions that work but whose logic nobody can reconstruct."
When the person who vibe-coded a campaign dashboard changes roles, the app keeps running against production data. Nobody left behind can maintain or patch it, and in many cases nobody can find it.
What governing vibe-coded software actually requires
OWASP and NIST converge on controls for assigned human ownership and role-based access control. ISO does as well, and audit trails must capture what the AI actually did. Deloitte's State of AI in the Enterprise found that mature governance models for autonomous AI agents remain uncommon. In Tines' Voice of Security 2026 survey of 1,813 security professionals, 66% of teams with a formalized AI policy reported being "very optimistic" about AI's impact.
Snowman Labs' governance model states the ownership requirement cleanly: "an agent can author a diff, but a named person is always accountable for the merge." OWASP's Excessive Agency risk refers to the role-based access control pattern in which AI components hold permissions far beyond the task at hand. OWASP's example is an extension that can modify and delete documents when the task only required reading them.
Audit trails must cover AI activity as well as admin actions. Re-entry.ai flags a gap many programs miss: GitHub Copilot Enterprise's audit logs cover admin actions and policy changes. They omit records of "what Copilot suggested and what got merged."
Excessive Agency incidents in production show the same permissions pattern: AI agents taking destructive actions on records far outside the scope of the task they were given, sometimes despite explicit instructions to hold changes. Portainer notes that a properly governed app stays "as standard source code in Git and a standard Kubernetes workload." IT can reassign or update it, and can retire it without the original builder.
These controls apply only to applications in the inventory. The CSA therefore recommends a low-friction registration process for citizen-built apps focused on awareness and minimal gatekeeping. Lior Zeltser argues oversight should scale with the data each app touches. Inventory-first is what separates governing from banning.
How teams govern AI-generated code across engineering, security, and IT
Effective governance splits by builder. For professional engineers, the controls live in the pipeline. Accidental programmers, the non-developer builders who make up most vibe coding users, need controls in the platform they build on.
Engineering and security: Use mandatory review gates with branch protection and provenance labels. Add secrets scanning at the IDE boundary. After outages linked to AI coding assistants, Amazon required senior engineers to sign off on AI-assisted changes made by junior and mid-level engineers. Security teams add data loss prevention at the API gateway to catch apps routing business data to external large language model (LLM) providers.
Non-developer builders: The controls must run by default. Tines 3B runs AI-generated agents, apps, and automations in a code-first environment with built-in credential protection and monitoring, so RBAC and audit trails apply automatically rather than being retrofitted after deployment. Exceptions route to Tines Cases, and Tines' principles for designing AI workflows keep execution governed.
IT inventory: On the IT service management side, create a ticket for each discovered app. The record has an owner, data classification, and review date. A scheduled workflow re-checks lapsed entries. The governed surface must reach every team building.
Pipeline controls and a governed build surface let teams preserve build speed. A maintained inventory retains ownership and visibility.
Governance priorities for security and IT leaders
The unit of risk has shifted from the line of code to the application nobody knows exists. If Gartner's projection holds, unowned applications will multiply faster than any review queue can keep up with. To keep pace, the speed builders already have must be matched with enforceable governance.
Tines 3B addresses the wild code problem directly, giving teams a code-first environment where AI-generated agents, apps, and automations run with built-in credential protection and monitoring, rather than bolted on after the fact.
Turn the inventory into action. TechTarget's guidance is to start with inventory, with policy following and to frame the work as an ask rather than a ban. Classify each app by the data and infrastructure it touches, then assign an owner. Give builders somewhere sanctioned to go next. The Tines 3B Explore Edition is free and gives teams a sanctioned place to build with AI from day one.
Frequently asked questions
How does AI-generated code compare to human-written code on security?
At meaningful rates, AI-generated code is less secure. Veracode's benchmark testing found that a substantial share of AI-generated code samples failed security tests, and Stanford's user study found that participants who used an AI assistant wrote significantly less secure code while being more confident it was secure. Functioning code feels finished, even without authentication or access controls.
Which methods surface vibe-coded apps already running in an environment?
The fastest surfacing method is asking team leads which internal apps their teams recently built with AI, then checking expense reports for recurring charges from platforms like Lovable, Bolt, v0, and Replit, an approach Portainer recommends. What surfaces should then be classified by the data and infrastructure they touch, so that a public data dashboard receives lighter oversight than an application handling financial records.
Who is accountable when AI-generated code causes a production incident?
A named human, always; Stack Overflow's guidance is to "make it clear that humans own AI-generated code." The harder problem is that a senior engineer can approve output they don't fully understand, and when something later breaks, nobody can reconstruct why that decision was made. Sign-off policies need provenance records alongside an approver's name.
How does the EU AI Act change AI-generated code governance?
The Act applies when the resulting application falls within a regulated use case. Annex III regulates specific use cases; ordinary developer assistance has a different scope. Scope follows what an application does, regardless of whether AI wrote the code. An obligation check rests on the same inventory and accountability records the governance work produces.