Veracode published its 2026 GenAI Code Security Report on July 28, 2026. The security pass rate for AI-generated code landed at 56%, nearly identical to the 55% reported in 2025. This was measured across the same security-sensitive tasks in Java, JavaScript, C#, and Python, with more than 100 models evaluated since the program began. The needle did not move.
What happened
Veracode tested AI-generated code against real security benchmarks and found that cross-site scripting defenses pass only 15% of the time. Log injection protections pass 12% of the time. These are not edge cases. They are the same vulnerability classes that auditors flag in regulated environments year after year, and the code generation models—despite architectural advances, larger context windows, and better training data—are not getting better at avoiding them.
The report covers the same security-sensitive tasks across four languages and over a hundred models. The stability of the failure rate is the finding. A 56% pass rate means 44% of AI-generated code fails security review on first pass. In an environment where every change must be reviewed by a person before production, that number defines the review workload.
Why the model improving doesn't fix the problem
A language model optimizes for functional correctness and syntactic plausibility. It predicts tokens that make the code look right and run without errors. Security is not a token-prediction problem. It is a constraint-satisfaction problem that requires knowledge the model does not have: your specific threat model, your data classification scheme, your regulatory obligations, and your organization's risk tolerance.
When a model generates a logging statement, it does not know that your data protection regulation classifies certain fields as personal data requiring masking. When it generates a web endpoint, it does not know that your security policy requires output encoding for every user-supplied value. These constraints live outside the training data. They live in your policies, your static analysis rules, and your architecture decisions. A better model will produce code that compiles more reliably and looks more idiomatic. It will not magically learn your compliance requirements.
The Veracode data confirms this. Two years of model improvements, same security pass rate. The bottleneck is not model capability. It is the absence of security constraints in the generation process itself.
What this means for operations in Latin America
In Panama and across Latin America, regulated financial institutions operate under clear expectations: a person reviews and approves every change that reaches production. The supervisor and the auditor do not accept tool-generated code on trust. They ask for names, timestamps, and evidence.
Panama's Law 81 of 2019 requires security measures proportional to the risk to personal data. When AI-generated code processes that data—whether in a customer-facing application or an internal automation—the same review obligation applies. The regulator may not ask about your model version. They will ask who reviewed the change and what security checks that person performed.
This creates a concrete operational requirement. If your team uses Copilot, Claude, CodeWhisperer, or any other code generation tool, you need to produce evidence that a named individual reviewed the output before it merged. The evidence must be per-change, not per-project. A blanket policy statement is not enough. The auditor wants to see the trail for the specific commit that introduced the logging function or the web handler.
I use Claude Code daily to build automations. In my team, every change generated by a tool carries a record of provenance: which tool produced it, which model version, and which person reviewed it. This is not theoretical. It is how we work, and it is what we would show an auditor if asked.
What your company can do this week
-
Require provenance metadata in every commit that includes AI-generated code. Add a trailer to the commit message or pull request description that states the tool, model, and prompt scope. Make this machine-readable so your pipeline can enforce it. A commit without provenance metadata should fail the build for any repository subject to audit.
-
Run static analysis on the diff, not just the branch. Your SAST tool should produce a result specific to the change, and that result should be archived alongside the pull request. A passing scan on the main branch yesterday does not prove that today's AI-generated change is safe. The evidence must be per-change and retrievable.
-
Define security acceptance criteria in your pull request template. Add a checklist item that explicitly asks: does this change handle user input, write to logs, or touch personal data? If yes, the reviewer must verify output encoding, log masking, or data minimization before approval. This makes the review structured and demonstrable rather than a vague "looks good to me."
-
Document exceptions with a named authorizer. If a security finding from static analysis is waived, the waiver must state who authorized it, why, and for how long. AI-generated code will produce findings. The auditor's concern is not that findings exist—it is that they are resolved or explicitly accepted by someone with authority to accept the risk.
-
Treat the AI tool as part of your software supply chain. The model, the plugin, and the generation context are all inputs to your build process. Apply the same supply chain logic you use for open-source dependencies: know what you're consuming, pin versions, and have a process for evaluating changes when the upstream shifts. Your application security posture management should include AI-generated code as a distinct source category, not lump it in with hand-written code.
My take
I think the Veracode data tells us something uncomfortable that the industry does not want to say out loud: code generation models, as they are built today, are not security tools and will not become security tools through scaling alone. The pass rate is flat because the problem is structural. Security requires constraints, and these models do not reason about constraints. They reason about probabilities.
That does not mean we stop using them. I use Claude Code every day. It makes me faster at the parts of my work that are well-defined and repetitive. But I treat its output the same way I treat code from any external source: I review it, I run analysis on it, and I make sure there is a record showing that I did both. In an audited environment, that record is not optional. It is the difference between passing an audit and explaining to a regulator why you trusted a probability distribution with personal data.
Frequently asked questions
If the model improves, why doesn't code security improve with it?
Because the model optimizes for functional correctness and syntactic plausibility, not for security invariants. A better model produces code that looks more correct and compiles more reliably, but it still lacks the context of your specific security requirements, your threat model, and your regulatory obligations. Security failures like cross-site scripting and log injection persist because the model has no mechanism to enforce those constraints during generation.
What does a regulator or auditor actually want to see for AI-generated code?
They want to see that a named, identifiable person reviewed and approved the change before it reached production. This means a commit or pull request with a human reviewer's name attached, not just a tool signature. They also expect evidence that security checks were applied to that specific change and that any exceptions were documented with authorization. The principle is traceable accountability, not trust in the tool.
Does this apply to internal tools and automations, or only customer-facing applications?
It applies to any code that processes personal data or supports a regulated process, regardless of whether it faces customers or runs internally. If an internal automation handles employee data, financial records, or operational logs that could contain personal information, the same review and evidence requirements apply under data protection regulations like Panama's Law 81 of 2019.