How security engineers actually assess AI-generated code

A developer sends you a pull request. It works, the tests pass, it's clean and well-commented. And then they mention, almost in passing, that an AI wrote most of it. If your stomach tightens slightly, good, that's the correct instinct. But "AI wrote it so be careful" isn't a review method. So here's the actual framework a security engineer applies, the specific places to look and the specific tools to run, when code arrives without a human author who can explain their reasoning.

Because the problem with AI code isn't that it's bad. It's that it's plausible. It looks exactly like code someone understood, and it will confidently do the wrong thing in the specific places that matter most.

First, the mindset shift: review the code, not the coder

Normally when you review a human's code, you're partly reading their intent. You can ask why. You can trust that a senior engineer probably thought about the auth check. With AI code, there is no intent and no one who reasoned about the edge cases, the model produced the statistically likely next token, not a considered decision. So you review it the way you'd review code from a talented intern who has read everything and understood nothing about your system: fast, fluent, and dangerous exactly where context matters.

That reframing tells you where to look. AI is strongest at the mechanical middle of a function and weakest precisely at the boundaries, the places where code meets untrusted input, meets authority, meets secrets, meets your specific architecture. So that's where you aim your attention.

The five places AI code breaks, in order

1. Input handling and injection. AI loves to build the happy path. Check every spot where external input reaches a query, a command, a file path, or a template. Does it parameterise, or does it concatenate? Models frequently produce SQL built by string-joining and shell commands assembled from user input, because those patterns are all over their training data. This is the number-one thing to grep for.

2. Authentication and authorisation. AI will cheerfully write an endpoint that works perfectly and checks nobody's permission to call it. It implements the feature, not the access control around the feature, because the feature was what you asked for. Every new route, every data access: ask who's allowed to do this, and check the code actually enforces it.

3. Secrets. Models paste API keys, default passwords, and tokens straight into source, sometimes real-looking ones absorbed from training data. Never assume a committed credential is fake.

4. Dependencies. AI confidently imports libraries, occasionally ones that don't exist (a hallucinated package name is a supply-chain attack waiting to be registered by someone malicious), and often pulls in outdated or vulnerable versions.

5. Error handling and crypto. It tends to swallow errors silently and to invent its own crypto or misuse real crypto, hardcoded IVs, weak modes, home-rolled token generation. Treat any security-sensitive primitive it wrote as guilty until proven innocent. [Your own example here — the most plausible-looking AI-written flaw you've personally caught in review.]

The tools that automate the first pass

You don't eyeball all of this by hand. Run the machine over it first, then spend your human attention on what's left. These are the real, free tools I'd point into any AI-authored PR:

# Did it commit any secrets?
gitleaks detect --source .
# Broad static analysis for injection, insecure patterns, etc.
semgrep --config auto .
# Python-specific security linting
bandit -r .
# Known-vulnerable dependencies
pip-audit          # Python projects
npm audit          # Node projects

# Did it commit any secrets?
gitleaks detect --source .
# Broad static analysis for injection, insecure patterns, etc.
semgrep --config auto .
# Python-specific security linting
bandit -r .
# Known-vulnerable dependencies
pip-audit          # Python projects
npm audit          # Node projects

For deeper coverage, CodeQL (free for open source) catches whole classes of vulnerability by querying the code like a database. Run the fast ones on every PR; they'll surface the obvious injection, the committed key, the vulnerable dependency, before you read a single line yourself.

The question the tools can't answer

Here's what no scanner catches, and where the real review happens: does this code do the right thing for our system? The AI didn't know your trust boundaries, your data classifications, which service is internet-facing, which input is attacker-controlled in your particular architecture. It wrote generically correct code for a system it couldn't see. Your job is to check it against the one it's actually going into.

That's why AI doesn't remove the security engineer from the loop, it changes what the loop is for. The mechanical review (is this line injectable) increasingly belongs to tools. The contextual review (is this safe here, given everything the model didn't know) is more valuable than ever, because the volume of plausible-looking code just went up by an order of magnitude, and plausible is exactly the failure mode humans are needed to catch.

Don't fear AI code, and don't ban it, both are the amateur move. Review it like what it is: fast, fluent, context-blind, and confidently wrong in precisely the places that matter. Then run the scanners, and spend your judgment where they can't reach.

What's your workflow for reviewing AI-written code, do you run it through a gauntlet, or eyeball it? And what's the most convincing flaw you've caught? I want to build a shared checklist from the replies.