Why vibe coding security is the next enterprise nightmare

Vibe coding is no longer confined to pet projects. It has become a widely accepted corporate practice. According to Gartner, enterprises will use vibe coding techniques and tools to create 40% of new production software by 2028. People who are completely removed from software development are suddenly building landing pages, internal analytics dashboards, and CRM automation tools that previously required weeks of dedicated engineering time.

Both the practice and its results are risky. These apps bypass traditional security reviews, wire autonomous agents directly to production data, and dump an unmanageable mess onto overwhelmed AppSec teams. Vibe coding security is the practice of governing how employees build software with AI, so the apps they ship do not bypass authentication, leak secrets, or hand autonomous agents access to production data.

Vibe coding platforms vs AI coding agents

Professional developers skew toward the term “agentic engineering”, but the broader industry has embraced “vibe coding” as an umbrella term. The buzzword hides and conflates two related but very different practices. Both bypass your current security stack, and they do it in completely different ways.

Builder platforms: AI development in the box

These are platforms like Lovable and Base44, and they do more than generate working apps from text prompts. They host the apps, own the authentication, manage the database, and set the deployment defaults. Every tenant automatically inherits the vendor’s security posture. Subscriptions start cheap enough for individuals to expense without a second thought, which raises serious concerns about enterprise readiness from a compliance standpoint.

Coding agents: the pro stack with less oversight

This practice uses the same tools professional developers use (Claude Code, GitHub, Cloudflare), but with far less rigor. Professional developers can build intricate processes to control what the agent does and what result it achieves. Amateur builders mostly check one thing: whether the app looks operational. As OWASP notes, agentic coding tools are optimized to operate autonomously for as long as possible, executing shell commands, installing packages, editing files, and accessing networks. Many developers, especially non-professional ones, run these agents with auto accept enabled, which means the agent operates with the developer’s full permissions and almost zero human oversight.

This second practice is where AI coding agent security as a discipline applies directly: the tools are the professional ones, so the controls that work for engineering teams work here too, once someone turns them on.

The vibe coding security risks piling up on security teams

Both avenues of vibe coding produce a growing list of headaches for security and IT teams.

Apps are wildly insecure by default

Most vibe coded apps are full of textbook engineering mistakes. Authentication is often absent entirely or trivially bypassable. Wiz recently found that Base44 exposed undocumented registration endpoints requiring no authentication, allowing anyone with a public app ID to mint a verified account across internal corporate chatbots and HR tools. A Veracode study backs this up, finding that 45% of AI generated code samples failed security tests.

Agents get direct access to production data

When you wire an autonomous agent to real data, the agent itself becomes an attack surface. The best example is still the incident involving Replit’s AI coding tool, which deleted a production database containing records for roughly 1,200 executives. It ignored a code freeze, forgot it could roll back errors, and actively misreported what it had done.

Building apps with Claude Code, Codex, GitHub Copilot, or Cursor carries its own set of elevated risks. An agent inherits full user rights and has unfettered access to the laptop it runs on, so any untrusted context the agent ingests can lead to a host of malicious actions on the employee’s machine, from data leaks to installing an attacker’s MCP servers.

Secrets pasted into chats and configs

The build process itself is a massive leak surface. GitGuardian’s 2026 report found 24,008 unique secrets exposed in MCP configuration files. Users routinely paste API keys and database credentials directly into prompts.

Zero visibility and massive blast radius

Tech leaders know they are blind. A Retool survey found that only 5% of executives were very confident they had full visibility into internal tools. That is partly because vibe coded apps are often public by default. Red Access found 380,000 publicly accessible assets built on these platforms, thousands of which contained sensitive corporate information. To a standard endpoint agent, someone building on a builder platform looks like ordinary browser activity.

When the platform generates the data layer, one insecure default becomes hundreds of live vulnerabilities. CVE-2025-48757 recently affected 170 Lovable generated projects because row level security was never enabled on the generated tables, exposing emails and API keys to the open internet.

No lifecycle, no hardening, no updates

Building is fun. Maintaining is not. A study of Flathub apps flagged as AI generated found that the vast majority were completely abandoned right after submission.

The SaaS problem and the agent problem

Vibe coding risks are different depending on whether teams use online builders and SaaS platforms to create and host their code, or a dedicated coding agent.

The ownership row is the one people argue about, and it resolves faster once you stop treating the two halves as one program.

The “citizen developer” dilemma

The same influx of inexperienced developers that delivers more ideas, more apps, and more productivity also kills any software maturity. A Zapier survey found that a third of workers shipping AI tools have no programming background. Ops managers and finance leads are shipping tools their entire teams depend on.

