Vibe-Coding Without a Safety Net: When the Prompt Ships the App and Nobody Locks the Door

Meet Norbert. Norbert is not a developer. Norbert has an idea, a credit card and an AI that answers 'build me an app' with suspiciously pretty code. Two afternoons later there is a working product and Norbert is proud. Norbert should be sweating.

What is actually happening

Vibe-coding turns an idea into running code at record speed. That is great, no sarcasm. The catch: 'it runs' and 'it is secure' are not the same sentence. The AI happily walks Norbert through putting the app on a server or a hosting platform, wiring up a database and importing real customer data. Security never came up in the entire conversation. Why would it? Norbert never asked.

And before you file Norbert under 'weekend hobbyist': Norbert works at your company. Sales, finance, marketing, take your pick. He has a real problem, a real deadline and zero patience for a three-month IT ticket queue. So he builds the fix himself. With company data. And IT has no idea.

Where it starts to hurt

Defaults are rarely secure. They are convenient. Secrets end up in the code, in the frontend bundle or in Git history. The database is reachable from the internet with zero access rules. Authentication? 'Nobody knows the URL anyway.' Bold strategy. And then, the cherry on top, the real data moves in: names, email addresses, maybe payment details. All in one place, all wide open. A buffet with a sign that says 'please don't'.

Want an example?

This is what it looks like when the service_role key ships to the frontend, readable by anyone who can press F12:

# .env, baked into the frontend build and readable in the browser
VITE_SUPABASE_URL=https://yourproject.supabase.co
VITE_SUPABASE_SERVICE_ROLE_KEY=eyJhbGciOiJIUzI1...  # god mode. in the browser. for everyone.
STRIPE_SECRET_KEY=sk_live_51Hxxxx                   # also not great

In Supabase, the service_role key bypasses every access rule you have. Put it in the frontend and anyone can dump the entire database in two clicks. Norbert does not know that. The AI did not mention it. And the Stripe key sitting next to it is basically an invitation to move money on Norbert's tab.

The usual suspects

• Secrets in the code, the frontend or Git history instead of server-side in a secret manager.
• A database with no access rules (row level security) that anyone on the internet can reach.
• No real authentication, just 'security through nobody-knows-the-URL'.
• Sensitive data imported without encryption and without a legal basis. GDPR would like a word.
• No backups, no logging, no plan B for the day it all goes sideways.

Shadow AI: the IT that IT doesn't know about

Norbert's app is just the tip of the iceberg. Underneath sits something that is about to hit pretty much every company: shadow AI. AI tools that are already part of daily work but were never registered with internal IT. The chatbot on a personal account where someone pastes the proposal for your biggest customer. The browser extension that 'just summarizes' emails. The meeting bot that quietly takes notes in every Teams call. The AI agent someone handed mailbox and drive access with a single click.

Here is the uncomfortable part: nobody does this to be malicious. People just want to get their work done. But every one of these shortcuts sends company data to a provider with no contract, no data processing agreement, no check on where the data ends up and no answer to whether it is used for training. Security and privacy don't fail here. They simply get skipped.

Three departments, three credit cards, three AI organizations

