Before a vibe-coded app takes a real user, run fourteen checks: row level security on every table, no secrets in the client, separate development and production, no agent with production write access, dependency audit, input validation, rate limits, authentication you did not invent, personal data you do not need deleted, backups you have restored once, logging without secrets, MCP configs clean, identity verification by an API rather than a prompt, and app store and processor rules read before submission. Each check below comes with the prompt to paste into your tool and the source that shows why it matters.

The 2025 and 2026 failure record is the reason this list exists: Lovable apps without RLS, a Replit agent deleting production, Moltbook's 1.5 million leaked tokens, and 45 percent of AI-generated code failing security tests. None of these needed a genius attacker. They needed a missing checkbox. For the full picture of the category, start with vibe coding in 2026.

Data and access

1. Row level security on every table. Why: without it, a table in an exposed schema is readable and writable by anyone with the public key. The Lovable disclosure found 170 or more projects and 303 endpoints exposed this way. Prompt: "List every table. For each, confirm RLS is enabled and show me the policies. Any table without a policy that restricts rows to the authenticated owner, fix now."

2. The service role key never touches the client. Why: the service role bypasses RLS. Supabase: never use a secret key in the browser. Prompt: "Search the client bundle and every client-side file for any key other than the public anon key. Move every third-party call into a server function that reads keys from environment variables."

3. Authentication is the platform's, not the model's. Why: hand-rolled session handling is where AI-generated code fails most; Veracode measured 86 percent failure on cross-site scripting and 88 percent on log injection. Prompt: "Use the platform's built-in auth. Remove any custom password, token or session code you wrote. Enforce email verification and, for admin roles, a second factor."

4. Personal data minimized. Why: the Tea app exposed 72,000 images, including 13,000 selfies and government IDs, from an unauthenticated storage bucket. Data you do not store cannot leak. Prompt: "List every field of personal data we store and why. Delete any we do not need. Confirm no verification images or ID documents are stored in our buckets."

Environments and operations

5. Development and production are separate, with separate keys. Why: the Replit incident happened because the agent had write access to production during a code freeze. Prompt: "Confirm dev and prod use different databases and different API keys. Confirm the AI agent's credentials cannot write to production."

6. Backups exist and you have restored one. Prompt: "Enable automated backups. Perform a test restore to a scratch database and show me the result."

7. Logging without secrets. Prompt: "Review every log statement. Remove any that print tokens, keys, passwords, session URLs or personal data."

8. Rate limits on every public endpoint. Prompt: "Add rate limiting to every server function and every auth endpoint. Return 429 with a retry hint."

Code and supply chain

9. Dependencies audited, including the ones the model invented. Why: OWASP's AI coding guidance lists hallucinated dependencies and outdated dependencies with known vulnerabilities among its threat categories. Prompt: "Run a dependency audit. Remove any package that does not exist on the registry or has no maintainer. Pin versions."

10. Input validation and output encoding everywhere. Prompt: "Validate every input at the server boundary with a schema. Encode every output. Show me the validation for each endpoint."

11. Secrets scanned in the repo and in MCP configs. Why: GitGuardian found 28.65 million new hardcoded secrets on public GitHub in 2025 and 24,008 secrets in MCP configuration files. Commits assisted by a coding agent leaked secrets at twice the baseline rate. Prompt: "Scan the repository history and every MCP config file for secrets. Rotate any you find. Add a pre-commit secret scanner."

12. A human approves every merge. Why: OWASP: require explicit developer approval before merging any AI-generated code.

Identity, compliance, distribution

13. Identity verification is an API call, not generated code. Why: if your users pay, sell, bet or must be over 18, verification is regulated and adversarial: liveness against replay and deepfakes, document forensics, sanctions screening, audit trails. Generated code does none of that. deepidv's hosted flow is one server-side call, POST https://api.deepidv.com/v1/sessions, that returns a session_url for the user and a webhook when they pass (docs); the MCP server lets your assistant set it up from inside Cursor or Claude Code, and verification for vibe coders is the overview. Every check is sealed as a proof at proof.deepidv.com. Prompt: "Add the deepidv MCP server. Create a workflow with ID_VERIFICATION, FACE_LIVENESS and PEP_SANCTIONS. Create a verification session from a server function when a user reaches [the trigger], redirect to session_url, and mark the user verified on the session.status.verified webhook."

14. Platform rules read before submission. Why: Apple's guideline 5.3 and Google Play's gambling policy require licenses per jurisdiction, geo-restriction and age controls for real-money gaming, and Stripe prohibits games of chance, sweepstakes with prizes and adult content outright. A rejected submission or a frozen processor account is a security incident for a startup. Prompt: "Summarize the App Store, Google Play and payment processor rules that apply to this app's category and list anything we do not comply with."

The one-prompt audit

Paste this before launch and read the answer slowly:

"Audit this app as a security reviewer. For each of the following, answer yes or no with evidence: RLS on every table; no secrets in client code; separate dev and prod; agent cannot write to prod; dependencies audited; inputs validated; rate limits present; platform auth used; personal data minimized; backups tested; logs clean; MCP configs clean; identity verification handled by an external service; platform rules reviewed. List every no as a task."

Then run the platform's scanner (Lovable's Quick Scan and Deep Scan, or Wiz and Aikido integrations where available) and have one human who did not build the app read the policies.

Frequently asked questions

What is the most common security flaw in vibe-coded apps?

Missing row level security on the database, which lets anyone with the public key read and write every table. It was the flaw behind the Lovable disclosure and the Moltbook breach.

Do the platform security scanners make my app safe?

They catch the obvious gaps. Lovable's own docs say the scans do not replace a thorough review and that you remain responsible for your app's security. Use them, then check the policies yourself.

Should I let the AI write the login and password code?

No. Use the platform's built-in authentication. AI-generated code fails security tests about 45 percent of the time in Veracode's testing, and authentication is where the cost of failure is highest.

Can I generate the KYC flow with a prompt?

You can generate the integration; you cannot generate the verification. Identity verification is a regulated, adversarial service with liveness, document forensics, sanctions lists and audit requirements. Call an API, and let your assistant wire it in through an MCP server.

How do I keep secrets out of MCP config files?

Prefer MCP servers that authenticate with OAuth so there is no key in the file, scan configs with a secret scanner, and keep configs out of the repository.

What should I do if I find a leaked key?

Rotate it immediately, check the provider's logs for use, and add a pre-commit scanner so it does not happen again. GitGuardian found most leaked secrets were still valid years later.