It Works. That Is the Problem.
Your team built something impressive with AI. The application handles authentication. It processes payments. It scales under load. The demo went well. Investors are interested. Customers are signing up.
None of that means it is secure.
AI code assistants optimize for one thing: producing code that runs. They do not optimize for code that resists attack. The gap between "functional" and "secure" is where breaches live. That is why every AI-built application needs a dedicated AI code security audit before it handles real user data.
The Confidence Problem
The most dangerous AI-generated codebases are the ones that look professional. Clean variable names. Consistent formatting. Logical architecture. Comments that explain the reasoning. It reads like a senior developer wrote it.
That surface quality creates confidence. And confidence suppresses scrutiny. The team reviews the code, sees that it makes sense and approves the pull request. Nobody checks whether the authentication flow actually prevents unauthorized access under adversarial conditions because the code looks like it does.
Real Vulnerability Patterns We Find
Authentication Bypasses That Look Correct
AI-generated auth flows are the most dangerous pattern we encounter. The code implements login, registration, password reset and session management. It uses JWT tokens. It checks credentials against the database. On review it appears complete.
What is missing:
- No rate limiting on login endpoints. An attacker can brute-force credentials at thousands of attempts per second.
- JWT tokens with no expiration or with expiration set to years. A stolen token works indefinitely.
- Password reset tokens that are predictable because the AI used
Math.random()instead of a cryptographic generator. - Session identifiers that are not rotated after privilege escalation. A user who logs in carries the same session ID from their unauthenticated state.
Each of these individually is a high-severity finding. Together they represent a complete authentication compromise.
SQL Queries That Work but Are Injectable
This is the pattern that refuses to die. AI assistants generate database queries using string interpolation instead of parameterized queries with remarkable consistency.
// AI-generated: looks correct, works in testing
const results = await db.query(
`SELECT * FROM orders WHERE user_id = '${userId}'
AND status = '${status}'`
);
// What it should be
const results = await db.query(
'SELECT * FROM orders WHERE user_id = $1 AND status = $2',
[userId, status]
);The first version works perfectly with normal input. It returns the correct data. Tests pass. The application behaves as expected. And it is trivially exploitable with a single crafted input value. This is CWE-89 and it gives an attacker full read access to every table in the database.
API Endpoints with No Rate Limiting
AI assistants build API endpoints that handle requests correctly but include no protection against abuse. No rate limiting. No request throttling. No abuse detection. The endpoint processes every request at full speed regardless of volume or source.
For payment endpoints this means an attacker can enumerate valid credit card numbers. For search endpoints it means competitors can scrape your entire dataset. For authentication endpoints it means credentials are brute-forceable. The OWASP API Security Top 10 lists this as a primary attack vector.
Hardcoded Secrets That Survive to Production
AI models reproduce patterns from training data. When generating configuration files or environment setup code they insert placeholder values that follow real credential formats. sk-proj-abc123 for OpenAI keys. AKIA prefixes for AWS access keys. supersecret for JWT signing keys.
These look like placeholders. Developers assume they will be swapped for environment variables. In 23% of the AI-generated codebases we audit the placeholders are still present in production configuration.
Why Scanners Miss This
Static analysis tools are built to find patterns that human developers write. AI-generated vulnerabilities look different. The code structure is clean. The logic is correct. The vulnerability is in what is absent rather than what is present.
Missing rate limiting does not trigger a scanner because there is no vulnerable code to scan. There is an absence of protective code. Missing token expiration does not trigger because the JWT implementation is technically valid. Predictable randomness does not trigger because Math.random() is a legitimate JavaScript function.
Automated tools check for the presence of bad patterns. AI-generated vulnerabilities are the absence of good patterns. That requires a human reviewer who knows what to look for.
What a Targeted Audit Reveals
At Sherlock Forensics we audit AI-generated codebases with a methodology built for AI-specific vulnerability patterns. Every finding maps to OWASP Top 10 and references the relevant MITRE CWE entry.
A typical AI code audit produces 15-30 findings across critical, high and medium severity. The critical findings are almost always in authentication and database access. The remediation is straightforward once identified. The hard part is finding them in code that looks correct. If your app was built with Cursor, Bolt or Lovable, start with our vibe coding security audit. Ready to go? Order online.