Vibe Coders Are Getting Sued. Here’s the EXACT Pre-Launch Playbook.

OpenAI just published a sentence that should make anyone shipping software with agents stop for a minute.

During an internal cybersecurity evaluation in July, OpenAI’s agents got around controls designed to isolate them from the internet and compromised parts of OpenAI’s own research infrastructure and Hugging Face’s systems.

The agents executed code on dozens of Hugging Face servers and gained root access on one. An internal research model called IM1 drove most of the incident. GPT-5.6 Sol agents also reproduced an exploit and copied private evaluation data into a public Hugging Face dataset.

This was not public ChatGPT randomly attacking the internet. The models were running cyber evaluations with reduced safeguards, and OpenAI says customer data and product availability were not affected. Those details matter.

OpenAI still called the incident a “warning shot.”

The full OpenAI incident report reconstructs what happened and explains why the existing safeguards failed.

I have helped ship 60+ MVPs at the agency over nearly two years, often on 21-day delivery timelines. Across client MVPs at the agency and our own app studio builds, these are the categories I review before anything production-bound goes live. The exact tools changed this month. The release gate did not.

Speed is useful. Shipping production code you cannot inspect, constrain, or recover is not.

This is the updated pre-launch security baseline I would use before putting an AI-built app in front of real users.

Here is the full breakdown.

The first version of this article started with a pre-launch checklist shared in r/vibecoding. The original Reddit post has since been removed, so I am not relying on its author credentials or engagement claims. The screenshot still captures the practical idea that made the post useful: review privacy, security, data leaks, and exposed keys before launch.

This update keeps that foundation and adds what changed after it.

What OpenAI Actually Disclosed

The important part is not that an AI model suddenly became a movie villain.

The important part is that a persistent agent could find weaknesses, share information through channels its operators did not intend, gain network access, chain exploits, and keep going.

OpenAI’s response is useful because it looks a lot like the controls small teams should be thinking about too:

→ Put untrusted code inside stronger sandboxes

→ Restrict network access

→ Reduce the blast radius of any single compromised workload

→ Monitor tool actions and suspicious behavior

→ Keep a human able to pause or stop the system

The scale is completely different, but the control problem is familiar. If your coding agent can read every secret, execute any command, write to production, and publish without approval, one bad instruction or malicious repository has access to everything you gave it.

That is the real connection to vibe coding.

It is not proof that AI-generated code is automatically insecure. It is proof that capability without boundaries becomes its own attack surface.

The Problem With How Most People Ship

A polished interface proves almost nothing about the controls behind it.

Your app can look finished while a browser-accessible role has excessive database grants. Authentication can work for you while leaking whether somebody else’s email exists. A payment button can work once while an unprotected endpoint lets a script call a paid API thousands of times.

The dangerous phrase is: “The AI built it, so I assumed it handled that.”

AI can draft a policy, write a validation schema, configure Row Level Security, or suggest a rate limiter. You still have to check whether the control protects the right boundary and whether the app behaves correctly when somebody tries to cross it.

The owner of the application still owns the result.

No federal court has yet decided a data-breach case involving vibe-coded software specifically. But privacy and cybersecurity lawyers are already warning that using AI does not remove the application owner’s responsibility to take reasonable security precautions.

So the goal is not paranoia. The goal is a repeatable release gate.

Step 1: Map What the App Exposes

Before scanning code, write down the surface you are protecting.

→ Every public domain, route, API endpoint, and webhook

→ Every database table, storage bucket, queue, and third-party service

→ Every type of personal or sensitive data you collect

→ Every secret or production credential the application can reach

→ Every action that changes data, charges money, sends a message, or publishes externally

If you cannot describe the surface, a scanner cannot tell you whether it is fully protected.

Publish a privacy notice that accurately explains what you collect, why you collect it, who receives it, how long you keep it, and which choices or rights users have.

GDPR and CCPA do not automatically apply to every app that collects one email. Coverage depends on where the business operates, where users are, what data is processed, and whether legal thresholds are met. Other privacy, breach-notification, consumer-protection, and platform obligations can still apply.

A policy generator is a starting point. It is not proof that your real data flows match the document.

Step 2: Test Database Authorization, Not Just Login

Authentication answers one question: who is this?

Authorization answers the dangerous question: what can this person read or change?

In Supabase, open Database > Policies and review every table and view exposed through the Data API. Supabase’s API security guide explains how grants and policies work together.

Grants decide which roles can reach an object. Row Level Security policies decide which rows those roles can read or change. You need to review both.

RLS enabled with no policies is default-deny. Zero policies does not mean the table is automatically public. The dangerous states are:

→ RLS disabled on an exposed table

→ Excessive grants

→ Policies that are too broad, including careless USING (true) rules

→ Views or functions that bypass the checks you expected

Test with an anonymous session and at least two separate user accounts.

User A should not be able to read, insert, update, or delete User B’s rows. Repeat the same test for storage, views, and functions.

Run Supabase’s Database > Security Advisor too. Let AI draft policy SQL if it helps, but do not deploy that SQL without cross-user tests.