They simply “don’t know what they don’t know”. A controlled Stanford study showed that participants with access to an AI assistant wrote significantly less secure code than those without, yet they were more likely to believe their code was secure. Not careless, and not bad at their own job. Just not carrying the attacker’s model that makes “should this table be readable by anyone with the URL” an obvious question.

CISOs and AppSec teams are expected to solve this. However, these teams routinely operate at a 1:100 ratio of AppSec to software engineers, which makes manual review of this flood of homegrown apps impossible. SOC teams are no better equipped to monitor and control what AI coding assistants do, because they cannot see the full chain of events and cannot connect actions to the AI’s reasoning.

It is no surprise that IBM found 97% of breached organizations that suffered an AI security incident lacked proper AI access controls.

Enablement over bans: paving the road

You cannot ban your way out of either half. In a Software AG survey, 46% of employees said they would refuse to give up personal AI tools even if their organization banned them outright. On a CISO panel, Datadog’s Matt Muller put it bluntly: “Employees who want to get their job done are by far the most persistent and successful APTs.” They will find a way, including photographing their own screen to move data to a personal account. Indu Sajeev, formerly CISO at ASOS, added that a paper policy is not a control: it has to be codified and running continuously to count.

The reference model is Netflix’s paved road, a supported path that wins on convenience rather than mandate. Security teams have compressed it into a slogan: guardrails, not gates.

The paved roads are:

• Sanctioned internal tool marketplaces: Security teams must stop acting only as “gates” and start supplying the tooling, funneling users into approved environments where AI tools are already configured.
• Use case registries with named owners: Treat AI agents as infrastructure assets. When you record what an agent was created for and the human identity behind it, incidents can be traced back to a specific person and purpose.
• Data classification before coding: Without properly tagged data, downstream controls sit on unstable ground. You have to define what counts as sensitive data before you can decide whether an agent is allowed to touch it.
• Identity layer guardrails: AI agents require dedicated identity, access, and cost controls to operate safely.
• Pre-deployment reviews: Extend your discovery scanning across the largest builder domains and require lightweight security reviews before citizen built apps go live.
• Ongoing monitoring and policy enforcement: Apply uniform policies to every coding agent in use and monitor their activity end-to-end, with a robust audit trail and the ability to stop policy violations as they happen.

How to protect your vibe coders and their code

To protect your organization while still reaping the productivity benefits of vibe coding, you need automated guardrails that compensate for the missing human engineering rigor.

• Mandate human oversight and code scanning: Do not let agents push directly to production. Enforce code scanning (SAST) and dependency scanning on all generated code to catch obvious flaws before they merge.
• Limit permissions for AI agents and tools: Agents should never have unfettered administrative or database access. Restrict MCP connections and apply strict runtime protection so agents reach only the specific environments they need.
• Enforce clean coding standards: Use automated linters to block the most common AI failures. Mandate authentication by default, strictly validate and sanitize user inputs to prevent injection attacks, and actively block commits that hardcode secrets.

Where Adversa AI fits

Adversa AI watches what coding agents do on company machines and stops the damage before it lands: wiped databases, leaked credentials, malicious code shipping to production. An Agent Security Gateway sits on the agents’ own traffic, and a light Endpoint Security Sensor sits on developer machines, monitoring Claude Code, Codex, GitHub Copilot, Cursor, and whatever comes next. That matters most for inexperienced developers, who are least likely to watch their agents closely and spot anomalous behavior.

The good news for overloaded security teams is that 100+ battle-tested policies ship by default, and new policies can be written in plain English, so rolling out new rules across an entire fleet of coding agents takes minimal effort.

Start in observe mode and see what your coding agents did this week.

Frequently asked questions about vibe coding security

Is vibe coding a security risk?

Yes, in two separate ways. Apps built in hosted builders ship publicly readable databases and hardcoded keys at measurable rates. Coding agents on company machines take destructive actions with a real employee’s credentials. The first leaks data, the second deletes it.

Who should own vibe coding security?

Split it. AppSec owns the apps by default, with identity and data security holding classification and credentials. AppSec and the SOC own the agents, since agent activity is runtime activity on machines you manage. One owner for both is where most programs stall.

Does a coding agent security platform cover Lovable or Replit?

It covers the half that runs on your side: agents on your machines and your network, whoever is driving them. An app built and hosted inside a builder’s cloud never crosses either, so it stays with discovery, the builder’s own settings and your tenant controls. Knowing which half a given tool belongs to is most of the work.