Is AI-generated code secure? What the research says

Tihanyi et al. generated 331,000 compilable C programs with nine models and checked them using ESBMC formal verification. At least 62.07% were identified as vulnerable (Empirical Software Engineering, 2024). The authors found similar coding errors across the tested models. This is evidence about that C-program dataset, prompt and verification method; it does not establish a failure rate for every language, application or current model.

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).

Perry et al. measured authors using that assistant on selected tasks. The result raises questions about confidence and validation; it does not demonstrate that every human review process fails.

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 Apiiro figures describe that vendor’s repository sample and analysis. They do not establish a universal trend across AI-generated code. Errors spanning authorization or service boundaries may require contextual analysis beyond a selected linter or scanner. Inspect the relevant paths and the actual checks run rather than assuming that every automated tool will miss them.

Shukla et al. examined 400 code samples across 40 rounds of iterative generation using four prompting strategies (2025). Vulnerabilities increased under the tested conditions, challenging the assumption that another model iteration necessarily improves security. This is a bounded experiment, not proof that every revision makes code less safe. Verify the changed implementation instead of treating iteration itself as evidence of a fix.

The cited vulnerability rates do not tell you whether a particular implementation satisfies an organization’s policies or operating obligations. That requires a separate assessment of the applicable requirements and the actual system.

Company requirements can include approved dependencies, data handling, access and audit logging. Supplying those documents as model context does not itself enforce them. An implemented control may test a requirement or block a change; its scope, configuration and actual result matter. Inspect those controls rather than assuming that every organization has them or that none does.

For example, a dependency may fall outside an approved list, personal-data handling may differ from documented flows, or required audit logging may be absent. Selected tests and scanners can pass while these requirements remain unverified. Determine the applicable obligations and check the implementation and operating agreement against them.

Gaps can create review findings and remediation work. Their consequences depend on the system, obligations and evidence; a benchmark percentage cannot predict audit qualification, certification loss or engineering effort for an organization.

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. The lesson is to inspect how the actual change-management controls operate. License checks, dependency allow-lists and policy-as-code can address particular requirements when implemented and configured. No single gate is implied by a policy document or by a completed generation run.

Review still matters. Perry et al.’s participants showed greater confidence in less secure output under that study’s conditions. That makes validation worth examining; it does not show that competent reviewers are ineffective. Review important authorization and service boundaries alongside tests and security analysis, with enough system context to evaluate the change.

Taiga’s new-project setup uses eight documents, with an optional service blueprint. Imported codebases use code-derived reality documents. Later initiatives use their project context; they do not necessarily produce nine new documents. The deliverables and checks must be read in the scope of the workflow and agreement.[8]

Taiga publishes 22 readiness questions across governance, security, build and run. They organize evidence review; they are not one universal automated release gate. Check the source, scope and result of each relevant control for the particular system you are accepting.[7]

The cited studies document reasons to validate generated code carefully. The practical question is which checks, reviews and operating controls apply to your implementation, what evidence they produced and what remains untested.