How to Audit Your AI-Built App: A 10-Point Security Checklist That Actually Works

You shipped your AI-built app. The demo worked. Payments go through. Users are signing up. Then someone posts your admin panel URL on Twitter.

This happens a lot more than you’d think. I’ve spent the last three weeks analyzing AI-built applications — apps made with Cursor, Lovable, Bolt, Replit, and Claude Code — and the same patterns show up every single time. Not edge cases. Not subtle race conditions. The same five classes of vulnerability, in the same order, in every app that hasn’t been explicitly hardened.

This is the checklist I use to audit them. It takes about two hours for a typical SaaS app. Most people find at least 3 critical issues their first time through.

1. The “Who Can See What?” Test (Data Isolation)

AI coding agents default to “make it work.” They do not default to “make it secure.” The most common pattern I see: an endpoint that returns all records filtered on the client side.

What to check:

• Log out. Can you hit /api/users, /api/orders, /api/projects directly?
• Change the ID in the URL. If your profile is /users/42, try /users/41.
• Check every list endpoint. Does it filter by the authenticated user, or does it return everything and let the frontend sort it out?

This alone catches about 40% of the vulnerabilities I find. AI agents love writing SELECT * FROM projects with no WHERE owner_id = ? clause. The frontend filters it, so the demo looks correct, and nobody notices until someone opens DevTools.

A 2026 analysis of 100 vibe-coded apps on Reddit found 94% had at least one vulnerability. Data isolation failures were the most common.

2. Auth Middleware: Does It Actually Run?

AI agents write auth middleware, then forget to apply it. Or they apply it inconsistently across route files. Or they write middleware that checks for a token but doesn’t validate what that token grants access to.

What to check:

• Hit every API endpoint without a token. Do you get 401s consistently?
• Check if role-based checks actually run. If you’re a regular user, can you hit the admin endpoints?
• Check WebSocket auth. AI agents almost never secure WebSocket connections — they set them up for real-time features and forget they bypass HTTP middleware entirely.
• Try JWT manipulation. Can you change the role claim in your token and get elevated access?

The most insidious pattern I see: auth middleware that runs on page load but not on API routes. The frontend redirects unauthenticated users, but the API happily serves data to anyone with curl.

3. Environment and Secrets: What’s Actually Exposed?

AI coding agents are terrible at secret management. They hardcode API keys. They commit .env files. They embed secrets in client-side JavaScript bundles. They generate random-looking “API keys” that aren’t random at all.

What to check:

• Search your git history: git log -p | grep -i "api_key\|secret\|password\|token"
• Check your built JavaScript bundles for any string that looks like a key. Framework env vars with NEXT_PUBLIC_ or VITE_ prefixes are embedded in the client bundle — make sure only truly public values use those prefixes.
• Review your .gitignore. Is .env in it? What about .env.local, .env.production?
• Check if your API has any endpoints that leak configuration. A GET /api/config endpoint that returns all environment variables is surprisingly common — the AI wanted a “config endpoint” and didn’t think about what that exposes.

One app I reviewed had the founder’s personal AWS root credentials in a config.json that was served at a public URL. The AI put them there because the CLI tool needed the keys to run and the AI found it “convenient.”

4. CORS: Your API Shouldn’t Be Anyone’s API

AI agents either don’t set CORS headers at all (blocking legitimate cross-origin requests and causing confusing bugs) or set Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true (allowing any website to make authenticated requests as your users).

What to check:

• What does your CORS configuration actually return? Check with curl: curl -H "Origin: https://evil.com" -I https://your-api.com/api/endpoint
• If you use credentials (cookies, auth headers), is Access-Control-Allow-Origin set to a specific origin rather than *?
• Are there any endpoints that reflect the Origin header back in the response? That’s a classic misconfiguration.

5. Rate Limiting and Abuse Prevention

AI-generated apps have no rate limiting. None. Your signup endpoint can be hit 10,000 times per second. Your password reset endpoint has no cooldown. Your search endpoint will happily run full-text searches on every request.

What to check:

• Hit any endpoint rapidly with a script. Does it eventually return 429s?
• Specifically test: login, signup, password reset, email verification, and any endpoint that queries a database with user-supplied text.
• Check if your file upload endpoint has a size limit. AI agents default to accepting files of any size.

6. Dependency Audit: What Did the AI Actually Install?

