AI-Generated Code Security: What to Check Before You Launch

AI-generated code is functional far more often than it is secure. Independent testing in 2026 found models chose insecure options in roughly 44 percent of security-relevant tasks, with cross-site scripting and log injection handled worst, and studies show models invent package names attackers can exploit. Before launch, treat AI-written code as untrusted: run static analysis, dependency and secret scanning in CI, have a human review authentication, authorization, input handling and data access, test access controls directly, verify every dependency exists and is the real package, and give your coding tools written security requirements so fewer problems are generated in the first place.

Three findings matter most for anyone shipping AI-written code.

Security has not improved as fast as capability. Veracode's 2026 GenAI Code Security Report (July 2026) tested 11 models on tasks where a secure and an insecure implementation were both possible. Code compiled almost every time, but the average security pass rate was 56 percent, barely changed from 55 percent in its first report. The best model reached 68 percent. Coding-specialized models were no more secure than general-purpose ones.

Some vulnerability classes are handled much worse than others. In the same report, SQL injection and cryptographic algorithm choice were handled correctly most of the time (83 and 87 percent), while cross-site scripting (15 percent) and log injection (12 percent) were usually wrong. Context-dependent issues, where safety depends on how data flows through the app, are the hardest for models.

Models invent dependencies. Spracklen and colleagues (USENIX Security 2025) analysed 576,000 code samples from 16 models and found 19.7 percent of suggested packages did not exist. Many hallucinated names recurred across runs, which makes them predictable targets for attackers who register them.

Models learn from public code, much of which is insecure or written for tutorials. They optimize for code that runs and satisfies the prompt, and prompts rarely state security requirements. They do not see your threat model, your other services or which inputs are attacker-controlled. And in agentic workflows they make many changes quickly, which increases the volume reviewers must check; DORA's 2025 research describes larger batches and review load as a key reason AI is still associated with lower delivery stability.

Run through this before any AI-assisted code reaches real users. It complements the OWASP Top 10 and ASVS, which remain the right references for web application security.

Manual checklists decay. Put the deterministic parts into your pipeline so they run on every pull request, whoever (or whatever) wrote it.

Coding agents follow repository instructions. Write your security rules down where they will be read (an AGENTS.md or CLAUDE.md file, Cursor rules or equivalent): which libraries to use for authentication, database access and HTML rendering, that secrets must never be hard-coded, that every route needs an authorization check, and that new dependencies require approval. Point agents to secure examples in your own code. Veracode's results suggest that giving models explicit security guidance improves outcomes, though not enough to skip the checks above.

For agent-specific risks (agents running commands, reading untrusted files or holding credentials), see securing AI coding agents. For using AI as a reviewer, see AI code review.

AI makes code cheap to produce and does not make it secure. Treat generated code as untrusted input to your codebase: scan it automatically, verify its dependencies, test access control directly and keep a knowledgeable human on the changes that matter. With those controls, AI-assisted development can be as safe as any other; without them, it ships the same well-known vulnerabilities faster.