73% is the number. Over the past six months, our engineering team reviewed 500+ AI-generated pull requests across 14 client projects, and 73% contained at least one security vulnerability that would have failed a standard code review.
The measurement was straightforward. Every PR in the sample was written primarily by an AI code generator โ Copilot, Cursor, or Claude โ and then passed through the same manual review we apply to human-written code. We counted a PR as failing if it contained a defect that a reviewer following our checklist would flag and block. We did not count style issues, missing tests, or performance concerns; only security defects. Four categories accounted for nearly all of the failures. Each is described below: what it is, why AI produces it, and how to catch it.
Hardcoded Secrets
Present in 41% of the PRs โ the single most common failure. These are API keys, database passwords, and JWT secrets embedded directly in source code instead of loaded from configuration.
AI models produce this pattern because they learn from public repositories, where hardcoded credentials are disturbingly common. The model reproduces what it has seen most often, and a literal key sitting inline is a frequent example in its training data.
To catch it, confirm that every secret is externalized to an environment variable and that no credential appears in the diff. Secret-scanning in CI helps, but a reviewer skimming for string literals that look like keys or passwords will catch most cases in seconds.
Missing Input Validation
Present in 38% of the PRs. AI generates the happy path beautifully but consistently skips boundary checks, type validation, and sanitization of user inputs.
This happens because the model optimizes for code that demonstrably works against the obvious case. The example that satisfies the prompt rarely includes malformed input, so the generated code rarely defends against it. The failure modes โ empty values, oversized payloads, unexpected types โ are exactly the ones the training example omitted.
To catch it, verify that every user input is validated and sanitized before use, and that error messages stay generic rather than leaking internal details. Trace each input from its entry point and ask what happens when the value is missing, malformed, or hostile.
SQL Injection
Present in 27% of the PRs. The cause is string concatenation in database queries instead of parameterized statements. The AI produces code that runs correctly against test data โ and that is also exploitable.
The model generates concatenated queries for the same reason it hardcodes secrets: the pattern is widespread in public code, and it reads as simple and direct. Nothing in the immediate output signals the vulnerability, because the query returns the right result during normal use.
To catch it, confirm that all database queries are parameterized and that the principle of least privilege is applied to every data-access path. Any query built by joining strings with user-supplied values should be blocked on sight.
Insecure Authentication Patterns
Present in 19% of the PRs. This category covers weak token generation, missing rate limiting on login endpoints, and session management that does not follow OWASP guidelines.
Authentication is where the gap between "works" and "secure" is widest, and AI sits on the wrong side of it. A login flow that authenticates a valid user looks complete, so the model stops there โ without the rate limiting, token entropy, and session handling that a secure implementation requires.
To catch it, check that authentication endpoints enforce rate limiting, that tokens are generated with sufficient entropy, and that session handling matches OWASP guidance. These are rarely visible in a quick read, so review auth code against a fixed standard rather than by inspection alone.
Working the Categories in Review
These four categories map directly to a focused checklist that catches the issues in under 15 minutes per PR:
- Are all secrets externalized to environment variables?
AI writes the first draft. Humans make it secure. That is not a limitation โ it is the model that works.