In January 2026, Joseph Thacker’s neighbor told him she had bought AI-powered stuffed dinosaurs for her children. The toys, called Bondus, let kids talk to an AI character like an imaginary friend. Thacker, a security researcher, decided to look at the company’s web portal, which was meant to let parents review their children’s conversations.
He found something much worse than he expected.
Without carrying out any hacking, Thacker and a colleague named Joel Margolis discovered that Bondu’s admin console was accessible to anyone with a Gmail account. Just log in with any Google identity, and the console displayed detailed transcripts of nearly every conversation the toys had ever had. Children’s names. Birth dates. Family member names. Pet names they had given their toys. Favorite snacks and dance moves. Tens of thousands of intimate, one-on-one chats between young children and their AI companions.
Bondu confirmed that more than 50,000 chat transcripts were accessible through the exposed portal. The company took it offline within minutes of being notified. The next day, proper authentication was in place.
The researchers later noted their suspicion about how the console was built. They suspected it was “vibe-coded,” created using the same kind of AI coding tools that now let anyone describe an app and deploy it to the internet with a single click.
The Bondu exposure is not an outlier. It is a preview of a systemic problem that has already landed inside most organizations. And most security teams do not know it yet.
Table of contents
- What is vibe coding?
- How AI coding platforms handle security by default
- Case study: The AI toy that exposed 50,000 children’s conversations
- Why AI coding tools default to insecure
- The shadow builder inside your organization
- What history tells us about default-insecure platforms
- How to discover vibe-coded apps in your organization
- 6 steps security teams should take this week
- FAQ
What is vibe coding?
Vibe coding means describing an application in plain language to an AI, letting the AI generate the complete application, and deploying it, often with a single click. The person using the tool writes no code and does not review what the AI produced.
The workflow is not hypothetical. Lovable, one of the leading platforms, describes its product on its homepage as: “Describe the app or website you want to create or drop in screenshots and docs. Watch it come to life. Refine and ship. Deploy it to the world with one click.”
These platforms market to everyone. Lovable’s audience pages cover product managers, designers, marketers, salespeople, operations staff, and founders. The pitch is explicit: you do not need to know how to code. The AI handles all of it.
The result is that people who have never learned about authentication, access controls, HTTPS configuration, or the difference between a development environment and a production deployment are publishing live web applications to the public internet. The tools give them exactly what they asked for. They almost never ask for security.
How AI coding platforms handle security by default
The major platforms all offer security features. The question is whether those features are the default, or whether the user has to know to go looking for them.
Lovable publishes a detailed security page. It lists enterprise-grade controls: SAML and OIDC single sign-on through providers like Okta, Azure AD, and Google. Role-based access control with separate permissions for editing, approving, and publishing. Server-side enforcement that cannot be bypassed from the client. Automated security scanning of generated code, dependencies, and configurations before deployment. SOC 2 Type II, GDPR, and ISO 27001 certifications.
The page also states that “editing, approval, and publishing are separate permissions” and that “public access is controlled by role and environment settings.”
These are substantive controls. But they are enterprise-tier features gated behind a paid plan. The path from “describe an app” to “deploy to the world with one click” on the free tier does not pass through any of these gates.
Netlify takes an explicit shared responsibility position. Its security page states directly: “Customers are responsible for the security and compliance of their applications, including: Application architecture, Data handling, Response caching configuration, Authentication mechanisms, TLS encryption.”
Netlify secures the infrastructure. The customer secures the application. This is a reasonable model when the customer is a professional developer who understands what “authentication mechanisms” means and how to implement them. When the customer is a marketing manager who described a dashboard to an AI and hit publish, the model breaks. That customer does not know authentication is their job, and the AI did not volunteer to add it.
Other platforms in this category, including Replit and Base44, provide configurable privacy and access settings. The industry pattern is consistent: security capabilities exist as opt-in features, not as defaults. The user who does not know about them will never activate them.
Case study: The AI toy that exposed 50,000 children’s conversations
The Bondu exposure in January 2026 is the clearest documented example of the vibe coding security problem, and it is worth understanding in detail.
Joseph Thacker and Joel Margolis discovered that Bondu’s web-based admin console required no authentication beyond logging in with any Google account. Once logged in, they could see: children’s full names, birth dates, family member names, parent-chosen “objectives” for each child, and complete transcripts of every conversation between the child and their Bondu toy.
The researchers had not hacked anything. They simply tried logging in and found themselves inside.
“It felt pretty intrusive and really weird to know these things,” Thacker said. “Being able to see all these conversations was a massive violation of children’s privacy.”
Bondu CEO Fateen Anam Rafid said in a statement that the console was taken down within minutes of the researchers’ notification and relaunched the next day with proper authentication. The company said it “found no evidence of access beyond the researchers involved.” Senator Maggie Hassan sent a letter describing the exposure as “devastating” and demanding answers about the company’s data protection practices.
The detail that matters most for this discussion: the researchers suspected the console itself had been built using AI coding tools. In their assessment, it appeared to be vibe-coded. If that assessment is correct, the Bondu exposure is a closed loop. An AI coding tool was used to build an application that handled the most sensitive data imaginable, conversations between children and their toys, and the tool built exactly what was asked for without adding any authentication.
Margolis described the cascading risk: “There are cascading privacy implications from this. All it takes is one employee to have a bad password, and then we’re back to the same place we started, where it’s all exposed to the public internet.”
He added a blunt warning: “To be blunt, this is a kidnapper’s dream. We’re talking about information that lets someone lure a child into a really dangerous situation, and it was essentially accessible to anybody.”
This is the extreme case. But the underlying mechanism, an AI tool building exactly what was asked for without adding security by default, applies identically to every vibe-coded app built by every non-developer in every organization.
Why AI coding tools default to insecure
AI coding tools are instruction-following machines. Their optimization target is giving you exactly what you asked for. If your prompt says “build me a dashboard that shows our Q2 sales data,” the AI builds a dashboard that shows Q2 sales data. It does not, unless explicitly prompted, add a login page.
The Bondu case illustrates the dynamic precisely. The researchers who discovered the exposure wrote on their own site that they suspected the console itself was built with AI coding tools. Someone, presumably at Bondu, described the admin panel they wanted. The AI built it. It went live. Nobody mentioned authentication, so nobody got authentication. It took two independent security researchers poking around to discover that 50,000 children’s private conversations were sitting on the open web.
This is not a vulnerability in the traditional sense. The software is not broken. It is doing exactly what it was designed to do. The vulnerability is in the combination of three design choices that, individually, are defensible, and together produce a predictable disaster:
First, the default deployment path publishes to a public URL. One click from describe to live on the internet.
Second, the default application template includes no authentication. The AI will not add access controls unless the user prompts for them.
Third, the platform markets to people who have never been taught that authentication is a requirement for any application that handles data.
Each of these choices is individually understandable. Together, they guarantee that thousands of people will publish applications containing data they did not intend to make public. The Bondu case is what happens when the data in question is among the most sensitive that exists. The corporate equivalent, a dashboard pulling from a production database or a chatbot logging customer conversations, is the same mechanism applied to a different dataset.
The shadow builder inside your organization
The Bondu exposure was caused by a company that knowingly built a web application. In most organizations, the problem is different: the apps already exist, and nobody who knows about security knows they exist.
RedAccess, a cybersecurity vendor that analyzed thousands of AI-coded applications, has labeled this phenomenon “shadow AI builders.” Their terminology is useful. Traditional shadow IT means someone signed up for a SaaS tool without IT approval. The data lives in a vendor’s cloud, protected by that vendor’s security team. With shadow builders, there is no vendor’s security team. The “vendor” is an AI that built whatever the user asked for.
The risk compounds when vibe-coded apps connect to other systems. Lovable’s platform supports integrations with tools like Jira, Notion, and APIs that connect to production data sources. An employee builds a quick dashboard to visualize data from a company database. They click deploy. The dashboard is live. If the URL is guessable or discoverable, anyone who finds it can see everything the dashboard shows, including whatever data it pulls from the connected systems.
Security tools designed for traditional development pipelines were not built for this pattern. An endpoint detection tool sees HTTPS traffic to an AI platform. A DLP tool sees document uploads. A cloud access security broker sees a new connection to a SaaS tool. None of these individual signals assemble into “an unauthenticated production application just went live” unless someone has explicitly connected those dots in advance.
What history tells us about default-insecure platforms
Security teams have seen this pattern before. The closest parallel is the Amazon S3 bucket exposure epidemic of the mid-2010s.
In 2017, the scale of the S3 problem became visible. World Wrestling Entertainment confirmed that an S3 bucket misconfiguration had exposed personal data for 3 million fans. Researchers announced that a separate misconfigured bucket had exposed the data of between 6 million and 14 million Verizon customers. These were not sophisticated attacks. They were not attacks at all. They were storage buckets left publicly accessible because the default configuration made it easy to leave them that way.
Security researcher Victor Gevers, commenting on the S3 epidemic at the time, said: “2017 is a year where low hanging fruit, misconfigurations and bad defaults, really are the beginning of a new strain of online criminal behavior.”
SAP executive Mark Testoni described the dynamic: “It’s like we have a great idea, let’s build a quick proof of concept and show it to an investor. Then it becomes a beta service and suddenly that quick and dirty build becomes a production environment.”
The S3 epidemic taught three lessons that apply directly to vibe coding.
The first lesson is that user education alone does not work at scale. Millions of people used S3. Many of them misconfigured it. The problem did not end because everyone learned about bucket policies. It ended because Amazon changed the default settings, added warnings, and made secure configuration the visible, obvious choice.
The second lesson is the long tail. Years after the S3 problem was widely documented, researchers were still finding exposed buckets. Vibe-coded app exposures will follow the same pattern. The tools are becoming more capable and more widely adopted every month. The number of non-engineers publishing applications is growing faster than the number of security teams adding vibe coding platforms to their monitoring.
The third lesson is that blaming the user feels productive but changes nothing. Testoni argued that the solution lay with the platforms: “I think it’s a natural progression for companies to offer these types of services.” That progression did happen for cloud storage. It has not yet happened for AI-generated applications.
How to discover vibe-coded apps in your organization
Finding exposed apps built by your employees starts with search engines. Try searching for your company name combined with the domains of popular vibe coding platforms. Lovable publishes apps to lovable.dev. Netlify publishes to netlify.app. Replit publishes to replit.app. Search broadly across the domains of any AI app builder your teams might use.
Extend the search to your product names, internal project codenames, executive names, and any other terms that might appear in an app built by an employee. The apps you find may not look like production software. They may look like quick dashboards, simple forms, or internal tools. Assume that any app you find might contain data.
Beyond search engines, review your network traffic for connections to AI coding platforms. If employees use corporate devices to access these services, your existing security tools should have that data. Look for sustained traffic patterns that suggest active use rather than one-time visits.
Ask your teams directly. Most employees who built apps using these tools were trying to solve a real problem. They did not know they were creating a security exposure. A message that says “If you have built a web app using an AI tool, please let us know so we can help make sure it is secure” will get a better response than one that sounds like an investigation.
6 steps security teams should take this week
Step 1: Run the searches. Search for your company name, product names, and executive names across the domains of major vibe coding platforms. Do it today. If you find nothing, expand the search terms. Your organization probably has apps out there.
Step 2: Inventory what you find. For each discovered app, document what it appears to do, what data it probably contains or connects to, who in your organization likely built it, and whether it is publicly accessible. You need the inventory before you can prioritize.
Step 3: Contact the builders. Reach out to the employees who created the apps. Explain the risk without blame. They almost certainly had no idea their app was publicly accessible or that it should not be. Help them secure or remove the app. Most will be grateful.
Step 4: Establish a policy. Write and communicate clear guidance on AI coding tools. Specify which platforms are approved, what security requirements apply before deployment, and who must review and approve applications before they go live. The policy should be practical, not punitive. People use these tools because they are trying to work faster. Give them a safe path.
Step 5: Add vibe coding platforms to your monitoring. Configure your security tools to flag traffic to AI coding platforms. Add these platforms to browser security policies and DLP rules. You cannot govern what you cannot see, and right now most organizations have zero visibility into vibe coding activity.
Step 6: Engage with the platforms. If you find your organization’s data exposed through a vibe coding platform, report it. Platform security teams have mechanisms for handling these reports. Individual exposures can be fixed quickly once flagged. But the systemic fix requires platform-level changes to defaults, and that requires sustained pressure from the organizations that use these tools.
FAQ
Is vibe coding the same as using GitHub Copilot or an AI code assistant?
Not quite. AI code assistants help developers write code within an existing development workflow that typically includes code review, testing, and security gates. Vibe coding tools generate and deploy complete applications, usually with one-click publishing that bypasses all of those gates. The important difference is whether the deployment path passes through a security review before reaching the public internet.
Are all vibe-coded apps insecure?
No. Apps built by developers who understand web security and properly configure authentication, access controls, and encryption are as secure as any other well-built application. The risk is specific to non-developer users who publish applications without knowing authentication is necessary.
Which platform has the best security?
Security depends far more on configuration than on platform choice. Every major platform provides security tools. The field where platforms differ meaningfully is in their defaults. A platform that makes authentication the default for all deployments would be inherently more secure than one that leaves it as an opt-in setting, regardless of the depth of the opt-in tooling.
What do I do if I find an exposed app I built?
Open the app’s URL in a private or incognito browser window. If it loads without asking you to authenticate, it is public. Enable privacy or authentication settings immediately through the platform. If the app contained real data, follow your organization’s incident response process for a data exposure.
Will this problem get better?
Only when the platforms change their defaults. User education helps at the margins. Monitoring helps catch exposures faster. But the fundamental dynamic, a tool that makes insecure publishing easier than secure publishing, will keep producing exposures until the path of least resistance is the secure one. The S3 experience shows that this kind of platform-level change does happen, but it typically takes a series of high-profile incidents to create the pressure for it.
Is this really comparable to the S3 bucket problem?
The mechanism is the same: a powerful tool that makes it easy to publish data, combined with defaults that do not enforce security. The scope is potentially larger because the user base is larger. S3 required at least some familiarity with cloud infrastructure. Vibe coding tools require no technical knowledge at all. Anyone in your organization who can describe what they want in a sentence can publish an application. The population of people who can accidentally create an exposure is the entire workforce, not just the technical staff.
Next steps
Start with the searches in Step 1. The Bondu case and the S3 precedent both tell the same story: default-insecure platforms produce predictable, repeating exposure patterns, and the only organizations that avoid being part of those patterns are the ones that go looking for the problem before someone else finds it.
The Netlify security page frames the arrangement clearly: the platform secures the infrastructure, and the customer secures the application. The gap is that many of the people in your organization using these platforms do not know the second sentence applies to them. Closing that gap, through policy, monitoring, and direct outreach to the builders themselves, is the single highest-impact action you can take this week.