This is not a hypothetical. The research on AI-built apps is genuinely alarming.
Most vibe-coded apps accidentally ship API keys inside the front end (your OpenAI key, database URL, Stripe keys), which means anyone can open DevTools, copy them, and use your backend on your dime. This prompt finds them, moves the real ones server-side, and tells you which to rotate.
Spin up 3 sub-agents to audit this repo for exposed secrets and fix them.
Sub-agent 1: scan everything that ships to the browser (src/, components/, pages/, public/, and any VITE_* or NEXT_PUBLIC_* variables) for hardcoded API keys, database URLs, Stripe keys, and auth tokens. Report every hit as file + line number.
Sub-agent 2: scan the full git history (git log -p) and any committed .env files, because deleted keys stay live in old commits.
Sub-agent 3: sort each finding into "true secret" (OpenAI/Stripe secret key, Supabase service_role, DB connection string, must move server-side) vs "publishable/anon key" (only safe if Row Level Security is on).
Then give me one table (file, line, key type, risk). For each true secret: move it into a server-side .env file, add .env to .gitignore, and replace the client call with a backend API route / serverless function / Supabase Edge Function that reads the key from process.env so it never reaches the browser. Finish with a checklist of exactly which live keys I must ROTATE now, because deleting them from code does not revoke them. Never print the actual key values.With no limits, anyone can spam your backend with unlimited requests, crash your API, or quietly drain your account on the endpoints that cost money per call. This prompt finds those endpoints and adds real throttling.
Spin up 3 sub-agents to add rate limiting to this app.
Sub-agent 1: list every API route / endpoint / serverless function, and flag the ones that cost money per call (they hit a paid API like OpenAI, an email/SMS provider, or my database) or have no auth. Those are the "denial of wallet" targets.
Sub-agent 2: check what protection already exists (any per-IP or per-user throttle, any HTTP 429 handling) and report what is missing.
Sub-agent 3: detect my stack and write the limiter. Use express-rate-limit if this is Express, or @upstash/ratelimit with a sliding window if this is Next.js / serverless / edge. Limit by IP AND by logged-in user, return HTTP 429 with a Retry-After header, and set a tighter limit on the expensive AI routes than on the cheap ones.
Then apply it to every endpoint sub-agent 1 flagged, show me the diff, and give me one line per endpoint explaining the limit you chose.If your app blindly trusts user input, someone can inject bad data, break your database, or run malicious queries, and AI-generated apps skip this step most of the time. This prompt adds server-side validation and locks the database itself.
Spin up 3 sub-agents to fix input validation across this app.
Sub-agent 1: find every place user input enters (form handlers, API route bodies, URL/query params, webhooks) and list each with file + line.
Sub-agent 2: check whether each one is validated on the SERVER before use (browser-only validation does not count, it is bypassable), and flag any raw SQL that concatenates user input instead of using parameterized queries.
Sub-agent 3: if this is a Supabase/Postgres app, list every table and whether Row Level Security is on, because the public anon key can read any table with RLS off.
Then: add a Zod schema for each input and reject bad data server-side with .safeParse(), convert concatenated SQL to parameterized queries (or the Supabase client / Prisma), and write the missing RLS policies so the database itself enforces who can read and write each row. Show me the before and after for every fix.