AI Security Review of Generated Code

Why Generated Code Has Security Risk

The core reason agent-generated code carries security risk is that agents optimize for the task they are given. If you ask for a search feature and say nothing about input handling, the agent produces a search feature that works, and it may not sanitize the input because nothing in the request signaled that this matters. The agent is not careless in a human sense. It simply has no reason to address a requirement that was never stated.

This is compounded by the fact that insecure code often looks correct. A SQL query built by concatenating user input runs fine in testing and passes functional tests, while remaining wide open to injection. The vulnerability is invisible to the feedback loop the agent uses to verify its work, because the tests check that the feature works, not that it is safe. This is why security cannot be left to the agent's normal verify loop and needs a separate process.

There is also a training-data effect. Models learn from large bodies of public code, and public code includes a great deal of insecure code. An agent can reproduce a common but unsafe pattern because that pattern appears frequently in what it learned from. Better prompting and better models reduce this, but it remains a source of risk worth understanding.

Common Vulnerability Classes

Injection flaws are the most frequent. SQL injection, command injection, and cross-site scripting all arise when untrusted input flows into a sensitive operation without proper handling. Agents introduce these when the prompt does not require parameterized queries, output encoding, or input validation.

Broken authentication and authorization is another common class. An agent might implement a feature that works for the intended user but fails to check whether the current user is actually allowed to perform the action. Missing authorization checks are easy to overlook because the feature behaves correctly in normal testing, where the tester is already authorized.

Unsafe handling of untrusted input goes beyond injection. Insecure deserialization, unvalidated redirects, path traversal, and improper file upload handling all stem from trusting input that should not be trusted. Agents handle the happy path and may not consider how the input could be abused.

Secret exposure rounds out the common list. Agents sometimes hardcode credentials, log sensitive values, or include secrets in code that gets committed. This happens when the agent generates a working example with a placeholder that becomes a real secret, or when it adds logging that captures more than it should.

A Practical Review Process

The first layer is automated security scanning on all agent-generated code before it merges. Static analysis tools catch many of the common vulnerability classes automatically, and they run without human effort once configured. Integrating a scanner into the pipeline so that no agent change merges without passing it establishes a baseline that catches the most frequent problems. This connects naturally to a broader automated code review setup.

The second layer is security-focused prompting. By building security requirements into the task descriptions and the project-level instructions, you ensure the agent addresses common vulnerability categories proactively. Instructions that require parameterized queries, input validation, output encoding, and authorization checks shift the agent toward producing secure code from the start, rather than catching insecure code after the fact.

The third layer is a dedicated security review pass. Some teams run a second agent specifically tuned for vulnerability detection over the changes, an AI reviewer whose only job is to find security problems. This is a form of AI code review focused on security, and it catches issues that the general feedback loop misses because it is looking specifically for them.

The fourth layer is human review of sensitive changes. Not every change needs deep security review, but changes to authentication, authorization, input handling, cryptography, payment processing, and anything touching untrusted data do. Routing these changes to a human with security knowledge, regardless of how confident the agent was, is the backstop that catches what automation and prompting miss.

Treat Agent Code Like External Contributions

The most useful mental model is to treat agent-generated code exactly like code from a new contractor. You would not merge a contractor's code into a sensitive system without review, no matter how capable they seemed. The same discipline applies to agents. The code gets functional review plus security review before acceptance. This framing avoids both extremes: the naive trust that ships vulnerabilities and the blanket distrust that throws away the productivity benefit.

The most mature teams have made this routine. Agent code flows through the same security gates as human code, no exceptions. The gates are automated where possible and human where necessary, and the result is that the team captures the speed of agent-assisted development without lowering its security bar. This balance is what separates teams that benefit from agents from teams that get burned by them.

Security as Part of Quality

Security review is best understood as one dimension of overall code quality, not a separate concern bolted on at the end. Just as you would not ship code that fails its tests, you should not ship code that fails its security checks. Building security into the definition of done, so that a change is not complete until it has passed the security gates, makes it a normal part of the workflow rather than an afterthought. When security is treated as integral to quality, agents become a net positive for security posture, because the automated gates apply consistently to every change in a way that manual processes often do not.