Two pieces of research published in August 2026 give secure development programmes something they have mostly been operating without: measurements.

Veracode assessed AI-generated code against security criteria and reported a 56% pass rate — meaning 44% contained an OWASP Top 10 flaw. The result varied sharply by language: Python passed 63% of the time, Java only 30%.

1Password studied more than 6,000 AI-generated patches and found that only 26% fully corrected the vulnerability without unintended effects. More than half failed to block the complete exploit pathway — producing a patch that addressed the reported symptom while leaving the underlying vulnerability reachable by an adjacent route.

Neither study is an argument for banning AI-assisted development. Both are arguments that the control model most organisations have quietly adopted — treat AI-generated code as equivalent to code written by a competent engineer — is not supported by the evidence, and that this gap now sits inside several compliance frameworks that require it to be closed.

Reading the numbers correctly

Some care is needed before these figures go into a board deck.

56% is not “AI writes insecure code half the time” in any simple sense. Human-written code also carries OWASP Top 10 flaws at meaningful rates, and the comparison depends heavily on the task set, the assessment methodology, and developer seniority. The honest reading is narrower and more useful: AI-generated code cannot be assumed secure, and the assumption of security is precisely what a code review process implicitly grants when a reviewer approves a change quickly because it looks conventional.

The language variance is the more actionable finding. Python at 63% versus Java at 30% is a very large spread, and it points at training data distribution and idiom complexity rather than at anything about the languages’ inherent security properties. The practical consequence is that your AI code risk is not uniform across your estate. A Java-heavy backend carries materially different exposure from a Python-heavy data platform, and a single organisation-wide policy will be simultaneously too strict for one and too loose for the other.

The patch finding is the more serious of the two. A 26% full-correction rate matters more than the generation figure because of where in the process it sits. Insecure generated code enters a pipeline that has review, testing and scanning ahead of it. A patch enters at the point where the organisation is closing a finding. It gets applied, the scanner stops reporting, the ticket closes, and the risk register records the issue as remediated.

That is the dangerous shape: not an undetected vulnerability, but a vulnerability recorded as fixed. Half of the patches studied left the exploit path open while removing the signal that would have prompted anyone to look again.

Where this touches compliance frameworks

This is not solely an engineering quality question. Several frameworks contain requirements that these findings speak to directly.

PCI DSS v4.0 Requirement 6 obliges entities to develop software securely, to train developers in secure coding, and to review custom code prior to release to identify vulnerabilities. Requirement 6.2.3 specifically requires review of bespoke and custom software by someone other than the author, with a documented process. An organisation where a substantial share of code originates from an AI assistant needs to be able to say what its review process does about that — and “the same as always” is a defensible answer only if the review process was already catching OWASP Top 10 categories reliably, which the same body of research suggests it often is not.

SOC 2 change management and system development criteria require that changes are authorised, designed, developed, tested and approved. An auditor asking how AI-generated changes are governed is asking a reasonable question, and the answer needs to be a control, not a philosophy.

ISO/IEC 27001 Annex A 8.28 (secure coding) and 8.25 (secure development lifecycle) carry the same implication. ISO/IEC 42001, where an organisation has adopted it, requires impact assessment of AI systems used within the organisation — and a coding assistant with commit access to production repositories is squarely such a system.

The EU Cyber Resilience Act, whose main obligations phase in through 2027, imposes vulnerability handling and secure development duties on products with digital elements. A manufacturer whose remediation process produces patches that fail to close the exploit path 74% of the time has a vulnerability handling problem in the regulatory sense, not merely an engineering one.

NIS2 Article 21(2)(e) requires security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.

The common thread across all of these is that they require an organisation to have a defined and effective process — and effectiveness is measurable. Once published research establishes a measurable failure rate for a technique your process depends on, “we were not aware” stops being available.

The verification asymmetry

The reason AI-assisted patching produces this failure mode is structural, and understanding it points at the fix.

A vulnerability report describes a symptom: this input reaches this sink; this endpoint returns this data. A model given that report will reliably produce a change that stops the described symptom. Doing so is a well-specified task with clear success criteria.

A correct fix requires reasoning about the class of the vulnerability: what other inputs reach the same sink, what other endpoints share the flawed authorisation logic, whether the underlying invariant is now enforced or merely one violation of it blocked. That requires understanding the system’s security model, which is generally not present in the context window and often not written down anywhere.

The result is a systematic bias toward narrow fixes that satisfy the stated test and leave the class intact. An input validation flaw gets a validator on the reported parameter. An authorisation bypass gets a check on the reported endpoint. In both cases the scanner goes quiet and the class survives.

