If you build apps with AI tools and deploy them anywhere, two recent security stories should be on your radar: a breach affecting Vercel's deployment infrastructure, and a documented pattern of critical security vulnerabilities in apps generated by Lovable. Neither incident is obscure edge-case news. Both touch the exact platforms and tools that the vibe-coding community relies on most heavily.
The Vercel incident exposed something that had been a latent risk in deployment pipelines for years: the build environment is an extremely sensitive attack surface, and most teams treat it as a passive convenience rather than a security boundary. When a deployment system is compromised, the damage is not limited to one app or one credential. Build systems hold secrets for every service connected to every project. A single breach can expose database passwords, payment API keys, OAuth secrets, and third-party integration tokens simultaneously — all in a single event.
The Lovable security issue is structurally different but equally serious. Lovable, like most browser-based AI app builders, generates code that runs directly in the user's browser and communicates with backend services such as Supabase from the client side. The problem is that the API keys used for these connections are embedded directly in the JavaScript that gets sent to every visitor's browser. These keys are not secret in any meaningful sense — anyone who opens the browser's developer tools and looks at the network tab can read them. For read-only data this is manageable; for databases that allow writes, or for services that charge per API call, it is a critical vulnerability.
The Supabase connection is particularly important to understand. Supabase provides what it calls an "anon key" — a public key intended to be used in client-side code, but one that only provides safe access when Row Level Security (RLS) policies are correctly configured on every table. Lovable-generated apps, optimized for speed of creation rather than security configuration, frequently ship without RLS enabled. The result is a database that is effectively open to the public: any user, authenticated or not, can read and write any row in any table, with no access controls enforced at the database level.
These two incidents together tell the same story from different angles. Vercel's breach is a reminder that your deployment pipeline is part of your attack surface, not separate from it. Lovable's vulnerability pattern is a reminder that AI tools generate code that works, not code that is safe. Both failures are predictable, both are documented, and both are preventable — but only if you treat security as an active responsibility rather than something the platform handles for you.
The vibe-coding mental model — move fast, ship quickly, iterate in public — creates a strong headwind against security discipline. The entire value proposition is speed. But speed and security are only in tension if you treat security as something you add at the end. The builders who avoid these incidents are the ones who build a short security checklist into their publishing workflow from day one, not the ones who go back and audit after something goes wrong.
What should you do right now? If you have apps deployed on Vercel, rotate your environment variable credentials and audit your team access. If you have apps built with Lovable that connect to Supabase, check whether RLS is enabled on every table and test whether an unauthenticated request can read or write your data. Both of these are fifteen-minute tasks. The cost of skipping them is potentially unlimited. Specific step-by-step guidance for both platforms is in our companion article.