The App Your AI Built Last Weekend Is Leaking: What 16,000 Exposed Databases Tell Every Board

Somewhere in your company, a product manager, a marketer, or a developer on a deadline has used an AI coding tool to build a small internal app. It took an afternoon. It works beautifully. It stores customer names, phone numbers, or documents in a cloud database. And nobody in security has ever heard of it.

Last week, the security firm UpGuard put a number on how often that story ends badly. Its researchers found 16,326 databases on Supabase, a popular back-end platform for web and mobile apps, whose data could be read by anyone who knew where to look. This is not a story about one company’s breach. It is a story about a new way of creating risk faster than any governance process can see it.

What UpGuard Found

According to UpGuard’s published research, the team screened roughly 300,000 domains and identified 16,326 Supabase databases with publicly readable tables. More than half showed indicators of personal information. Smaller shares contained passwords or authentication tokens, and a very small number appeared to contain payment card data.

UpGuard also described specific exposures. One was an India-based adult content platform with 65,467 user records, including identity documents. Another was a Philippines-based text-message verification service that exposed more than 100,000 messages, including one-time login codes. A U.S. valet service exposed more than 100,000 customer records, and an African consulate exposed about 25,000 records on vulnerable people, including home addresses.

The cause was not a hacker breaking in through a clever exploit. As UpGuard explains it, the databases lacked row-level security, which is the setting that controls who can see which rows of data. Without it, a table can be read by anyone holding the app’s public access key, and that key is visible in the app’s own code by design. Supabase turns this protection on by default for tables created through its dashboard. UpGuard notes that tables created programmatically through the platform’s API, which is how AI coding agents typically work, do not get it automatically.

In plain English: the lock exists, the vendor sells the lock, and the way these apps were built left the door unlocked by default.

Whose Problem Is This?

It is tempting to say this is Supabase’s problem, or the app builders’ problem. The affected organizations will not be able to say that to a regulator, a plaintiff’s lawyer, or a customer. If your company’s customer data sits in an app that anyone on the internet can read, it is your breach, regardless of who clicked the buttons or which tool wrote the code.

This is the heart of the argument in Cyber Risk Is Business Risk: security failures are business failures, and accountability does not transfer with the work. When AI lets any employee ship software, every employee becomes a potential source of unreviewed, unmonitored attack surface. The speed that makes these tools valuable is the same thing that outruns the review process.

It is also a clean illustration of the gap between compliance and security. A company can have a spotless secure-development policy, a clean audit, and a trained engineering team, and still have a dozen apps built outside that process that never appear on any inventory. The policy covers the software you know about. The exposure lives in the software you don’t.

The Three Questions for Your Board

The Three Questions framework from the book fits this problem directly.

Exposure: Do we know what applications our people have built or deployed with AI coding tools, and what data they hold? If the honest answer is “we don’t,” that answer is the first finding.

Response: If one of those apps were exposed tomorrow, who owns it, who would learn about it, and how quickly? An orphaned weekend project has no on-call team.

Validation: Has anyone independently tested these apps’ access controls, or are we relying on the tool’s defaults and the builder’s good intentions?

What to Ask Your CISO This Week

• Do we have an inventory of applications built with AI coding assistants or low-code tools, including ones built by non-engineers? Who owns each one?
• Which of those apps store customer, employee, or partner data, and where does that data live?
• Do our cloud database settings require access controls such as row-level security on every table, and has anyone checked?
• Is there a simple, fast approval path for employees who want to build something, so that the safe route is also the easy route?
• If a researcher found one of our databases open on a Saturday, who would they be able to reach, and who would answer?

The goal is not to ban the tools. They are genuinely useful, and employees who build things are often your most valuable people. The goal is to make sure that when software gets created in an afternoon, someone is still accountable for it on Monday.