Enterprise vibe coding: the security risks and how to govern it
Gartner predicts that 90% of enterprise software engineers will use AI code assistants by 2028, up from less than 14% in early 2024. That shift inside engineering teams is well documented. What gets less attention is the parallel shift happening outside engineering entirely.
Finance analysts, ops managers, and marketing leads are now building and deploying working software using tools like Lovable, Bolt, v0, Replit, Claude, and ChatGPT. They describe what they want in plain English, and the tool generates a real, running app. No engineering background required. No ticket in the backlog. No waiting.
That speed is real. So is the risk. This guide covers what enterprise vibe coding actually is, the three failure modes that create the most exposure, and a concrete checklist for IT and security teams who want to bring it under control.
What enterprise vibe coding actually is
Enterprise vibe coding is non-developers inside a business using AI tools to build working software from natural-language prompts. The person describes the outcome they want, and the tool generates real, deployable code: a web app, an internal dashboard, a script, or an automation.
The examples from the real world look like this:
- A finance analyst generates an internal web app that reconciles data across two spreadsheets.
- An ops manager automates a weekly report pulling from Salesforce, Slack, and a shared drive.
- A marketing lead builds a campaign dashboard that reads from three systems and surfaces performance in one view.
In each case, someone with no formal development background produces working software that touches real customer, financial, or operational data. The build might take an afternoon. The deployment determines whether the business can safely use it.
This is different from low-code and no-code tools, which assemble apps from visual blocks. Vibe coding uses AI to generate actual source code from natural-language prompts, which changes both what gets produced and how it needs to be governed.
Why it’s growing fast
Lovable’s June 2026 Build Economy report found that 80% of people building on its platform identified as non-technical. These users were creating internal tools, CRMs, inventory systems, HR platforms, and e-commerce applications. The Lovable CEO also reported that more than half of Fortune 500 companies now use the platform, with customers including Klarna and HubSpot.
Four things are driving the adoption:
- Near-zero cost to start. Most platforms have free or low-cost entry tiers. A team can try one without a procurement conversation or a manager’s sign-off.
- Plain-English operation. If you can describe what you want, you can build it. The LLM handles the rest.
- Real backlog relief. Internal software requests that used to sit in an engineering queue for months can now be answered in an hour by the person who needed the tool.
- Social proof everywhere. Non-technical builders see finished projects on LinkedIn, Reddit, X, and YouTube daily, and the message is clear: a marketer built this over a weekend, so you can too.
⚠️ The three risks that matter most
1. The app runs somewhere IT doesn’t control
Many vibe-coding platforms make external hosting the easiest next step. A user can publish a finished app to the platform’s own hosting environment, a public cloud service like Vercel, Netlify, or Fly.io, or a personal or departmental cloud account that IT doesn’t monitor.
Once the app sits outside sanctioned infrastructure, none of the organization’s normal controls reach it. No required network policies, no resource quotas, no identity provider, no centralized logging, no vulnerability scanning, no central shutdown controls. If the app is misconfigured, compromised, or abandoned, the security team may only find out after an incident.
2. The code has vulnerabilities and too much access
Veracode’s 2025 GenAI Code Security Report tested more than 100 large language models across 80 coding tasks and found that 45% of AI-generated code samples introduced OWASP Top 10 vulnerabilities, most commonly cross-site scripting and log injection.
Without an approved deployment process, a vibe-coded app may also store database credentials and API keys insecurely, use over-scoped tokens that grant more access than the app needs, and connect to internal systems without any documented least-privilege review. A flaw in a simple marketing dashboard could expose the customer, financial, or operational data the app was designed to access.
3. Nobody knows the app exists, and nobody can audit it
IBM’s 2025 Cost of a Data Breach Report found that one in five organizations had experienced a breach involving shadow AI. Organizations with high levels of shadow AI faced breach costs averaging $670,000 more than those with little or no shadow AI.
Ungoverned vibe coding extends the same problem from AI tool usage to application deployment. IT may not know who built the app, where it runs, what systems it connects to, what data it processes, or whether anyone is still responsible for maintaining it. Frameworks like GDPR, HIPAA, and SOX require organizations to demonstrate where regulated data is stored, who can access it, and what controls protect it. An app outside the inventory makes that evidence much harder to produce.
️ How to govern it: three controls
Governing enterprise vibe coding means putting a deployment layer between the builder and production, one IT configures once, and every AI-built app has to pass through.
1. Route every deployment onto infrastructure the organization already controls
Vibe coding platforms default to their own hosting or a personal cloud account. A governed path routes every deployment onto the Kubernetes clusters the organization already runs, whether those sit in the corporate cloud tenancy, an on-premises data center, an edge site, or an air-gapped environment.
The builder doesn’t see the cluster, doesn’t touch infrastructure, and doesn’t choose where the app runs. IT has already made that decision on their behalf.
2. Bind access to policy, not to whatever the AI tool hardcodes first
In an ungoverned deployment, the builder or the AI tool picks the credentials, API tokens, and database access, usually by hardcoding whatever works first. A governed model handles this through four controls IT sets once:
- Scoped personal access tokens tied to the builder’s identity, authorizing deployment and nothing else.
- Centrally managed RBAC governing access inside the resulting namespace.
- Resource quotas and namespace isolation enforced automatically at deploy time.
- IT-scoped secrets for every credential. If the app needs a database connection or an API key, it draws from a secret IT scoped in advance. Nothing gets hardcoded by the AI tool or pasted in by the builder.
3. Make every app visible, auditable, and reversible
A governed deployment path has to guarantee three things: a central inventory of every vibe-coded app in the organization, a complete audit record tying each deployment to a builder identity and a Git commit, and a one-click rollback IT can execute without depending on the original builder.
Ownership also needs to be durable. When an employee changes roles or leaves, the app they built should remain as standard source code in a sanctioned Git repository and a standard Kubernetes workload. IT can reassign it, update it, or retire it without asking the original builder to recreate anything.
✅ Enterprise vibe coding security checklist
Establish visibility
- Audit for existing shadow vibe-coded apps. Ask team leads which internal tools were built with AI in the last six months. Check expense reports for recurring charges from platforms like Lovable, Bolt, v0, and Replit.
- Map what data each app touches. Document the systems it connects to, the credentials it uses, and the customer, financial, or operational data it can reach.
Reduce exposure
- Approve a sanctioned vibe coding tool list. Officially bless one or two platforms, communicate the list to staff, and clarify what falls outside policy.
- Define approved deployment targets in Kubernetes. Decide which clusters and namespaces vibe-coded apps can deploy into.
- Publish a review-and-sanction path. Give business builders a clear route for getting an AI-built app promoted into governed infrastructure. Without one, the safe route becomes the slow route.
- Give builders a guide on what not to put in their prompts. Tell business teams which data they can’t paste into a vibe coding tool: credentials, customer records, and anything under a regulatory obligation.
Sustain governance
- Add vibe coding platforms to your CASB and expense monitoring so future shadow usage surfaces automatically.
- Extend your incident response plan to cover vibe-coded apps. Assign an on-call owner for AI-built apps in production and add a takedown procedure that security can execute without needing the original builder.
Work through that list top to bottom and enterprise vibe coding moves from an ungoverned risk into a managed part of how your business builds software.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