AI coding agents install packages they’ve “heard of” without checking if they’re maintained, have known vulnerabilities, or even do what the agent thinks they do. I’ve seen apps with 400 dependencies where only 12 were actually used — the AI kept installing libraries, trying them, and moving on without cleaning up.

What to check:

• Run npm audit or pip audit. Fix critical and high vulnerabilities.
• Check for packages that were installed but never imported. Remove them.
• Look for typosquatted packages. AI agents occasionally hallucinate package names, and if the typo happens to match a real malicious package, you’ve got a problem.
• Check your lockfile into version control and review changes to it in PRs. An unexpected new dependency is a red flag.

The OpenClaw supply chain crisis found 341 malicious skills — 12% of the entire registry — with screening evasion techniques. MCP servers and AI agent skills are the new npm, and the security infrastructure hasn’t caught up.

7. Database: Direct Access, Migrations, and Backups

AI agents love raw SQL queries with string interpolation. They don’t use parameterized queries unless explicitly told. They write migration files that drop and recreate tables instead of altering them. They don’t set up backups.

What to check:

• Search your codebase for any SQL query that uses string formatting (f"SELECT * FROM users WHERE id = {user_id}"). These are SQL injection vulnerabilities.
• Check if your database is accessible from the public internet. It shouldn’t be.
• Do you have automated backups? Are they tested? An AI agent that accidentally drops a table is not a hypothetical — it happens.
• Check if you’re using row-level security (RLS) in Postgres. If you’re using Supabase, RLS should be enabled on every table with user data.

8. Error Handling: What Leaks to the Client?

AI-generated apps leak stack traces, database errors, and internal paths in production error responses. This isn’t just ugly — it gives attackers a map of your infrastructure.

What to check:

• Trigger an error on purpose. Send bad input. What does the error response look like? Does it include stack traces, file paths, database table names?
• Check if your API returns different error messages for “user not found” vs “invalid password.” Consistent error messages prevent user enumeration.
• Make sure your 500 error page doesn’t reveal framework versions or server information.

9. AI-Specific: What Prompts Are Hardcoded in Your App?

If your app uses AI (and most AI-built apps do), check what prompts and system instructions are in your codebase. AI agents have a habit of including their own system prompt in generated code because they saw it as context and assumed it was part of the application.

What to check:

• Search for “system prompt,” “system message,” “You are,” or “instructions” in your codebase.
• Check if any AI API calls include API keys directly in client-side code. Keys for OpenAI, Anthropic, or other providers should never be in frontend bundles.
• If you’re using MCP servers, review which ones you’re connected to. The MCP ecosystem has 15,382 servers, 1,880 of which point to deleted repos.

10. The “Does It Run at 3 AM?” Test

AI agents build for the happy path. They don’t handle what happens when a downstream service is down, when the database connection pool is exhausted, or when a user uploads a 2GB file.

What to check:

• What happens when your database is unreachable? Does your app crash or degrade gracefully?
• What happens when a third-party API (Stripe, SendGrid, OpenAI) is down or returns errors?
• Do you have health check endpoints that verify all dependencies?
• What’s your deployment rollback process? Can you go back to the previous version in under 5 minutes?

What to Do If You Find Something

If you’ve made it through this checklist and found issues — congratulations, you’re in good company. Every AI-built app I’ve audited has had at least 3 of these problems. The apps that survive are the ones where someone sat down and went through this systematically.

If this feels like a lot, that’s because it is. Production hardening is not glamorous. It’s not what the AI demo video shows. But it’s the difference between “works on my machine” and “works for paying customers.”

Need help? I run dotfm — I audit AI-built apps and harden them for production. I find the things your AI coding agent doesn’t know it created. If you’ve got an app you’re about to launch and want a second pair of eyes, get in touch.

---

Further reading:

• The 5 Failure Modes That Kill Every AI-Built App — the patterns behind these checklist items
• The AI Agent Security Landscape Has 6 Layers — where human audit fits in the ecosystem
• MCP Census: 15,382 Servers, 1,880 Dead Repos — the supply chain you’re connecting to
• John Halloran’s MCP Safety Training — academic research showing no safety-tuned model refuses more than 35% of disguised MCP attacks
• OWASP Top 10 for LLM Applications — the emerging security standard for AI-powered apps