“It Runs” Is Not the Same as “It’s Safe”
July 22, 2026
On April 20, 2026, a security researcher posted on X that he could read other Lovable users’ source code, database credentials, AI chat history, and customer data, all from a free account in just five small requests to Lovable’s servers. Lovable’s first public response was that the exposure had been intentional behavior.
This is a story about a real platform, but it isn’t really about Lovable. It’s about a problem AI coding tools widen rather than solve.
The visible part of software is the easy part for AI to get right. Here is what it may do effectively:
- Build an app that loads.
- The buttons do what their labels promise.
- The forms submit.
- The login screen hands you a dashboard.
For someone who isn’t an engineer, every cue that says this is real software lines up and so does the assumption that it must therefore be safe software.

Sofia Stolberg
CEO & Founder of PilotoMail
Sofia is the CEO and cofounder of Piloto 151 and PilotoMail. After launching her region’s first coworking space in 2013, she cracked the code to scaling beyond square footage through Virtual Offices and mail automation. Today, she helps operators unlock higher profits with her Freedom from Square Feet methodology.
Nothing in the experience pushes back on that assumption. No error message announces your authentication is theater.
No banner warns that your customer data is publicly readable. The software doesn’t beep when you’re a few characters away from leaking everyone’s information. It just keeps running. The gap between works and safe is not visible. AI coding tools, while fluent at the visible layer, almost never cross into the layer where safety lives.
Safe code are hundred of small checks the user never sees. Some may include:
- Who is allowed to read which records?
- What happens when somebody tries the same thing fifty times in ten seconds?
- What gets logged?
- What gets encrypted?
- What happens when a request comes in that nobody expected?
Lovable’s flaw is known in the industry as BOLA (Broken Object Level Authorization). Which means: a missing “are you allowed to see this?” check on the back end of the app. The lobby looked perfect, while the backdoor was unlocked.
Picture a demo car driving cleanly around a test loop. Everything is working as expected. You don’t see who installed the brakes. AI is excellent at the dashboard and the paint. The brakes live somewhere you can’t inspect, and somewhere AI doesn’t think to ship.
Now consider who shipped this particular flaw. Lovable is not a hobby project. It’s a startup with a reported $6.6 billion valuation, a real engineering team, and a HackerOne bug bounty program that pays outside researchers to find exactly this kind of problem. Its customers include Uber, HubSpot, and Microsoft. With every advantage in their hand, the company still shipped a flaw that exposed its users’ source code and database credentials. Its first public response was that the exposure had been intentional.
If a company with that much infrastructure can ship a bug of that severity, think about what’s likely to happen when a non-technical solo builder ships their own platform without any of those safeguards: no security team, no code review, no bug bounty, no real way to know what BOLA even is. That isn’t a knock on the builder. It’s a reality check on the difficulty curve.
Here’s the part of the Lovable story that should matter most to anyone thinking about building something themselves with AI. The founders and small teams who built their products on Lovable were not hacked. The platform leaked itself exposing: source code, AI chat history — which routinely contains pasted API keys and other secrets. And most importantly their customers’ personal data. All of it readable, the researcher reported, by anyone with a free account.
That’s what building with AI looks like in practice. You inherit the security posture of every layer underneath you: the AI tool, its hosting, its permissions model, its API, and you don’t get to audit any of it.
Here’s the takeaway. “It works” tells you little about whether it’s safe. Judging whether software is safe to handle other people’s information is its own discipline, distinct from building it and distinct from using it. Even teams whose entire job is that discipline still miss things in production. If you’re shipping something that handles other people’s data, you should not be the only person judging whether your code is ready to ship, not because you aren’t smart enough, but because it takes proper care and attention to build great software.
– Sofia