Human engineers make this mistake too. The difference is volume and confidence: the AI-generated patch arrives quickly, reads plausibly, and carries none of the hedging that would prompt a reviewer to dig further.

What to actually change

The goal is not to slow down AI-assisted development. It is to place verification where the failure rate concentrates.

Treat AI-generated code as untrusted input to your pipeline

  • State this explicitly in your secure development policy. That sentence is what an auditor is looking for, and it is what makes the downstream controls coherent.
  • Require human review by someone other than the prompter, with the reviewer aware that the change is AI-originated. Provenance metadata on commits makes this possible; several tooling vendors now emit it.
  • Do not permit AI-generated changes to bypass review on the grounds that they are small. Size is uncorrelated with security impact.

Concentrate scrutiny where the data says to

  • Weight review effort by language. If your estate is Java-heavy, the Veracode data says that is where your exposure concentrates. Adjust review depth and scanning aggressiveness accordingly rather than applying one uniform policy.
  • Apply the highest scrutiny to code touching authentication, authorisation, cryptography, deserialisation, and query construction — the categories where a plausible-looking implementation is most likely to be subtly wrong.

Change how you close vulnerability findings

This is the highest-value change available and most organisations are not doing it.

  • Verify the fix, not the symptom. A finding should be closed on evidence that the exploit path is blocked, not on evidence that the scanner no longer alerts.
  • Require a regression test that encodes the exploit for every security fix. If the test passes before the patch, the test is wrong. If it fails before and passes after, you have evidence.
  • For any AI-generated patch, require the reviewer to answer in writing: what class of vulnerability is this, and what else in the codebase is in that class? That single question converts a narrow fix into a class fix.
  • Re-test closed findings periodically. If 74% of AI-generated patches are incomplete, your historical remediation record contains incomplete fixes recorded as complete. Sampling old closures is uncomfortable and worth doing.

Instrument it

  • Track security defect rates by code origin — AI-assisted versus human-authored. Without this measurement you are managing on published research about someone else’s codebase rather than your own.
  • Track reopen rates on security findings. A rising reopen rate is the leading indicator of the incomplete-patch problem.
  • Report both to whoever owns your SOC 2 or ISO 27001 evidence. These are control effectiveness metrics, and they are the kind that satisfies an auditor asking how you know your process works.

Govern the assistants themselves

The Black Hat 2026 and DEF CON 34 disclosures this month found remote code execution, credential theft, prompt injection and supply chain compromise paths in coding agents from multiple major vendors. A coding assistant is not only a code source; it is a privileged process with repository access.

  • Run coding agents in isolated execution environments.
  • Limit repository permissions to what the task requires. Broad organisation-wide read access on a coding assistant is a credential-theft blast radius.
  • Treat repository content, issue text and documentation the agent reads as untrusted input capable of carrying instructions.
  • Log agent actions attributable to a named human owner.

We covered the wider agentic governance control set in our analysis of the Taiwan autonomous agent campaign.

The exploit-development side

One finding from the same period frames the urgency. Researchers who developed the ZOOMSDAY exploit chain — three vulnerabilities enabling zero-click remote code execution across Windows, macOS, iOS and Android via Zoom’s annotation feature — reported using public AI models to develop the exploit in under 24 hours.

Set that against a 26% patch success rate and the asymmetry is stark. AI is compressing exploit development timelines faster than it is improving remediation quality. That is not an argument to stop using AI in the SDLC; it is an argument that the remediation side needs the verification discipline that the offensive side does not.

The bottom line

Most organisations adopted AI-assisted development without changing a single control, on an unstated assumption that the output was equivalent in quality to what it replaced. That assumption was reasonable in 2024 when there was no data. There is data now, it is public, and it is specific: 56% security pass rate on generation, 26% full-correction rate on patches.

The compliance exposure is not that the numbers are bad. It is that the numbers are published. A secure development programme that has not been adjusted in light of them is running a known-defective process, and the frameworks that govern it — PCI DSS 6, SOC 2, ISO 27001, the CRA, NIS2 — all require processes that are effective, not merely present.

The single most valuable change is also the cheapest: stop closing security findings on the absence of a scanner alert, and start closing them on a test that encodes the exploit. That one control catches the majority of the failure mode these studies identified, and it produces exactly the evidence an auditor will ask for.

This article is provided for informational purposes only and does not constitute legal advice. Organisations should consult qualified counsel and appropriate technical advisors regarding their specific secure development and vulnerability management obligations.