Locked By Default

AI tools that build entire apps from plain conversation are having a rough year on the security front. Independent researchers have been scanning apps built this way, and the results aren't a handful of typos. One researcher who scanned dozens of apps built on a popular AI app builder found that roughly two-thirds carried critical or high-severity vulnerabilities, averaging around ten findings per app. One of those apps, with over a hundred thousand views, had a flaw that exposed the personal data of more than eighteen thousand people.

That's not one bad app. Research looking at AI-generated code across these tools more broadly puts the vulnerability rate somewhere between 40 and 62 percent. That's a real, industry-wide pattern, not a fluke.

Here's what's actually happening underneath those numbers. The AI builds the feature you asked for, a login, a form, a member feed, and it works. It looks finished. What it skips, more often than it should, is the setting that decides who's allowed to read or write the data sitting behind that feature.

Every one of these platforms sits on a database, and every table in that database needs a rule: can anyone read this, can anyone write to it, or is it locked to just the person it belongs to. A well-built table refuses every request by default until a specific rule says otherwise. A table left without that rule isn't just under-protected, it's wide open to anyone who knows it exists, no login required.

That single missing setting is the root cause behind nearly every one of these incidents. Not a hacker exploiting some clever trick. A database that was never told to lock its own doors.

This isn't specific to any one platform, and it isn't a reason to distrust AI-assisted building in general. It's a reason to know exactly one thing about whatever you build on: does it lock every new table by default, or does it leave that decision to whoever's typing the prompt.

Dedicated Cloud, the backend infrastructure this hub runs on, defaults new tables to deny-by-default: a table with no explicit rule is invisible to a visitor, not just restricted. That's a structural choice, not a marketing claim, and it's exactly the kind of default that prevents the failure pattern showing up in the research above.

If you don't know whether your own backend locks by default, that's worth finding out before you find out the hard way. Ask whoever built it, or ask the AI building it directly, to confirm every table holding real data has access rules turned on, not assumed. It's a five-minute question that either gets you a clear yes, or tells you exactly what to fix.

Structure isn't just clean pathways and a clear offer. It's just as much about what's actually protecting the data sitting behind the page nobody ever looks at.