It gets really fun (it doesn't) when the sprawl becomes organized. Marketing spins up a team workspace with AI provider A. Engineering opens its own organization with the same provider for API keys, on a different credit card, obviously. Sales is trialing provider B, and somebody still has a trial account with provider C from last year that never got cancelled. Nobody asked, nobody approved. The result: several organizations at one provider, plus several providers, all holding company data, none of them centrally managed.

What that means in practice:

• No single sign-on, no enforced MFA, every organization runs its own user management.
• No offboarding: people who leave often keep access to the workspace, chat history and uploaded files included.
• API keys in organizations nobody rotates, because nobody knows they exist.
• No logs, no audit trail: after an incident or a GDPR access request, nobody can say which data went where.
• No record of processing that matches reality, and no idea what any of it costs.

How to spot shadow AI

Good news: shadow AI is only invisible as long as nobody looks. Typical traces:

• AI subscriptions on corporate cards and expense reports.
• Consents for unknown AI apps in Entra ID or Google Workspace with OAuth access to mail, calendar or drive.
• AI domains in proxy or DNS logs, and hits in cloud app discovery (Microsoft Defender for Cloud Apps, for example).
• Browser extensions with full access to every website.
• Meeting bots suddenly showing up as call participants.

Why bans alone don't work

The reflex makes sense: block AI, send a company-wide email, done. It works about as well as a 'no snacking' sign in the break room. Give people no approved alternative and they reach for their personal phone, personal account and personal credit card. The usage doesn't go away. It just goes dark.

The real point is simple: if the company doesn't offer anything, employees decide for themselves. Which means Norbert decides, based on gut feeling and a pricing page. If you want to prevent that, you have to move first and roll out AI in a controlled way before someone else makes the call for you.

What actually helps: offer, policies, training, control

1. Roll it out, on your terms

Give people approved AI tools that are good enough that nobody wants to go around them. With an enterprise contract and data processing agreement, single sign-on, central administration and clear settings for data retention and training. Exactly one organization per provider, owned by IT, not five owned by five departments. And for every Norbert who wants to build: a safe sandbox without production data, with templates that already have secret management, authentication and database rules baked in.

2. Policies people actually read

Not a 40-page PDF gathering dust on the intranet. An AI policy that fits on one page and gives clear answers:

• Which AI tools are approved, and where is the current list?
• Which data is allowed in? A simple traffic light helps: public yes, internal with approved tools, confidential and personal data only with sign-off.
• Who can create organizations, workspaces and API keys with AI providers? IT. Full stop.
• How do you request a new tool, and how fast do you get an answer?
• What has to happen before a home-built app touches real data? A review. No exceptions.

3. Training, not scare tactics

'AI is dangerous' is not training. It is a warning everyone forgets by lunch. Good training is practical: which data goes where, how to get real value out of an approved tool, what the usual suspects look like and who to ask before things blow up. In the EU it is not optional anymore, either: since February 2, 2025, Article 4 of the EU AI Act requires companies that use AI systems to take measures for sufficient AI literacy among their staff.

4. Better control

Trust is nice. Visibility is better. A few levers that work right away:

• Restrict user consent for third-party apps and set up an admin consent workflow, so AI agents can't get into mailboxes with one click.
• Turn on cloud app discovery, assess AI services and block unapproved ones once there is an alternative.
• Where providers support it, verify your company domain and pull accounts using company email into the central organization.
• DLP rules for your most sensitive data, so customer records don't end up in the nearest chat window.
• Take inventory regularly: which AI tools, organizations and API keys exist, and who owns them?

For every Norbert who builds anyway

Vibe-coding is not the enemy. Flying blind with real data is. The minimum dose of security before the first real record goes in:

1. Secrets live server-side. Never in the frontend, never in Git. Use .gitignore, use a secret manager, rotate anything that leaked immediately.
2. Turn on database access rules. The safe default is 'closed', not 'open'.
3. Put real authentication in front of anything that touches data.
4. Before the first real record: who can access what, where does the data live, and is any of this legal?
5. Get someone to look at it from the outside before customer data goes in. An honest review now beats a call from the data protection authority later.

The actual problem

Vibe-coding democratizes building, but not securing. The tools get loud at 'build me something' and go suspiciously quiet at 'lock it down'. As long as that stays true, we keep mass-producing beautiful apps with the back door propped open. Security is not a sticker you slap on at the end. It is the foundation.

And in the end, this isn't a tech problem. It's an organizational one. AI is coming into your company either way. The only question is whether it walks in through the front door with a contract, rules and training, or sneaks in through the back on Norbert's credit card.

So, Norbert: keep building, please. Just lock the door before you carry the real data inside. And dear IT: hand Norbert a key before he cuts his own. Turn on MFA. Think purple.