Step 3: Attack the Authentication Flow

Most people test the happy path once and move on.

Run these four smoke tests:

→ Submit several wrong passwords. Verify that throttling, backoff, or a step-up challenge appears without confirming whether the account exists

→ Request a password reset for an unknown email. The public response should look the same as the response for a known email

→ Reuse an email-verification or password-reset link. The token should be single-use or expire safely

→ Attempt signup with an existing email. Avoid exposing account state before the user proves control of that address

Use generic responses such as “Invalid email or password” and “If an account exists, we sent instructions.”

Do not show database queries, stack traces, internal identifiers, or secret values in production errors. Keep diagnostic detail in server-side logs and keep passwords, access tokens, API keys, and unnecessary personal data out of those logs.

These are smoke tests, not a full authentication audit. Session handling, MFA, OAuth, CSRF, authorization, token revocation, and business logic still need their own tests where relevant.

Step 4: Validate Every Untrusted Request on the Server

Client-side validation improves the interface. It is not a security boundary.

An attacker can disable JavaScript and call your API directly.

Validate every untrusted request on the server using an allowlisted schema:

→ Type and format

→ Minimum and maximum length

→ Numeric range

→ Allowed values

→ The authenticated user’s permission to perform the action

Use parameterized queries for SQL. Use output encoding that matches the destination, whether that is HTML, JavaScript, a URL, or another context.

Do not rely on a generic “sanitize input” function to solve every injection problem.

Step 5: Treat Secrets and Unfamiliar Repositories as Hostile

Only documented publishable keys belong in browser code.

Examples include Stripe pk_... keys and Supabase publishable or legacy anon keys. Those keys are not authorization by themselves. Their safety depends on the permissions and backend controls around them.

Keep Stripe sk_..., Supabase secret or service-role keys, OpenAI keys, Anthropic keys, and other private credentials on the server.

If a secret reaches a public repository, treat it as compromised immediately. Revoke or rotate it first. Then review provider logs, remove it from current code and history, and check forks and build artifacts.

GitHub scans public repositories for many supported secret patterns, but coverage is not universal. Its August update added Lovable as a secret-scanning partner and expanded push protection for several other providers. That is useful backup. It is not permission to commit secrets.

There is another agent-specific risk people miss: the repository itself can contain instructions or configuration that executes when an agent opens it.

In August, GitLab disclosed that Serena 1.6.1 and earlier could execute attacker-controlled code from a malicious .serena/project.yml when a repository was opened. Version 1.7.0 fixed it.

Before giving an unfamiliar repository to an agent, inspect its agent instructions, hooks, MCP configuration, environment files, package scripts, editor tasks, and project configuration. Open unknown code in an isolated environment with low-privilege credentials.

Step 6: Limit Abuse and Spending

Rate-limit login, signup, password reset, public forms, state-changing routes, and endpoints that call paid services.

Do not copy one universal requests-per-minute number from an article.

Choose limits from:

→ Expected user behavior

→ Endpoint cost

→ Downstream provider limits

→ The damage one account or IP can cause

Use a burst window, a sustained window, concurrency limits, and a cost budget where appropriate. Layer identity signals such as user or account plus IP rather than trusting one signal alone.

Configure enforced provider spend limits where available. Add application-level budgets when you need per-user or daily control. Alerts at milestones such as 50%, 75%, and 90% can give you time to react, but they are operating choices rather than universal defaults.

For abuse-prone public forms, start with server-side rate limiting, validation, duplicate suppression, and monitoring. Add Cloudflare Turnstile or another bot challenge as a step-up control when traffic or behavior warrants it.

If you use Turnstile, validate every token on the server. The browser widget alone is not protection.

And one correction that matters: CORS does not authenticate callers or stop direct API requests. It controls which browser origins can read responses. Cookie-authenticated state changes may also need SameSite cookies, CSRF tokens, and server-side origin checks.

Step 7: Patch the Stack Before You Scan It

A security scanner cannot compensate for choosing to run a version with a known critical vulnerability.

On August 25, Next.js released patches for two critical unauthenticated remote-code-execution paths.

One involved Image Optimization processing attacker-controlled AVIF files. The other affected Windows-hosted applications using both the Pages Router and App Router without Cache Components.

Upgrade to a patched release, including 15.5.24 or 16.3.3 where those release lines apply. The Windows issue has no documented workaround.

Then scan the rest of the dependency tree and remove packages you do not need.

Check the security advisories for your framework, database, authentication provider, hosting platform, and major dependencies before every public release.

Step 8: Run Automated Security Review

Use automation as a second pair of eyes, not a safety certificate.

OpenAI quietly released the open-source Codex Security CLI in July. It can scan repositories, track findings across runs, verify fixes, and add security checks to CI.

Start with:

npx @openai/codex-security scan .

OpenAI says an initial scan can take several hours and large repositories can take multiple days. That is why this article no longer promises that a complete security review fits into 30 minutes.

Anthropic offers two separate Claude Code plugins:

