Is AI-generated code secure? What the research says

The largest study to date is also the bluntest. Tihanyi et al. generated 331,000 C programs with nine leading LLMs and checked them with formal verification: at least 62% contained security vulnerabilities (Empirical Software Engineering, 2024). GPT-4o mini, Gemini, Code Llama, Falcon: the leaderboard order barely mattered, because every model landed in the same failure band and produced the same categories of flaws. A weakness that survives every architecture and every training budget is how these models write code.

Perry et al. tested the people instead of the code. In a study of 47 developers working with a Codex-era assistant, those writing with the AI produced significantly less secure code than the control group and rated their own output as more secure (ACM Conference on Computer and Communications Security, 2023).

If your control for AI risk is "a human reviews it", that is the finding your plan rests on.

The result was visible early. Pearce et al. assessed GitHub Copilot across 89 scenarios built around the MITRE CWE top 25, security-relevant code paths rather than a random sample of everyday code, and measured roughly 40% of completions as vulnerable, with C close to 50% (IEEE Symposium on Security and Privacy, 2022). A systematic review of 19 studies reached the same consensus in 2024: current models do not reliably produce secure code (Negri-Ribalta et al., Frontiers in Big Data, 2024).

Veracode tested more than 100 models and found AI-generated code introduced a security flaw in 45%[5] of tasks, with wide spread by language and Java the worst performer (Veracode, 2025). CodeRabbit compared 470 open-source pull requests and found AI-authored PRs carried 2.74 times more security issues than human-only ones (CodeRabbit, 2025). For autonomous agents, DryRun Security measured 26 of 30 pull requests, 87%[4], introducing at least one vulnerability (DryRun Security, March 2026). All three companies sell scanning or review products, so read the multipliers as vendor telemetry. The academic record is the anchor, and the vendor numbers point the same way.

The trend is stranger than the snapshot. Apiiro analyzed AI-generated code across Fortune 50 enterprise repositories and found syntax errors down 76% and logic bugs down more than 60%, while privilege escalation paths rose 322% and architectural design flaws rose 153% (Apiiro, 2025). The same vendor caveat applies. The direction matches the academic record.

The code is getting cleaner on the surface while getting worse underneath. The bugs that are disappearing are the ones a linter catches in milliseconds. The flaws that are multiplying live across service boundaries, pass every automated check, and surface months later in an incident report.

Iteration does not correct this. A controlled experiment presented at IEEE-ISTAS ran 400 code samples through 40 rounds of iterative generation and found that vulnerabilities persist and often increase through feedback loops with the model (Shukla et al., IEEE-ISTAS, 2025). Feature-focused prompts produced the most vulnerabilities, and prompts that pushed for efficiency skewed the flaws toward memory safety. Asking the model to go again is not a fix. Worth holding onto in a market where every tool is sold on speed.

Vulnerabilities get the attention because they are countable. For a regulated enterprise, the deeper exposure is a category none of these studies touch: policy violations. No benchmark measures this layer, so what follows rests on the incident record and on reasoning from the numbers above.

Every organization of real size runs on internal rules: an approved library list, a data classification policy, logging requirements written into SOC 2 controls, records of processing activities under GDPR. Feeding those documents into a model's context does not enforce them. A model that has read your architecture decision records is not a gate. Nothing verifies the output against the rules it was shown, and nothing blocks the merge when it breaks them.

So the model pulls in an unapproved dependency, and nothing objects. The build passes, the tests pass, the SAST report comes back clean. What broke is procurement policy, which NIS2 treats as part of supply-chain security rather than as an internal preference. Generated code that stores personal data outside your documented processing flows is not a CVE, it is a GDPR record-keeping failure. An endpoint shipped without the audit logging your control matrix requires can be functionally perfect and still fail the audit.

The cost arrives on a schedule. Findings accumulate as audit exceptions. Enough exceptions turn a clean report into a qualified one, a qualified report escalates every buyer's security questionnaire, and remediation eats quarters of engineering time. Repeat findings eventually cost the certificate, and the buyer's procurement team checks certificates before it looks at features.

Process failures carry real cost with zero vulnerabilities involved. In March 2026, a configuration change deployed outside change management cut Amazon.com orders by 99% across its North American marketplaces for about six hours: 6.3 million lost orders[15], as reported by Business Insider from internal Amazon figures (March 2026). Not reported as an AI failure, and that is the point: a control that exists on paper and is not enforced in the pipeline fails exactly this way, at any scale. For an EU financial entity, DORA's ICT change-management requirements make the same gap a regulatory finding. Tools for pieces of this layer exist, from license scanners to dependency allow-lists to policy-as-code. In most organizations they are fragmented across teams and never enforced as one gate in front of generated code.

The standard enterprise answer is human review of AI output. The research explains the strain. Authors using assistants overrate the security of their own code, so flawed work arrives at review carrying more confidence than it earned. The flaws themselves are moving to the architectural level, where a pull-request diff cannot show them: a privilege escalation path across two services does not fit in a diff. The reviewers are not the problem. The method has been outgrown.

The conclusion we draw at Taiga: enforcement has to move in front of the code, encoded as machine-readable checks. That is the case for an AI software factory. The hard part is the translation from written policy to executable check, and that is where the factory's slow phase goes: intake agents interview your stakeholders and read your policy documents, and every run produces the same nine artifacts[8], each reviewed by a person, before code exists. Assistants make developers faster. The governed layer checks what the speed produces.

That check does not have to be fast. It has to be complete. Taiga's factory takes hours, sometimes days, on purpose, and every run is measured against the same published bar of 22 checks[7]. The bar is the fixed baseline. Your own policies are encoded on top of it, so an unapproved dependency fails the build and names the rule it broke. If you want to know where your pipeline stands against that bar, the self-test is six questions and stays in your browser.

The research settled the question in the title years ago. The open question is what stands between the model and production, enforcing the rules your organization wrote.