April 2026
Vibe Coding Has a Security Problem
Vibe coding doesn't create new classes of security failure. It compresses the time in which developers accumulate third-party trust, secrets, and operational debt they aren't prepared to service.
What Happened
In April 2026, Vercel disclosed that a third-party AI coding tool's infrastructure had been compromised. Users who had granted that tool OAuth access to their Vercel accounts had their environment variables — including API keys, database credentials, and service tokens — potentially exposed. The breach vector wasn't Vercel's infrastructure or any customer's code. It was a third-party application that customers had authorized to access their accounts.
This is a specific kind of failure: a supply-chain compromise through delegated access. You grant an application OAuth scopes to your deployment platform. That application gets breached. Now every secret accessible through those scopes is exposed — not because of anything you built, but because of a trust decision you made when you clicked “Authorize.”
This class of attack isn't new. But the conditions that make it dangerous are accelerating. And vibe coding is a meaningful part of why.
Why Vibe Coding Changes the Profile
Vibe coding doesn't introduce novel vulnerabilities. What it does is compress the timeline in which a developer accumulates third-party dependencies, secret issuance, and scope delegation. The security risks are familiar. The speed at which they compound is not.
When you build an app with AI assistance, you integrate faster. Claude scaffolds your auth layer, suggests a database provider, wires up transactional email. Each integration follows a pattern: issue a credential, paste it into an environment variable, grant OAuth access, deploy. In a traditional workflow, these decisions happen over days or weeks, with some natural friction. In a vibe-coded project, they happen in a single session.
The result is a specific kind of exposure. Every new integration adds four things to your operational surface:
Secret issuance
A new API key or token you need to store, rotate, and track.
Scope delegation
Permissions granted to a third party to act on your behalf.
Dashboard persistence
A credential stored in a UI you may not revisit for months.
Rotation overhead
Another entry in a playbook you probably haven't written.
In my case: one Vercel account, seven projects, ten upstream providers, 24 secrets. This is a small setup. I built most of it in evenings and weekends with AI assistance. The integration count accumulated faster than my awareness of what I'd actually authorized.
AI-assisted development also changes howyou integrate. You're more likely to follow a suggested setup flow without scrutinizing OAuth scopes. You're more likely to accept default token lifetimes. You're more likely to paste a service role key where a restricted key would suffice, because the AI-generated example used the permissive one and it worked. None of these are catastrophic individually. Accumulated across a dozen services in a single afternoon, they represent real exposure.
What Response Actually Looks Like
When the Vercel notification arrived, my first task was triage: which of my 24 secrets were accessible through Vercel's environment variable storage, which providers needed rotation, and in what order? I didn't have an inventory. I built one from memory and dashboard UIs, project by project.
During the rotation, I swapped a Supabase service_role key with an anonkey in one project. The app didn't crash. It silently lost write access. I didn't catch it until I tested the affected route 30 minutes later. This is the kind of error that happens when you're rotating credentials without a reference document — you introduce new failures while remediating old ones.
The full rotation took two hours for seven projects. Most of that time was spent not on the rotation itself, but on reconstructing what existed where: which project uses which Supabase instance, which GitHub PATs have no expiration date, whether a given Resend key is shared across projects or scoped to one.
This is the operational cost that fast-shipped projects defer. The integration takes ten minutes. The incident response takes two hours — not because the rotation is hard, but because the inventory doesn't exist.
A Practical Checklist
These are the specific practices that would have reduced my two-hour response to under 30 minutes. They're biased toward the failure modes that vibe-coded projects create: fast integration, default scopes, and deferred documentation.
Maintain a per-project secret register
For each project, document every credential: the key name, issuing provider, whether it's publishable or privileged, its expiration date, and which deployment contexts use it. Update this when you add a new integration, not after an incident.
Prefer short-lived credentials over static tokens
If a provider offers token expiration, use it. 90 days is a reasonable default. GitHub PATs, GCP service account keys, and database credentials all support this. A credential that expires is a credential you're forced to understand.
Minimize OAuth scopes at integration time
When an AI tool or third-party service requests OAuth access, read the scope list before authorizing. If it asks for write access and you only need read, deny and look for a more restrictive option. Default scopes are designed for the provider's convenience, not yours.
Distinguish publishable keys from privileged keys
Supabase anon keys and service role keys look similar in a .env file. So do Clerk's publishable and secret keys. Label them explicitly. When you rotate under pressure, the difference between a silent permission failure and a clean swap is whether you can tell them apart at a glance.
Test rotation on a non-critical project first
Before you need to rotate in production, practice on a side project. Generate a new key, swap it in the dashboard, redeploy, verify. If you've never rotated a specific provider's key before, you don't know their regeneration flow — and an incident is not the time to learn it.
Revoke unused tool authorizations immediately
After evaluating an AI coding tool, a CI integration, or any OAuth-connected service, revoke its access if you're not actively using it. Check your authorized applications page on GitHub, Vercel, and any provider that supports OAuth. The tool you tried once in January still has access in April.
Write a rotation playbook before you need one
For each provider in your stack: where do you generate a new credential, where do you update it, what do you redeploy, and how do you verify? This takes 20 minutes when you're calm. It takes two hours when you're responding to a breach notification.
None of this requires enterprise tooling. But it does require treating credential management as part of the project, not something that happens around it. The speed of AI-assisted development is genuine. The operational debt it creates is also genuine. The gap between the two is where incidents become expensive.
Work with Nektar
We build production tools for businesses with real domain expertise. If your stack is growing faster than your security posture — let's talk.
Book a free data audit