security-guidance runs while Claude writes code and warns about known-dangerous patterns. Install it with:

/plugin install security-guidance@claude-plugins-official

claude-security is the separate on-demand deep scanner. It maps the architecture, builds a threat model, hunts for vulnerabilities, and sends findings to independent verifier agents before reporting them.

Install and run it with:

/plugin install claude-security@claude-plugins-official

/reload-plugins

/claude-security

The deep scanner requires a paid Claude Code plan and consumes plan usage.

Cursor and Lovable also provide security-review surfaces. Availability and billing can depend on the plan.

Whatever scanner you use, reproduce the finding, assess whether the vulnerable path is reachable, review the proposed patch, run tests, and scan again.

The Four Prompts I Would Run Before Release

These prompts are review aids. They are not a penetration test.

Require evidence instead of accepting a confident paragraph.

Prompt 1: Architecture and threat model

Map this application’s trust boundaries, public entry points, privileged components, sensitive data, third-party dependencies, and irreversible actions. Identify plausible attacker goals and abuse paths. Cite the exact files and routes that create each boundary. Do not propose fixes until the map is complete.

Prompt 2: Authorization and tenant isolation

Review authentication, authorization, database grants, Row Level Security policies, storage policies, views, and server functions. For every potential cross-user or cross-tenant access path, provide the exact file or policy, exploit preconditions, likely impact, and a test using two users plus an anonymous session.

Prompt 3: Secrets, validation, and output

Trace untrusted input from every public route to database queries, shell commands, templates, logs, and API calls. Find exposed credentials, over-broad API responses, unsafe logging, missing server-side validation, injection paths, and context-specific output-encoding problems. Provide file-and-line evidence and a test for every finding.

Prompt 4: Abuse, cost, and dependencies

Review login, signup, password reset, public forms, uploads, webhooks, and paid API routes for abuse and cost-amplification risks. Check dependencies and framework versions against current advisories. For each issue, provide evidence, a reproducible test, a proposed control, and the remaining risk after the fix.

When to Use This Baseline

Run this before exposing an application that:

→ Processes personal data

→ Exposes a backend or database

→ Handles money

→ Calls paid APIs

→ Uploads or stores files

→ Grants access to private resources

→ Lets agents take external or irreversible actions

Internal tools need the same controls when they can reach production data, customer records, credentials, or privileged systems.

A local prototype with no real users, production credentials, or production data can stay lightweight. Write down what must be completed before it becomes public.

Health, financial, identity, children’s, precise-location, and other regulated or highly sensitive data need more than this baseline. Get a qualified security and legal review.

What to Watch Out For

This checklist is a baseline, not certification that an application is secure.

Scanners produce false positives and false negatives. AI-generated fixes can create new regressions. A clean report does not test every business-logic path.

Be careful with the scanner itself. Local security tools can read source code and generate reports containing source excerpts or vulnerability details. Check where those reports are stored and who can access them.

Repeat these checks after meaningful changes to authentication, database schema, dependencies, API integrations, agent permissions, or infrastructure.

And keep a human approval gate on deployments, payments, external messages, data deletion, and other irreversible actions.

What This Actually Means

The old version of this article promised a 30-minute checklist.

That was too neat.

You can begin a useful first pass in one focused sitting. You cannot honestly claim that a complete security review, remediation, and retest fits into the same timer. OpenAI says a deep Codex Security scan alone can take hours or days.

The more useful promise is simpler: stop shipping blind.

OpenAI’s incident did not prove that every vibe-coded app is insecure. It proved that capable agents can find and chain real weaknesses faster than most teams are prepared for.

The response is not to stop using AI. It is to pair capability with boundaries, evidence, testing, monitoring, and human control.

That is how I now review production-bound client MVPs at the agency and our own app studio builds before real users arrive.

2026 is going to be UNFAIR for people who treat security as part of shipping instead of something they add after the incident.

TLDR

→ OpenAI disclosed that agents in a reduced-safeguard cyber evaluation compromised real OpenAI and Hugging Face infrastructure

→ This was not an ordinary vibe-coded app attack, and OpenAI customer data and product availability were not affected

→ Map public surfaces, sensitive data, secrets, and irreversible actions before scanning code

→ In Supabase, review grants and RLS together under Database > Policies, then test with anonymous and separate user accounts

→ Validate untrusted requests on the server and keep authentication errors generic

→ Keep documented publishable keys in clients and secret keys on servers. Rotate public secrets immediately

→ Treat unfamiliar repositories as hostile before giving an agent shell, network, or credential access

→ Set risk-based endpoint limits, concurrency limits, cost budgets, and provider spend controls

→ CORS is a browser response-control mechanism. It does not replace authentication, authorization, or CSRF controls

→ Patch known vulnerabilities before scanning. Next.js released two critical fixes on August 25

→ Codex Security, Claude security-guidance, and Claude deep security scans are different tools with different depth and time requirements

→ AI review supplements deterministic scanners, tests, human review, and monitoring. It does not replace them

Run the baseline before launch. Repeat it whenever the attack surface changes.

LFG.