Are AI Coding Agents Writing Secure Code? 2026 Benchmarks

Mostly not, unless you check. In an October 2026 benchmark of six frontier models, 73.6–91.3% of tasks produced working code, but only 16.4–25.1% produced code that was both working and secure. Treat agent output like code from a fast junior developer: scan it, test it, sandbox it, and have a person review every merge.

Updated 13 November 2026. Several primary studies on coding agent security came out in October 2026. They point the same way: agents ship features reliably and security unreliably, and the agent tooling itself is now an attack surface. This post summarises what the papers actually measured, from their arXiv abstracts and full text, and turns it into controls you can put in your pipeline this quarter. For which tools to evaluate, see our Cursor vs Claude Code vs Codex vs Devin comparison.

Do AI coding agents write secure code in 2026?

Not by default. Agents now produce code that passes functional tests most of the time, but security has not improved at the same rate. Two independent sources agree. A new academic benchmark puts the best model at 25.1% "functional and secure". Veracode's long-running test puts the average secure pass rate around 55%, roughly flat since 2023.

The two numbers differ because they measure different things. Veracode's Spring 2026 update gives single-function tasks across four CWE types and scans the output with SAST. It found "only 55% of generation tasks result in secure code", while syntax correctness rose from about 50% to 95% since 2023. LSCBench, below, uses real vulnerabilities in real projects, at function, file and whole-repository scope, and grades with hidden exploit tests. It is a harder and more realistic bar.

What did the October 2026 LSCBench study find?

"Last Secure Code Benchmark: Is the Code You Vibe Secure?" (arXiv 2610.14766, submitted 10 October 2026) tested six frontier models on 450 tasks. The tasks were built from 150 real vulnerabilities across seven languages and 24 CWE categories. The best model produced functional, secure code on 25.1% of tasks. Only 19 tasks were secured by all six models.

The prompts asked only for working features and never mentioned security, which is how most people use agents. Hidden functional and security tests graded the results.

Source: LSCBench full text, Table 10. Three findings matter for engineering leaders:

• Functional pass rate tells you nothing about security. Kimi-K3 had the highest functional pass rate (91.3%) and the lowest secure rate (16.4%).
• Models fail on different tasks. Pooled, at least one model secured 44.0% of tasks, against 25.1% for the best single model. A second model reviewing the first catches real issues, but nowhere near all of them.
• More agent turns did not buy security. The authors' phrase is "More Turns Do Not Buy Security." Letting the agent iterate longer is not a substitute for a security check.

Note that these are the models from August and September 2026. Newer releases such as Claude Fable 5.2 and Kimi K3.1 Pro were not tested. We cover those in our open-weight coding models guide and the November agent update.

Which vulnerabilities do AI coding agents get wrong most often?

Web-facing data flow bugs. In LSCBench, information exposure (CWE-200) was secured in only 0.7% of attempts, server-side request forgery (CWE-918) in 2.4%, and code injection (CWE-94) in 4.9%. Memory safety was the easiest category, at 34.3%. Veracode reports the same pattern: cross-site scripting at 15% and log injection at 13%, against 82% for SQL injection.

That pattern makes sense. SQL injection and memory bugs have well-known local fixes that models have seen millions of times. Information exposure, SSRF and injection depend on context the model does not see: what is sensitive, which hosts are internal, where input comes from. Add that context to the agent's instructions and to your review checklist. By language, LSCBench found C, Python and JavaScript secured most often (27–30% of tasks), and Java, Go and PHP least (10–18%). The authors attribute much of that gap to which weakness types each language's tasks contained.

Does telling the agent to "write secure code" help?

Somewhat, but nowhere near enough. In LSCBench, adding one sentence asking for secure code raised the functional-and-secure rate by 21.5 points for GPT-5.6 Sol (to 46.2%), 16.9 points for GLM-5.3 (to 38.2%) and 15.6 for Qwen3.8-Max (to 37.6%). DeepSeek-V4-Pro gained only 1.1 points. Most tasks stayed insecure even with the reminder.

So do it. Put security requirements in your AGENTS.md or CLAUDE.md, and be specific: "never build URLs from user input without an allow-list", "never log request bodies". It is free and it helps. But it is a nudge, not a control. The controls come later in this post.

Is the coding agent itself an attack surface?

