What recent research actually says

A 2025 large-scale analysis of 7,703 files explicitly attributed to AI coding tools found 4,241 CWE instances across 77 vulnerability types, while also reporting that 87.9% of the analyzed files had no identifiable CWE-mapped vulnerability under that methodology. Another large 2025 study comparing human and AI-generated code reported different defect profiles and found more high-risk security vulnerabilities in AI-generated samples.

A 2026 cross-model study of routine automation scripts found recurring vulnerability classes across ChatGPT, Copilot, and Gemini outputs. These studies differ in sampling, languages, tasks, tools, and definitions, so the useful conclusion is about patterns and controls—not a universal 'X% of AI code is vulnerable' number.

Common vulnerability patterns remain familiar

AI code usually fails in ordinary software-security ways rather than inventing entirely new bug classes. Frequently discussed patterns include missing input validation, injection-prone queries, weak authorization, unsafe file/path handling, hardcoded secrets, insecure cryptography choices, excessive permissions, poor error handling, and missing resource limits.

Task definition strongly influences security quality

Security outcomes depend on what the developer asks for. A prompt such as 'build a login API' leaves many unspecified decisions: password storage, rate limiting, MFA, token lifetime, error behavior, account lockout, logging, and recovery. The model may fill gaps with generic defaults that do not match the organization’s threat model.

• Include authentication and authorization requirements explicitly.
• Specify data sensitivity and tenant boundaries.
• State secure library or framework patterns that must be used.
• Require tests for negative authorization and invalid input.
• Ask for dependency and security assumptions to be listed, then verify them.

Reduce risk with approved secure building blocks

Generated code is safer when the organization narrows the solution space. Shared authentication middleware, authorization libraries, schema validators, logging wrappers, secret-management clients, and infrastructure modules can keep AI output inside reviewed patterns.

Put generated code through independent security gates

The generator should not be the only reviewer of its own output. Use independent tools and humans with different failure modes.

1. Format, lint, and type-check generated code.
2. Run unit and integration tests including negative cases.
3. Use SAST and secret scanning.
4. Scan dependencies and container/base images.
5. Run API contract and authorization tests.
6. Use human review for security-sensitive code.
7. Deploy behind normal runtime controls and monitor behavior.

Apply deeper review where impact is highest

Not every generated line needs the same scrutiny. Prioritize authentication, authorization, cryptography, file parsing, deserialization, payment flows, admin functions, infrastructure-as-code, CI/CD, agent tools, and code that handles secrets or untrusted input.

A small helper function may be low risk; a generated authorization middleware or deployment policy can affect the entire application. Review depth should follow blast radius.

Keep provenance without creating false confidence

It can be useful to know which changes were AI-assisted so teams can measure outcomes and investigate defects. Some coding-agent platforms add signed commits or session links. Provenance helps auditing, but an 'AI-generated' label is not itself a security severity score.

• Track agent-authored pull requests and associated human owner.
• Preserve relevant prompts or session metadata where policy allows.
• Measure vulnerability and rework rates by task type.
• Use findings to improve templates and instructions rather than blaming individual developers.

Runtime API security still matters after code review

Static analysis cannot prove that business authorization behaves correctly in production. API discovery and runtime monitoring can reveal shadow endpoints, unusual object access, automation, resource abuse, and sequences that were not represented in test data.

This is especially valuable when AI accelerates release velocity: more code and endpoints can reach production faster than a central AppSec team can manually inspect them.

A practical policy for AI-generated code

• AI-generated code is treated as untrusted until reviewed.
• Security-critical changes require human approval.
• Approved secure libraries and templates should be preferred over generated security primitives.
• Generated dependencies must pass normal software-composition controls.
• Secrets and production data must not be included in prompts unless explicitly approved.
• CI security gates apply equally to human and AI-authored changes.
• Teams measure real defect outcomes and continuously improve controls.

Frequently asked questions

Sources and further reading

1. Security Vulnerabilities in AI-Generated Code: A Large-Scale Analysis — 2025 empirical analysis of public repositories
2. Human-Written vs. AI-Generated Code — large-scale comparison of defects, vulnerabilities, and complexity
3. Security Vulnerability Patterns in AI-Generated Code — 2026 cross-model comparative study
4. GitHub Docs — Responsible use of Copilot Agents — vendor guidance on insecure output and review
5. OWASP Developer Guide — API Top 10 — secure API development categories