Working and secure are different bars
AI coding assistants are trained and evaluated overwhelmingly on whether generated code runs and satisfies the prompt's functional requirement — not on whether it would pass a security review. This gap produces a specific, recurring pattern: code that compiles, runs, and does exactly what was asked, while containing well-known vulnerability classes that a security-focused developer would never introduce deliberately.
The four patterns that show up most often
- Hardcoded secrets. AI assistants sometimes generate example code containing realistic-looking placeholder API keys, or echo back a real secret a developer pasted into a prompt for context. Either way, a hardcoded secret that makes it into committed source code is compromised the moment it's pushed to any shared repository.
- SQL injection via string concatenation. Building a database query by directly concatenating a variable into the query string remains one of the most well-documented vulnerability classes in software, and AI assistants still generate this pattern regularly when not explicitly prompted toward parameterized queries.
- Dangerous dynamic execution.
eval(),new Function(), and shellexec()calls on any input that could originate from an untrusted source allow arbitrary code execution — AI assistants sometimes reach for these for apparent flexibility without flagging the risk in the same response. - Unsanitized DOM XSS. Assigning user-influenced data directly to
innerHTMLwithout sanitization allows script injection — a pattern that's easy for a fast-moving prompt-and-paste workflow to miss, since the resulting code works perfectly for any non-malicious input used during testing.
Why "it works when I tested it" isn't a security signal
All four of these vulnerability classes produce code that behaves completely correctly under normal, non-malicious testing conditions — the vulnerability only manifests when a specifically crafted malicious input is provided, which is exactly the scenario a quick manual test never happens to cover.
Why a pattern scan is a useful first pass, not a replacement for review
Regex-based pattern matching for these specific vulnerability signatures is fast, deterministic, and catches a meaningful share of the most common issues before code ever reaches a human reviewer or a full static analysis tool — but it is not equivalent to a comprehensive security audit, and passing a pattern scan doesn't guarantee code is free of other, less common vulnerability classes.
Building this into an AI-assisted development workflow
Teams that have adopted AI coding assistants at meaningful scale increasingly treat a fast automated scan of generated code as a standard step before code review, precisely because the volume of AI-generated code makes manually re-deriving "does this have a hardcoded secret" for every snippet impractical at scale, while an automated first-pass check is nearly free to run.
What to do when the scan flags something
A flagged pattern is a starting point for review, not an automatic verdict — some flagged patterns will be false positives in context, and confirming the actual risk (is this variable genuinely user-controlled? is this secret actually real and live?) still requires a human look at the surrounding code before deciding how to fix it.
Frequently Asked Questions
AI coding assistants are primarily optimized to produce code that runs and satisfies the functional request in the prompt, not to pass a security review. This produces a recurring pattern: code that works correctly under normal testing while containing well-known vulnerability classes that only manifest with specifically crafted malicious input.
Hardcoded secrets, SQL injection via string concatenation, dangerous dynamic execution functions like eval(), and unsanitized DOM XSS via innerHTML assignment are all commonly cited patterns. Each tends to produce code that behaves correctly during normal testing, which is exactly why it's easy to miss without a specific scan.
No. A pattern-based scan checks for specific, well-known vulnerability signatures via regex matching, which is fast and catches a meaningful share of common issues, but it isn't equivalent to a comprehensive security audit or full static analysis. A clean result reduces known risk without guaranteeing the absence of other vulnerability classes.
Yes. An automated scan is a useful, fast first-pass check, but flagged (and unflagged) patterns still benefit from human review to confirm real risk in context — for example, whether a flagged variable is genuinely user-controlled, or whether a detected 'secret' is actually a live, real credential.
Yes — the AI-Generated Code Vulnerability Checklist genuinely regex-scans pasted code for hardcoded secrets, SQL injection via string concatenation, dangerous eval()/exec() usage, and unsanitized innerHTML/XSS patterns, returning a real pattern-matched risk score rather than a manual reading checklist.