Vibe Coding at Work: How to Govern Lovable, Replit, and Bolt Before Code Leaks

Vibe coding tools moved software creation out of the IDE and into the browser, which means source code, API keys and customer data now leave your company through people who were never covered by your developer-tool policy. Lovable, Replit, Bolt and similar app builders let a product manager or a marketer describe an app in plain language and get working code, often wired to real credentials and real data. That is powerful. It is also a shadow AI surface that endpoint DLP and discovery have to cover, because a block list on fireflies-style domains will never keep up. If your governance so far has focused on IDE assistants, our write-up on Cursor enterprise controls is the companion to this one.

This post is for security teams that approved GitHub Copilot and Cursor for engineers and then watched non-engineers start shipping apps from a browser tab.

What vibe coding actually is

Vibe coding is building software by describing what you want to an AI, then accepting, tweaking and deploying what it generates, without writing most of the code yourself. Tools like Lovable, Replit and Bolt run in the browser, generate a full app, and can connect to databases, payment providers and third-party APIs. The appeal is obvious: someone with an idea and no engineering background can get to a working prototype in an afternoon.

The security consequence is just as obvious once you look. These tools ask for context to be useful. People paste in a schema, a sample export, an API key, a block of existing source. That content leaves the device and goes to the vibe-coding service. The person doing it is often not in engineering, has never signed your secure-development policy, and does not think of 'I pasted our customer table structure into Lovable' as a data event.

Why this is a different problem from IDE assistants

You may already govern GitHub Copilot, Cursor and Claude Code. Good. But those live in the engineering org, inside tools IT provisioned, used by people who know what a secret is. Vibe coding tools break all three assumptions. They live in the browser, so there is nothing to provision. They are used across the business, by marketing, ops and finance, not just engineers. And the people using them often do not recognize that an API key or a customer list is sensitive.

So the governance you built for IDE assistants does not automatically cover this. The surface moved to the browser and the user population widened to the whole company. That is exactly the kind of blind spot we map in detecting shadow AI across desktop apps, IDEs and CLIs.

What actually leaks through a vibe coding tool

Three things, mostly. Source code, when someone pastes existing proprietary code in to extend it. Secrets, when an API key, a database URL or a token gets dropped into a prompt or a config so the generated app can connect to something real. And customer or business data, when a sample export is used to 'make the app work with our data.' Any one of these leaving on an unmanaged account is a problem. Together they are a steady drip of your crown jewels into services you have no contract with.

The reason this stays invisible is that it looks like normal web traffic. There is no alert. The app just works, the person moves on, and the data now lives somewhere else. Discovery has to happen at the point where the data moves, which is the device.

How dope.security governs vibe coding from the endpoint

dope.security runs on the device, so it sees the browser traffic these tools generate on any network. That turns an invisible problem into a governed one in three steps.

Discovery comes first. AI Analytics surfaces Lovable, Replit, Bolt and the next tool like them as soon as they are used, with the user, the transaction count and the data volume, no survey required. Then content inspection: Dopamine DLP reads prompts and uploads on the device and is built to catch exactly the categories that leak here, including source code, secrets and PII. It classifies by meaning rather than matching patterns, with zero data retention, and it carries US Patent 12,464,023. Finally, enforcement: Cloud Application Control and SWG policy let you allow a sanctioned tool on an enterprise account while blocking personal sign-ins and risky uploads, the same three-layer model shown in one-click AI blocking and shadow AI detection.

Vibe coding ungoverned versus governed on the endpoint

Here is the contrast, ungoverned first and dope.security-governed second on each line.

• Discovery: a browser-based app builder leaves no trace in your tool inventory; dope.security surfaces it in AI Analytics from the endpoint, with the user and data volume attached.
• Secrets: nothing stops an API key or database URL from being pasted into a prompt; Dopamine DLP reads the prompt on the device and can block the secret before it leaves.
• Source code: proprietary code pasted in to extend an app is gone the moment it is sent; on-device DLP inspects for source code and blocks the upload at the source.
• Account control: a personal account puts your data in a service you have no terms with; Cloud Application Control allows the sanctioned tenant and blocks the personal sign-in.

The tool can be the same in both rows. What changes is whether the data movement is seen and governed where it happens.

A policy that does not just say no

Banning vibe coding outright is tempting and usually pointless, because the whole value is speed and people will find a browser tab you have not blocked. The better move is to discover what is already in use, pick which tools become sanctioned on enterprise accounts, and turn on DLP so secrets and source code cannot be the thing that leaks even on an approved tool. Make the safe path the fast path. The difference between sanctioned and unsanctioned use is the heart of it, and we go deeper in sanctioned versus unsanctioned SaaS governance. Teams that rolled this out at scale, like the Fortune 100 deployment that reached 18,000 devices in weeks, did it without a gateway to design first because the control runs on the endpoint.

The takeaway

Vibe coding is not going away, and it should not. It is a real productivity unlock. But it moved code, secrets and data into the browser and into the hands of people outside your developer governance, so the control has to move with it. Discover the tools from the device, read what is being pasted and uploaded, and enforce sanctioned accounts. Govern the data where it moves, and vibe coding becomes a tool you can say yes to.

Frequently Asked Questions

What are vibe coding tools?

Vibe coding tools like Lovable, Replit and Bolt let someone build software by describing it to an AI in plain language, then deploying the generated code, often without writing it by hand. They run in the browser and can connect to real databases, APIs and credentials. That makes them powerful for non-engineers and a meaningful data-exfiltration surface, which dope.security governs from the endpoint.

Are vibe coding tools a security risk?

They can be, because people paste source code, API keys and customer data into them to make the generated app work, often on personal accounts outside IT governance. The risk is not the code generation itself but the sensitive data leaving the device. dope.security discovers the tools, reads prompts and uploads with Dopamine DLP, and blocks secrets and source code before they leave.

How is governing vibe coding different from governing GitHub Copilot or Cursor?

IDE assistants live inside engineering, in tools IT provisioned, used by people who understand secrets. Vibe coding tools live in the browser, are used across the whole business, and are often used by people who do not recognize an API key as sensitive. dope.security covers both with one on-device model that discovers the tool, inspects the content and enforces the account.

Can you stop employees from pasting secrets into Lovable or Replit?

Yes. Because dope.security runs on the device, Dopamine DLP reads the prompt or upload on the endpoint and can block content it classifies as a secret, source code or sensitive data before it reaches the service. It classifies by meaning rather than matching fixed patterns, with zero data retention.

Should we block vibe coding tools entirely?

A blanket block usually fails, because the value is speed and users find another browser tab. A better approach is to discover what is in use, sanction specific tools on enterprise accounts, and turn on DLP so secrets and source code cannot leak even on an approved tool. dope.security enforces that sanctioned-versus-personal distinction on the endpoint.