By Nolan Sullivan, Founding Growth Engineervibe coding security
Vibe coding security is the set of controls that keep employee-built apps from Lovable, Base44, v0, and similar builders from reaching production data and Model Context Protocol (MCP) servers the security team never approved. It is a shadow-AI problem at the app layer: the builder is sanctioned or not, but the generated app’s connectors, tokens, and tool calls are usually neither inventoried nor identity-bound.
The term traces to Andrej Karpathy’s February 2025 description of building software by prompting and accepting what the model produces without reading the code. An app built this way can still include a database, credentials, and network access. When it does not pass through the organization’s normal repository, delivery pipeline, or review process, security may have no record of it.
Procurement can sanction Lovable while generated apps still create unsanctioned reach. The person prompting can determine which databases an app reads, which tokens it holds, and which tools it calls. The security question therefore follows the apps and their connections rather than the builder’s procurement status.
How is vibe coding security different from shadow AI and shadow MCP?
Speakeasy already maintains references for the neighboring terms, and the boundaries matter because each population is governed differently:
| Term | Unsanctioned object | Question it answers |
|---|---|---|
| Shadow AI | Any AI in use outside the perimeter: models, agents, MCP servers, skills | What AI is running here that nobody approved? |
| Shadow MCP | MCP servers agents connect to without review | Which tool servers are agents calling that nobody sanctioned? |
| Vibe coding security | Applications employees generate with AI app builders | Which employee-built apps reach company data, and through what? |
Shadow AI is the category. Shadow MCP is the tool-server slice, where a finding is a server with tools and a credential. Vibe coding security is the app slice, where a finding is a running application with users, a data store, embedded keys, and often an AI feature that can keep calling tools after the person who built it has moved on. An app is a different kind of object from a server or a chat account, so it needs its own record shape and disposition path, even though all three populations land in the same governance machinery.
What is the security risk of Lovable, Base44, or v0 at work?
Lovable security became a concrete topic in May 2025. The incident illustrates three sources of risk in AI app builders. These are the defaults the platform generates, the credentials the employee supplies, and the absence of a record tying the app to an owner.
Lovable security and CVE-2025-48757
Security researcher Matt Palmer disclosed CVE-2025-48757 after finding that Lovable-generated projects shipped with missing or insufficient row-level security (RLS) on their Supabase databases. Lovable apps embed the Supabase project URL and public key in the page by design, which is safe only when RLS policies restrict what that key can read. Palmer’s scan of 1,645 Lovable-built projects found 303 vulnerable endpoints across more than 170 projects, exposing names, phone numbers, subscription and payment details, and live API keys to anyone who copied the key from the browser and queried the database directly.
The same class of gap can apply when a builder generates a working data layer for someone who cannot evaluate it, and a platform fix covers only its own defaults. The person shipping the app may have accepted code they did not read, which is the premise of vibe coding. The review that could catch a missing policy may therefore never happen.
How credentials and ownership create vibe coding security risk
The second and third parts of the risk are independent of any CVE. To make a generated app useful, an employee may paste in credentials such as a personal access token, a CRM API key, or a database connection string. Those tokens can carry the person’s full reach, live in a vendor’s cloud outside the organization’s secret management, and remain active after the person changes teams or leaves. If the app did not pass through procurement or a repository, there may be no record of who owns it, what it reaches, or that it exists. When exposed data appears somewhere it should not, the investigation can begin without that context.
How do vibe-coded apps connect to MCP servers?
Model Context Protocol (MCP) servers are the standard way AI systems reach tools, and vibe-coded apps meet them on three paths:
- At build time. The builder’s agent can connect to MCP servers and third-party integrations while generating, acting on company systems with whatever credential the employee supplied to make the integration work.
- At runtime. A generated app that includes an AI feature, a support chatbot, a data-analysis assistant, or an automation step calls MCP servers or APIs on every use, long after the building session ended. Once it runs without its builder steering each action, govern that feature as a background agent with an owner and its own identity strategy.
- Through pasted credentials. On both paths, the credential behind the connection is typically one the employee supplied by hand, so the server sees a personal token rather than an identity bound to the app.
These connections are the overlap with shadow MCP: an MCP server that only ever gets called by a vibe-coded app is invisible to a review process that watches coding agents. They are also why the governable point is the connection rather than the app. The app lives in a vendor’s cloud the security team cannot reach, but every call it makes to company data or tools crosses a network boundary where an MCP gateway can require identity, enforce an allowlist, and record the call.
How should a CISO inventory vibe-coded apps?
The same way agents are inventoried: as records with an owner and a disposition, in a register that stays current from live signals rather than from a survey. The agent inventory reference covers the register pattern; a vibe-coded app record needs the app’s location, the person who built it, the data stores and MCP servers it reaches, the credentials it holds, and whether it is sanctioned.
Discovery draws on signals the organization already has. The broader agent discovery process explains how those signals become owned inventory records rather than disconnected alerts:
- Identity provider and SSO logs. Sign-ins to Lovable, Base44, v0, and similar builder domains identify who is building, which is the fastest route to an owner for each finding.
- Expense and procurement records. Builder subscriptions on corporate cards surface teams that adopted a platform nobody reviewed.
- Network egress. Traffic to builder-hosted app domains from inside the organization indicates generated apps in active use.
- Tool-call traffic. When company data and MCP servers sit behind a gateway, any app that reaches them registers as a side effect of being used, including apps no other signal caught.
The register is the difference between detection and governance: a finding that lands as a record can be assigned, scoped, sanctioned, or shut down, where a finding that lands as an alert scrolls past.
Do you need an endpoint agent to govern vibe coding?
Not for control. Coding agents can be observed from inside via agent hooks, but a vibe coding builder runs in a browser tab and the app it produces runs in the vendor’s cloud, so an agent on the laptop sees the building session at best and the deployed app not at all. Vendors such as Willow market browser-side monitoring of vibe-built apps, which addresses the discovery half of the problem from the endpoint.
Control sits elsewhere. The app’s reach is created at the moment it connects to company data or an MCP server, and that connection crosses infrastructure the organization does control. A gateway on that path can require every connection to carry a directory identity, evaluate each tool call against the owner’s grants, and log the result, which is the agent identity model applied to apps. An app that never passes the gateway never reaches anything worth governing, whatever sensor did or did not see it get built.
How does the Speakeasy AI Control Plane handle vibe coding security?
The Speakeasy AI Control Plane governs the connection layer the sections above keep landing on. Its MCP gateway sits between AI clients and the MCP servers and tools an organization exposes, so a vibe-coded app that needs company data gets it the same way a sanctioned agent does: as a registered client with an owner, authenticated through the identity provider the organization already runs, authorized per tool call, and recorded in audit logs the security team can export. The gateway’s traffic doubles as a discovery feed, because every server and client that touches the sanctioned path registers as a side effect of being used, and the inventory it maintains is where vibe-coded app findings land next to agents and MCP servers.
The platform governs what apps reach, and it inventories the MCP and tool-call traffic that crosses it. It does not claim to find every builder tab open in every browser; the discovery signals in the inventory section above cover that half. To see which apps and servers are already reaching your data through paths nobody sanctioned, talk to us.