Vibe Coding’s Security Problem Is Invisible Production
The security problem with vibe coding is not that generated code sometimes has bugs. That is true, but it is the smaller story. The bigger story is that prompt-to-app tools are creating a new production surface outside the engineering perimeter: apps with URLs, databases, forms, customer data, and business logic — but no repo in the service catalog, no owner in the on-call rotation, and no pre-deployment security review.
RedAccess says it found 380,000 publicly accessible assets tied to vibe-coding platforms and deployment surfaces including Lovable, Base44, Replit, and Netlify. Roughly 5,000 of those assets — about 1.3% — contained sensitive corporate information, according to VentureBeat’s reporting. Wired, which separately reviewed the findings, reported examples including hospital doctor-patient summaries, patient conversations at a children’s long-term care facility, customer-service chat logs, internal bank financial information, shipping records, clinical-trial details, ad buying strategy, and corporate presentations.
That is not a code-quality footnote. That is shadow IT getting a deploy button.
The S3 bucket analogy works, but the blast radius is different
VentureBeat calls this a “shadow AI S3 bucket crisis,” and the comparison is useful. The industry has already lived through a decade of “private data left in public cloud storage because someone misunderstood the default.” The lesson was supposed to be boring and permanent: defaults matter, discovery matters, and configuration mistakes become incidents when infrastructure is easy enough for anyone to provision.
Vibe-coded apps add a sharper edge. S3 was mostly adopted by technical teams. Lovable, Replit, Base44, and similar tools are explicitly marketed to people who may not know what row-level security, OAuth scopes, CORS, RBAC, secret rotation, or data classification mean. If the sales pitch is “describe the app and ship it,” then a platform response of “the creator is responsible for configuring security correctly” may be legally tidy, but operationally it is wishful thinking in a blazer.
RedAccess CEO Dor Zvi put the real failure mode plainly in Wired: “Anyone from your company at any moment can generate an app, and this is not going through any development cycle or any security check. People can just start using it in production without asking anyone. And they do.” That quote matters because it shifts the discussion away from whether AI writes safe code and toward whether organizations can even see the software being created in their name.
Security teams cannot review apps they do not know exist
Traditional AppSec assumes there is an artifact to inspect: a repository, a CI pipeline, a cloud account, a ticket, a pull request, a release process. Vibe-coded apps often skip that breadcrumb trail. They may live on platform subdomains, behind generic hosting layers, connected to SaaS APIs or Supabase databases, and shared in Slack as “just a quick tool.” The owner might be a product manager or operations analyst, not an engineer. The URL might get indexed by Google before anyone in security knows the project exists.
This is why the “just educate users” answer is inadequate. Education helps, but it does not scale to every employee becoming a part-time software publisher. The safer mental model is that citizen-built AI apps are now a class of enterprise asset, and they need the same boring controls that made cloud adoption survivable: identity, inventory, logging, policy, and blast-radius management.
The numbers are not comforting. VentureBeat connects RedAccess’s findings to prior Escape.tech research that scanned 5,600 public vibe-coded apps and found 2,000+ high-impact vulnerabilities, 400+ exposed secrets including API keys and access tokens, and 175 personal-data exposures involving records such as medical and banking data. IBM’s 2025 Cost of a Data Breach report found that 20% of organizations had breaches linked to shadow AI; those incidents added $670,000 to average breach cost, pushing the shadow-AI breach average to $4.63 million. IBM also reported that 97% of AI-related breaches lacked proper access controls and 63% of breached organizations had no AI governance policy.
The pattern is obvious enough to stop pretending it is theoretical. Shadow AI is not only employees pasting secrets into chatbots. It is employees generating software that stores, transforms, and exposes data while bypassing the controls that normally make production software auditable.
The platform-default problem is not a UX nit
The vendors’ responses, as reported by Wired and VentureBeat, are exactly what you would expect. Replit CEO Amjad Masad argued that public apps being accessible is expected behavior and that privacy settings can be changed with one click. Lovable said builders have tools to build securely, but configuration is ultimately the creator’s responsibility. Base44/Wix said publicly accessible applications reflect user configuration choices, not a platform vulnerability.
There is truth in those statements. Public apps are public. Users can misconfigure things. Not every exposed-looking demo contains real data. Researchers and reporters should verify carefully before declaring a breach. Fine.
But the platform-level question remains: what defaults are appropriate when your product turns non-engineers into deployers of internet-facing applications? “Public unless changed” is a risky default when the output can include live customer data. A one-click privacy setting is not enough if the user does not understand why they need it. Secure configuration cannot be treated as an advanced feature when the business model depends on removing the technical friction that used to force security conversations earlier.
Better defaults would look boring: private-by-default apps for organization workspaces, SSO/SAML before deployment, clear warnings when data tables appear to contain PII, generated auth and authorization scaffolding that is on by default, search-indexing disabled for internal tools, admin dashboards showing every app created by employees, and deployment gates when an app connects to live business systems. Some of that adds friction. Good. Friction is not always the enemy; sometimes it is the guardrail between “prototype” and “incident report.”
What engineering teams should do Monday morning
The wrong reaction is to ban vibe coding outright. That will not eliminate the demand; it will just move the work further into shadow channels. The right reaction is to drag the shadow production layer into the same governance model used for SaaS, cloud, and CI/CD.
Start with discovery. Monitor DNS, secure web gateway logs, and certificate transparency for corporate identifiers, domains, project names, and employee activity on major vibe-coding and hosting platforms. Do not stop at “someone visited Lovable.” The useful question is: what did they deploy, what data does it touch, and who can access it?
Then put identity in front of sanctioned use. Require organization-managed workspaces, SSO, and admin-visible app inventories. Block unauthenticated apps from connecting to live internal data sources. Add Lovable, Replit, Base44, Netlify, and similar deployment domains to DLP rules. Extend SAST/DAST and dependency scanning to citizen-built apps when they touch sensitive data. Publish an acceptable-use policy that defines review requirements by data class, not by who built the app.
For individual builders, the checklist is simpler: if the app touches customer data, employee data, financial data, health data, credentials, source code, or internal strategy, it is not a toy. It needs authentication, authorization, logging, secret management, environment separation, and an owner. If that sounds too heavy for a weekend prototype, use synthetic data. The fastest way to ship is still not creating the breach you have to spend the next quarter cleaning up.
The long-term lesson is bigger than vibe coding. Agentic software creation collapses the distance between intent and deployment. That is the whole appeal. But software still enters the real world through URLs, databases, permissions, and logs. The model can write the code; it cannot absorb the accountability. Teams that confuse invisible production with velocity are not moving faster. They are just removing the warning lights from the dashboard.
Sources: VentureBeat, Wired, Escape.tech, IBM Cost of a Data Breach 2025