Yes. October's research shows two concrete paths: weak harness settings, and poisoned instruction files. The biggest single risk is auto-approve. In one benchmark, turning it on raised attack success from 29.2% to 95.6%.

Harness settings

HarnessSecurity-Bench (arXiv 2610.07639) tested nine security mechanisms across six harnesses: Claude Code, Codex CLI, Gemini CLI, gptme, Qwen Code and GitHub Copilot. It ran 2,500 trials with the same baseline model. Key results:

• Enabling auto-approve raised utility but lifted attack success from 29.2% to 95.6%.
• Network isolation and read-only mode reduced attacks, at a substantial cost to utility.
• Command allow-listing reduced attacks with a small utility loss. Command deny-listing reduced attacks with a small utility gain.
• About half of the confirmed mechanism implementations are opt-in. In other words, off unless you turn them on.

Memory and instruction files

"Security Impact of Coding Agent's Memory Files" (arXiv 2610.38521) planted malicious CLAUDE.md-style files that framed removing defensive checks as best practice. They tested Claude Code and OpenCode on 36 tasks. Secure-completion rates moved between −8 and +6 points with no consistent pattern. That is a small sample, as the authors say. Disclosure differed: Claude Code named the file in about two-thirds of its final messages, while OpenCode mentioned it almost only in its reasoning trace, which developers rarely read. Practical rule: treat changes to AGENTS.md, CLAUDE.md, skills and MCP configs like changes to CI config. Require CODEOWNERS review.

Can AI coding agents find and fix vulnerabilities instead?

Better than they avoid them. CWE-bench (arXiv 2610.17020) gave agents 250 real repositories to audit and repair, without saying where the bug was or what kind it was. The best agent fixed 67% at the first attempt and 79% within four attempts. A deterministic verifier checked that each patch blocked the exploit and kept functionality.

This is the useful flip side. The same class of model that writes a vulnerable endpoint can often find and fix it when asked to look. So run a separate, security-focused review pass, by a different agent or a different prompt, plus SAST. That catches much of what the writing pass missed. GitHub has built this into its cloud agent, as the next section shows.

What controls make AI-generated code safe to merge?

Layer five controls: static analysis in the loop, secret scanning, a dependency policy, sandboxed execution, and human review that the agent cannot bypass. No single one is enough. Together they move agent output from "probably insecure" to "reviewed like any other change".

1. SAST in the agent loop, not only in CI. Run CodeQL or Semgrep as a tool the agent must call before it finishes, so it fixes findings itself. GitHub's Copilot cloud agent does this by default. Its risks and mitigations page says CodeQL checks security issues, new dependencies are checked against the GitHub Advisory Database, and Copilot code review gives "a second opinion" before the pull request is complete.
2. Secrets. Keep production credentials out of every environment an agent can reach. Turn on secret scanning with push protection. Rotate any key an agent has seen.
3. Dependency policy. Block new dependencies with High or Critical advisories or malware flags. Require approval for any new package. Agents add packages freely.
4. Sandboxing. Never use auto-approve with network access. Use command allow-lists, keep writes inside the working directory, and deny rather than prompt in unattended runs. Claude Code added blockWritesOutsideWorkingDirectories and denyInsteadOfPrompting settings in October and November 2026 (changelog).
5. Independent human review. The person who asked the agent should not be the one who approves it. GitHub enforces this for its cloud agent: the requester cannot approve the PR, and Actions workflows wait until a human with write access approves them.

Our AI agent security checklist covers these controls in more depth for agents you build into products. The governance side (model allow-lists, budgets, audit) is in governing AI coding agents in the enterprise. If you have inherited a codebase written mostly by an agent, start with taking a vibe-coded app to production.

How BeevR builds this

BeevR is a senior, founder-led software and AI studio in Hanoi. We build for regulated industries: we sign a BAA as a business associate when healthcare data is involved, and we can run models inside the client's own AWS account. Our rule for any AI component, including our open-source Kite agent framework, is that the model proposes and deterministic code plus a human decide. For teams adopting coding agents, we can run a fixed-scope security phase from $10K. We add SAST and dependency checks to the agent loop, lock down sandbox and secret handling, and set up a review gate the agent cannot bypass. You get a working demo every Friday and keep all code and IP.

Read more about our security approach and how we work as an AI agent development company, or book a 30-minute call and bring a recent agent-written pull request. We will review it with you.