Skip to main content

← All writing

I will not log into your vibe coded app

I will not log into your vibe coded app

I recently saw a team inside a company build an internal tool to store sensitive business data. The page title still contained the name of the vibe coding platform they used to build it. The URL was a random string assigned by the hosting service. The login screen asked for OAuth but requested an absurd number of scopes. The backend was a free-tier cloud database with no SLA, no support contract, and almost certainly no row level security configured on the tables.

This is where we are now. People are storing company IP in apps held together by prompts and default configurations.

The default configuration problem

Services like Supabase and Firebase are genuinely good tools. They’re well-engineered, well-documented, and designed to let developers move fast. The problem is that “move fast” assumes you know what you’re doing.

They have been known to create new tables with row level security disabled by default. That means any authenticated user can read any row in the database unless the developer explicitly writes policies to prevent it. Firebase Realtime Database historically shipped with open read/write rules in development mode, and plenty of apps went to production with those rules still in place.

If you’re a developer who understands these defaults, you configure security before you ship. If you’re someone who prompted an app into existence and the AI never mentioned RLS, you ship an open database and have no idea.

The AI doesn’t warn you. It generates code that works. Working and secure are not the same thing.

My personal rule

I’ve adopted a simple heuristic. If an app looks vibe coded and requires a login, I check two things.

First: does it use OAuth from a trusted provider like Google or GitHub? If yes, I check the scopes. If it asks for email and basic profile, fine. If it asks for access to my drive, calendar, contacts, and the ability to send email on my behalf, I close the tab.

Second: does it ask for a username and password? If yes, I don’t create an account. I have no way of knowing whether the person who built this app understands password hashing, session management, or secure storage. The vibe coding fundamentals I wrote about earlier are exactly the things most vibe coders skip. I explicitly warned against building your own auth. Most people building these apps didn’t get that memo.

When I hand a vibe coded app my password, I’m trusting that the builder knows what bcrypt is. That’s a bet I’m not willing to make.

GDPR is collateral damage

This gets worse when you factor in data protection regulation. GDPR applies to any app that collects personal data from EU residents. It doesn’t matter if the builder is in the US, India, or anywhere else. It doesn’t matter if the app was built in an afternoon. The moment you collect an email address from someone in the EU, you have legal obligations.

You need informed consent. You need to explain what data you collect and why. You need to store it securely. You need to be able to delete it on request. You need to notify authorities within 72 hours of a breach.

Most vibe coders don’t know GDPR exists. EU-based vibe coders who should know better often assume it only applies to big companies. It doesn’t. It applies to the app you prompted into existence last Tuesday that now has forty users and a Supabase table full of email addresses with no RLS, no privacy policy, and no breach response plan.

The regulatory exposure is real, and nobody is talking about it because nobody thinks their little vibe coded tool counts. It counts.

Some nuance

I want to be fair here. Not every vibe coded app is a security disaster. Some people building with AI tools do understand infrastructure. Some are experienced developers using vibe coding for speed, not as a substitute for knowledge. The tools themselves aren’t the problem - Supabase, Firebase, Clerk, and others are solid products when configured correctly.

The problem is the gap between “I can build this” and “I understand what I’ve built.” AI closes the first gap instantly. The second gap stays wide open. And that second gap is where user data leaks through.

I also recognize that my personal rule is conservative. OAuth isn’t bulletproof either. Excessive scopes are their own risk. But it’s a better baseline than trusting an unknown builder with my raw credentials.

Concluding

We’ve democratized the ability to build apps. We haven’t democratized the understanding of what it means to hold someone else’s data. That’s the gap that should concern everyone right now.

The vibe coding wave is producing thousands of apps that collect logins, store personal information, and run on infrastructure their builders can’t explain. Some of them are storing company secrets on free-tier databases with default security settings. Some of them are violating GDPR without knowing the regulation exists.

If you don’t understand what happens to my data after I type my password, you shouldn’t be asking for it.

On this page
Aug 5, 20268 min read

Ten AI security problems hiding in plain text

This article argues that AI security risks extend far beyond model jailbreaks and prompt engineering, into every piece of text an AI can read. Natural language now behaves like soft code, where logs, documentation, commit messages, wikis, support tickets, web pages, PDFs, and search results can all carry hidden instructions for agents. The author walks through ten concrete scenarios where ordinary text fields become attack surfaces, often with delayed or indirect activation through internal tools and multi agent pipelines. The core message is that information and instruction have blurred, and any text accessible to AI must be treated as part of the security model. Teams need to rethink access, editing rights, retrieval, and agent capabilities accordingly.

  • Composable architecture
  • AI engineering
  • Cloud & infra
Sep 4, 20267 min read

Building MCP Profile Hub part 2, one MCP server is the wrong abstraction

This article argues that a single, monolithic MCP server per platform is the wrong abstraction, especially for complex systems like Contentstack. Instead, it introduces managed profiles as the right unit of configuration, aligned to jobs, teams, or access boundaries rather than product catalogs. Each managed profile bundles a curated set of tools, Automations, and agents, enriched with account context, while still respecting individual user identities and permissions. Profiles can only narrow what a user can do, never expand their underlying platform permissions. This makes configurations easier to reason about, review, audit, and replicate across environments, and offers a scalable pattern for enterprise platforms with many roles and capabilities.

  • Composable architecture
  • AI engineering
  • API design