Is AI-generated code secure?
Test what it does.

“AI code” does not have one security score.

A study can ask a model to complete a small function, ask a developer to solve a security task with an assistant, or analyze code already used in a project. Those are different situations. The result also depends on the language, prompt, model version, surrounding code, and how researchers decide that a vulnerability exists.

Static-analysis findings, working exploits, human review, and production incidents answer different questions. A benchmark percentage is a result for its task and method; it is not a general probability that an AI-written application is unsafe.

Security depends on the work around the code as well as the code itself.

A 2023 ACM study gave 47 participants five security-related programming tasks in Python, JavaScript, and C. The group using an assistant based on Codex-davinci-002 wrote less secure code on those tasks and was more likely to believe its code was secure. The study provides evidence about one early assistant and a small controlled setting; it cannot predict the result for every developer or today’s tools.

A separate USENIX Security study asked 58 students to implement one linked-list “shopping list” in C. In that specific task, the rate of critical security bugs in the AI-assisted group was no more than 10% higher than in the control group. The difference between these studies is a reason to inspect task design and language before repeating either result as a universal rule.

In a 2025 ACL benchmark, researchers tested 20 proprietary and open models on code completion, vulnerability detection and classification, and repair. They reported that models often identified vulnerable code, yet still generated insecure code and struggled with some vulnerability types and fixes. Security review, secure generation, and repair should therefore be evaluated as separate capabilities.

Two ACL 2026 studies move the question closer to real projects. SecureVibeBench ↗ tests multi-file changes across 105 C/C++ tasks from 41 OSS-Fuzz projects, with both static and dynamic checks. The best-performing agent setup produced a solution that was both correct and secure for 23.8% of that benchmark’s tasks. That is a result for targeted C/C++ security scenarios, not a failure rate for coding tools in general.

RealSec-bench ↗ uses 105 expert-validated cases from high-risk Java repositories. In its experiments, retrieval improved functional correctness but did little for security; broad security instructions could also cause compilation failures without reliably preventing vulnerabilities. A stronger prompt can help specify intent, but it cannot replace testing the resulting security property.

For another view of the workflow around code changes, see the review checklist before merging ↗ and the evidence on code maintainability ↗.

Start with the rule the code must protect.

1. Name the trust boundary. Identify who can supply each input, which data is private, and which actions or records require authorization.
2. Follow inputs to sensitive operations. Inspect how user-controlled values reach SQL, HTML, shell commands, file paths, network requests, or deserialization.
3. Check access decisions and secrets. Verify authorization on the server, narrow permissions, safe handling of credentials, and what appears in logs or errors.
4. Test the failure paths. Add cases for empty, malformed, oversized, unauthorized, and adversarial input. Check that failures do not expose data or leave partial changes.
5. Use multiple forms of evidence. Combine review with relevant tests, static analysis, dependency checks, and dynamic testing where the risk warrants it. Investigate findings; a clean scan does not prove that the design is secure.
6. Keep a security regression test. When a flaw is fixed, preserve a test that would fail if the same boundary were crossed again.

This follows the wider secure-development approach in NIST’s Secure Software Development Framework ↗. The framework is not an AI-code checklist; it is a useful lifecycle baseline to apply to software whether a person, a model, or both authored the change.

An agent that can act introduces a second security question.

Generated code can contain a vulnerability. An AI coding tool can also create risk through the files it reads, the commands it runs, or the services it can reach. Review those as separate boundaries: code security asks what the resulting software allows; tool security asks what the assistant can do while working.

Keep permissions narrow, inspect changes before they reach sensitive systems, and treat repository files or retrieved content as data rather than trusted instructions. Continue with the coding-agent workspace security guide ↗, permissions at the tool boundary ↗, and prompt injection and untrusted input ↗.

For Symploka’s software-engineering product, read the Grablex Code overview ↗.