Security of AI-generated code: the pass that admits no shortcuts

TLDR: Generated code is not more insecure than human code, but it fails differently: it under-validates, over-trusts, embeds secrets naturally and sometimes invents dependencies someone malicious already registered. The defense: know that pathology, always verify dependencies, direct your review at the hot spots (inputs, authentication, secrets) and automate the net with scanners and CodeRabbit on every pull request. With agents in parallel, this pass either scales with the rest or becomes the hole.

This guide is for anyone already working with agents who wants the speed not to be paid in incidents. It completes the general technique of the reviewing AI code guide with the dimension where a failure’s cost is measured not in time but in scares: security.

The honest frame: agents write code with whole classes of human failures already solved, and in exchange introduce their own pathology. Knowing it is half the defense.

1. Know AI’s typical security failures

Generated code has a structural bias: it is trained to work, and security is exactly what you do not see when it works. Hence its characteristic pathology.

Missing validation: the impeccable happy path and the hostile input never considered, because the example it learned from did not consider it either. Embedded secrets: the API key in the code “so the example works”, with complete naturalness. Trust in input: queries built by concatenation, unsanitized file paths, cheerful deserialization. And the old pattern with expert confidence: the encryption method or configuration that was reasonable years ago, written with total assurance.

None of this is exotic: it is application security’s eternal list, with the difference that it arrives in volume and with a confident prose that disarms suspicion.

2. Verify every dependency before installing it

Generated code’s genuinely new vector is invented dependencies. Models complete plausible library names that do not exist, and that hallucination has a known exploitation: registering the invented package with malicious content and waiting for someone to install what their agent suggested.

The systematic version: automated dependency analysis in the repository (modern package managers and platforms ship it) warning about packages with known vulnerabilities or suspicious traits before they reach the main branch.

3. Direct security review at the hot spots

Full security review of every change does not scale, and it does not need to: failures live concentrated in known hot spots, and directed review covers them.

Flow transparency helps here too: with tools like Cline, which show each step before applying it, changes in hot zones are seen coming instead of discovered in the final diff. And with Claude Code, the project’s instructions file should include the house security rules: how secrets are handled, which validation libraries are used, what is forbidden.

4. Automate the safety net in the repository

Human discipline needs a net, and the net gets built once. The three pieces: the secret scanner that blocks commits with keys inside, dependency analysis on every pull request, and CodeRabbit as the automatic reviewer, whose catches include the obvious security problems: the concatenated query, the missing validation, the embedded secret. Free for open source projects, with a limited free tier on private repos and from $24 a month.

With that net, security scales with agent volume: every pull request passes the same filters without depending on the on-duty human being sharp. Step 3’s directed review is reserved for where the machine does not reach, which is design judgment.

The complete system (agent, automatic reviewer, directed review, scanners) is what lets you say the generated code in your house is as safe as the human kind, with evidence rather than faith. The whole sector lives in AI for software development.

Common mistakes

Installing suggested dependencies unverified. It is the new vector and the thirty-second habit that neutralizes it. No proposed dependency gets installed without checking it is what it claims to be.

Reviewing security only when “the change is about security”. Failures arrive in the normal change that touches a form. The hot spot map exists for that.

Trusting that tests cover security. Generated tests verify the happy path: hostile input has to be requested explicitly, in the tests and in the review.

Saving the secret scanner for production, instead of blocking the commit.

A committed secret must be rotated even if deleted afterwards.

Frequently asked questions

Is AI code more insecure than human code?

It is different: it solves whole classes of human carelessness and brings its own pathology (missing validation, secrets, invented dependencies). With this guide’s system, the net result is comparable or better. Without it, volume multiplies the characteristic failures.

What should I set up first?

The secret scanner and dependency verification: the two cheapest protections against the two most expensive failures. The automatic reviewer comes right after.

Can I ask the agent to review its own security?

As an additional pass yes, and asking it to explain hostile-case handling is revealing. As the only review no: it shares the context and biases of what it generated. The clean-eyed reviewer (automatic or human) is not substituted.

Does this change with parallel agents?

The automatic net scales on its own (every pull request passes the filters), and directed review becomes the sizing criterion: do not launch in parallel more hot-zone work than you can review carefully.