How to audit AI-generated code for security vulnerabilities

The problem with trusting the autocomplete

AI coding assistants are genuinely impressive. They write boilerplate faster than any human, they fill in the tedious parts you'd rather skip, and they rarely complain. They also reproduce insecure patterns from their training data without blinking, because they have no stake in your production environment.

That's not a knock on the tools. It's just how they work. A model trained on the open internet has seen a lot of Stack Overflow answers from 2014 that use MD5 for password hashing and pass user input directly into SQL queries. It learned from that code. It will write code that looks like that code.

The risk compounds when you're working fast. You accept a suggestion, move on, accept another. By the time you have something that ships, you may have introduced a dozen small problems you never consciously chose to make.

So here's a practical process for catching them.

Step 1: Treat AI output as untrusted input

Shift your mental model. When you read AI-generated code, approach it the way you'd approach a pull request from a contractor you've never worked with before: assume good intent, verify everything that touches security boundaries.

The specific boundaries to focus on first:

• Authentication and session handling
• Anything that touches the filesystem
• Database queries, especially ones built from user input
• HTTP headers and CORS configuration
• Secret and credential handling
• Error messages (they leak more than people think)

None of these are exotic. They're the same categories that have caused real breaches for decades. AI code doesn't introduce new vulnerability classes so much as it reproduces old ones at higher volume.

Step 2: Run a static analysis pass before human review

Human review is slow and expensive. Static analysis is fast and cheap. Run it first, fix what it finds, then do the human pass on what's left.

For a Node.js or TypeScript project, a basic audit pass looks like this:

# install a linter with security rules if you haven't already
npm install --save-dev eslint @typescript-eslint/eslint-plugin eslint-plugin-security

# run it against your AI-generated code
npx eslint src/generated/ --rule 'security/detect-object-injection: error'

# check for known vulnerabilities in your dependency tree
npm audit

# for a broader structural scan
npx seaworthycode

The output won't catch everything. But it will catch the obvious things: insecure regex patterns, direct object injection, eval() calls, hardcoded secrets, and similar patterns that no reviewer should have to catch manually.

Step 3: Check for secrets and credentials explicitly

AI assistants sometimes generate example code with hardcoded credentials, API keys, or connection strings. Sometimes they lift these from context you gave them without realising it. Either way, they end up in your codebase and eventually in your git history.

Run a secrets scan separately from your general static analysis:

# trufflehog scans git history, not just the working tree
npx trufflehog git file://. --only-verified

# gitleaks is faster for quick checks
gitleaks detect --source . --verbose

If you find something, rotate the credential immediately before you do anything else. Removing it from code doesn't help if it's already in history and the repository is or was ever public.

Step 4: Trace data from input to output

This is the manual step that tools can't fully automate. Pick every place your application accepts external input: HTTP request bodies, query parameters, file uploads, environment variables read at runtime, webhook payloads. Then trace that data forward.

Where does it go? Does it reach a database query? Does it get written to a file? Does it get rendered into HTML? Does it get passed to exec() or spawn()?

AI-generated code frequently skips sanitisation steps because the training examples it learned from also skipped them. The model isn't lazy; it just doesn't know your threat model. You do.

Step 5: Review the dependency choices

When you ask an AI assistant to "add authentication" or "add file upload support," it will pick packages for you. Sometimes it picks popular, well-maintained packages. Sometimes it picks packages that are abandoned, have known CVEs, or are very small and obscure in ways that make supply chain compromise more likely.

Check every package the AI introduced:

# when was this package last published? who maintains it?
npm info <package-name>

# does it have open security advisories?
npm audit --audit-level=moderate

Be especially suspicious of packages with very low download counts, no repository link, or a single maintainer who hasn't committed in two years. AI assistants have no way to know that a package has been abandoned since their training data was collected.

Step 6: Don't skip the review because the code "looks right"

This is the trap. AI-generated code often looks clean. It's well-formatted, it uses modern syntax, it has comments. It passes a visual skim. That's not the same as being secure.

The vulnerabilities that matter aren't usually visible at a glance. They're in the assumptions: assuming input is validated upstream, assuming a token will always be present, assuming an error condition can't happen. Those assumptions are invisible in the code until something goes wrong.

The review process above won't catch every problem either. Nothing will. But running static analysis, scanning for secrets, tracing data flows, and auditing dependencies gets you substantially further than accepting the output and shipping it.

Seaworthy is a static analysis tool that scans a repository for security, resilience, and configuration issues across six categories, and is designed for exactly this kind of post-AI-generation audit workflow.