← All articles
Software

Is the code from your AI tool truly safe?

Marc Cornelius6 October 2026 · 4 min read
bij artikel: Software

Try searching GitHub for repositories with the word lovable in them. You'll find piles with a public .env file. That's the file holding your app's passwords and keys. Public. For anyone with a browser and a bit of patience. Ouch.

What the fk is a .env

In plain terms. A .env is your app's key box. It holds your database passwords, the API keys, the secrets nobody should see. Vibe tools sometimes just write those credentials straight into the code or leave them in a public repo. And then it's child's play to break into the matching database, often a Supabase. All the customer data in there is out in the open at that point. For anyone even slightly handy. Think email addresses, phone numbers, maybe payment details. We've seen more than once how wide open a database like that lies. You don't have to be a hacker, you only have to know where to look.

The unknown unknown

The nasty bit is that you often don't know this. You're vibe coding with AI, you've no programming background, and the tool tells you everything's safe. That's a sales pitch. You simply don't know. This is an unknown unknown: a risk you didn't even know existed. You see a working app and assume working means safe. It doesn't.

“A tool that tells you it's safe is a sales pitch. You only know once someone checks it.”

The last 25 percent

Vibe coding gets you to a working prototype at lightning speed. That's wonderful. But the last 25 percent is where the value lives and where it goes wrong. It's the dull, invisible work: who can see what (permissions and RLS), how you keep bots and abuse out (rate limiting), where your secrets are stored safely (env vars), and whether the login security holds up (auth). Plus whether you comply with GDPR and the EU AI Act, and whether it keeps working as more users pile in. That part isn't fun, isn't visible, and that's exactly why people skip it. And speed creates blind spots. And blind spots become data leaks. The nasty bit is that you see nothing from the outside. The app runs, the buttons work, the demo looks slick. Under the bonnet it can still be a sieve.

What you should never purely vibe code

The rule of thumb is simple. A little tool for yourself, no sensitive data? Vibe away, have fun. But a tool used by clients or colleagues that holds sensitive data? Never purely vibe code that. That needs real programmers who check the lot before it goes live. Because the moment someone else's data is involved, a fun experiment suddenly becomes a liability.

What to do if it's already happened

Say it's already gone wrong. Your secrets were public, or someone reports they could reach your data. What then? First rotate all your keys and passwords, so the old ones no longer work. Take the .env out of your public repo and check the history, because old versions stay findable too. Then look at who's been in the database in the meantime. And if you leak personal data, GDPR obliges you to report it to the Data Protection Authority. Not sure where to start? That's exactly the kind of unknown unknown where you're better off calling someone who's done this before than guessing yourself.

Placeholder data in a separate environment

Here's how we handle it in the Empathree Studio: it holds placeholder data only. Clients can happily keep building in it without running into API restrictions and without accidentally using real customer data. That separates the experimenting from the real work. And for hosting we deliberately chose Laravel Cloud, which may host within the EU in line with GDPR. Your data doesn't leave the EU. You make those choices up front, not after something goes wrong.

You vibe-coded it, we'll ship it

Vibed together an app yourself and unsure whether the security holds up? That's exactly where we step in. We do code audits and finish the last 25 percent: permissions, rate limiting, env vars, auth, GDPR and scalability. We do it daily, so you're on far surer ground than taking a tool at its word. Have your code checked before you put customer data in it. Fix it now, not when it's too late.

Marc Cornelius
Marc CorneliusFounder / AI Engineer

Marc bouwt dagelijks met AI en helpt bedrijven om ideeen snel om te zetten in werkende tools.

Follow on LinkedIn ↗

Want to talk this topic through?