"Expected behavior": who decides an app should be public?

If someone on your team built a handy little app last month, do you know whether anyone on the internet can open it? In May a security firm went looking for apps people had built with AI tools and left on the open web, and it found a lot of them. The numbers weren't what stuck with me, though. It was a two-word phrase one of the platforms used when it responded: "expected behavior."

The firm, RedAccess, said it found about 380,000 publicly accessible applications and other assets built with tools from Lovable, Base44, Netlify and Replit, and that about 5,000 of them contained sensitive corporate information, Security Boulevard reported. Axios verified a number of them, and they're very concrete. One was a shipping company app laying out which vessels were going to which ports, and another held internal financial information for a bank in Brazil. The same report also lists an app a hospital used to hold summaries of conversations between doctors and patients, along with patient complaints.

WIRED's reporting, summarized on Slashdot, shows how open these apps were. Many let in anyone who simply found the URL, and others had "only trivial barriers," like asking a visitor to sign in with any email address. Of the 5,000, the researchers found close to 2,000 that seemed to reveal private data, and IANS Research put it more bluntly, saying around 40% had "virtually no security or authentication of any kind." Dor Zvi, who cofounded RedAccess, explained how this happens in the same WIRED piece, and it's about as simple as it gets: "People can just start using it in production without asking anyone. And they do."

Two fair readings

Replit's CEO, Amjad Masad, answered on X by writing "Public apps being accessible on the internet is expected behavior," and added that "privacy settings can be changed at any time with a single click," according to Security Boulevard. He also pointed out that Replit lets users choose whether their apps are public or private.

Which way you read that probably says a lot about where you sit. If you build software, it sounds obvious, since a public app is public and that's what the word means. If you work in security, it sounds more like a shrug. I think both readings are fair, which is a big part of why this is worth talking about. He's technically right that the apps did what they were set to do, and according to Axios the privacy settings on some vibe-coding tools were set in a way that made the apps accessible, leaving users to switch them to private by hand. Nothing was hidden.

But "a single click" cuts both ways, because if privacy is one click away, a leak is one forgotten click away too. The person who forgot may never have heard the word authentication, and there's no real reason they should have. They wanted to see which ships were going where, not take a lesson in access control.

A default is a decision

Every default is a guess about who's using the tool. Public by default makes plenty of sense for someone showing off a weekend project, because they want a link they can post, a login screen would only annoy them, and there's nothing in the app worth stealing. That isn't who's building now, or at least not only them. The apps in this report held bank financials and summaries of patient conversations, built by someone in operations or finance or at a hospital because a tool finally let them do it (which, honestly, is the good part of this story). The defaults just didn't move along with the audience.

IANS's advice to security teams is practical and a little grim: "Security teams should assume any vibe coded apps are public by default and check the app's security settings," and "Treat them as production from minute one." It also tells them to make protections the baseline, and to expect that employees will deploy apps without understanding the authentication or privacy settings. I'd take that last point as a design brief rather than a complaint, and as an accurate description of the people building these apps rather than an insult. Most knowledge workers shouldn't need to understand authentication any more than they need to understand how their email gets routed, so the setting that protects them ought to be on already when they arrive.

So the question in the title does have an answer, more or less. The platform decides whether an app is public at the moment it picks the default. The builder only gets to decide whether to change it, and only if they know there's something to change.

None of this is a reason to slow builders down. These tools spread because someone with a real problem could fix it in an afternoon without filing a ticket, and I'd hate to lose that, so I don't think the answer is a security course before anyone's allowed to build a form. What I'd rather see is defaults picked for whoever is actually at the keyboard. If that's a nurse manager or a logistics coordinator, the safe option should be the one they get without thinking about it: apps start private, get shared on purpose, and only go public when someone chooses that and knows what it means. It's the default we went with at Workbricks, where apps start private and are shared only with the people who need them, because the people building apps now aren't the people these defaults were designed for, and the defaults should catch up with them.