AI vulnerability discovery is outpacing secure code generation

At a glance

What this is: Cogent argues that AI is scaling vulnerability discovery and exploit generation faster than it is improving secure software generation, creating a widening assurance gap.

Why it matters: For IAM, NHI, and AI security teams, the lesson is that faster code generation does not remove the need for verifiable controls, because security properties still fail at specification, review, and assurance time.

By the numbers:

• Vibe Security Radar listed 78 AI-linked CVEs across tools including GitHub Copilot, Claude Code, Cursor, and Devin as of March 2026.
• March 2026 alone added 34 CVEs spanning authorization bypasses, XSS, path traversal, and CORS misconfigurations.

Context

AI code generation has changed the speed at which software can be produced, but it has not solved the harder problem of proving that the resulting code is secure. The central governance gap is assurance: organisations can generate plausible code quickly, but they still struggle to verify that it preserves intended security properties.

This matters for identity-heavy systems because generated code increasingly touches authentication, authorisation, and secret-handling paths where small flaws create large blast radii. When the topic is AI-assisted development, the control question is no longer only whether code can be written faster, but whether the resulting access logic, token handling, and trust boundaries can be independently checked.

The article’s position is atypical only in emphasis, not in direction: most engineering teams still optimise for delivery velocity before they have strong verification discipline in place.

Key questions

Q: What breaks when teams assume AI-generated code is secure by default?

A: When teams assume AI-generated code is secure by default, they miss common failure modes such as embedded secrets, unsafe dependencies, missing validation, and maintainability problems that later become vulnerabilities. Review processes also become weaker because hidden instructions can survive traditional code review if they live in trusted configuration files rather than executable code.

Q: Why does faster code generation not eliminate security risk?

A: Because security risk is created by unproven behaviour, not just by code volume. AI can accelerate development, but it does not automatically prove that the code preserves intended invariants or resists abuse. In practice, the weakest point is assurance, so teams need evidence that the code does what the design intended, not just that it compiles or passes superficial tests.

Q: What signs show AI-assisted development is outpacing security review?

A: The clearest signs are rising pull request size, fewer but denser merges, more findings per change, and an increase in privilege or secret-related defects. If review queues are growing while the number of touches per merge also increases, the process is losing inspection quality. That usually means the team is measuring throughput, not control effectiveness.

Q: How should security teams govern AI-generated code in production environments?

A: Security teams should treat AI-generated code as normal production code with extra provenance risk. Require architectural review, test coverage, static analysis, and approval before merge. Then bind the agent and the build pipeline to least privilege, short-lived credentials, and complete audit logging so implementation speed does not outrun control.

Technical breakdown

Why AI-assisted code generation changes the attack surface

AI-assisted coding tools can accelerate both development and exploit discovery because they let operators iterate quickly over candidate code paths, triage outputs, and refine suspicious findings at scale. That does not require the model to be perfect. It only requires it to lower the cost of finding the next bug and turning it into a working exploit. In practice, this means offensive capability improves as a workflow, not as a single breakthrough. The security implication is that any environment that treats code generation as a net reduction in risk is misreading the mechanism. Speed helps both sides, but offensive workflows currently appear to benefit first.

Practical implication: treat AI-assisted development as an attacker productivity multiplier until verification proves otherwise.

Why secure code generation is not the same as secure code assurance

The article draws a hard distinction between generating code and proving that code is safe. A patch or generated snippet can look plausible while still introducing regressions, new attack surface, or broken invariants. That is why the assurance problem cannot be solved by better generation alone. Testing, review, and fuzzing still matter, but they are not equivalent to formal verification. For identity systems, that matters most where generated code affects authentication, session handling, access decisions, or secret lifecycle logic. Those paths need evidence, not just plausibility, because a small defect can invalidate the trust model for the whole application.

Practical implication: move high-risk generated code through stronger verification than ordinary peer review alone.

How formal specifications reduce the security gap

The article’s strongest technical argument is that secure code needs checkable intent, not just better prompts or larger training sets. Formal specifications make the expected behaviour explicit, certificates provide evidence that the output satisfies that behaviour, and proof systems check the evidence independently. That architecture changes the security model from trust the generator to trust the verifier. It is especially relevant for parsers, protocol handlers, authorisation logic, and critical remediation code because those components are both narrow enough to specify and important enough to justify the extra discipline. In other words, assurance moves from a human judgement problem to a machine-checkable control.

Practical implication: reserve formal or semi-formal verification for security-critical code paths where correctness failures are unacceptable.

NHI Mgmt Group analysis

Assurance debt is now the primary software-security constraint. The article is not really about coding speed. It is about the growing gap between how quickly code can be produced and how slowly teams can prove that it is safe. That gap becomes especially visible in code that touches identity, authentication, and authorisation, where one defective assumption can break the control plane for the whole application. Practitioners should treat assurance as a first-class governance issue, not a downstream testing activity.

AI changes the economics of both offense and defense, but not symmetrically. The article shows that AI is already lowering the cost of vulnerability discovery and exploit development in a repeatable workflow. Defensive gains are real, but they are being pulled into a harder verification problem: teams must now prove that fixes, generated code, and AI-assisted changes preserve security properties. That means the security bar shifts from more output to more evidence.

Intent formalization is the most durable answer to plausible-but-unsafe code. Better training data helps, but it does not remove the need to express what the code must do and then verify that it does it. This is the same governance problem identity teams face when policies exist in prose but not in enforceable controls. The practitioner takeaway is clear: make security properties checkable wherever the code is high impact.

AI-assisted development will force security teams to rethink where trust is established. The old model assumes review and testing can catch enough issues after code is written. That assumption is weakening when code volume and change velocity keep rising. The more resilient pattern is to establish trust at specification and verification time, especially for code that makes decisions about access, secrets, and trust boundaries.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Assurance debt will become a persistent governance issue for teams that adopt AI-assisted development without stronger verification. The immediate risk is not that AI writes every insecure line of code, but that it increases the amount of code flowing through systems that were already weak at proving correctness. Security leaders should assume the burden shifts from code production to code proof.

Vulnerability discovery is being automated faster than remediation confidence. According to the State of Secrets Sprawl 2026, Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025. That pattern signals a control problem in the development pipeline, not a tooling problem in isolation.

For practitioners

• Strengthen verification for identity-critical code Apply stricter review, fuzzing, and test coverage to authentication, authorisation, token, and secret-handling paths before merging AI-generated changes.
• Require checkable intent for high-risk components Express security requirements as explicit assertions or formal specifications for parsers, protocol handlers, and access-control logic that AI helps generate.
• Gate AI-assisted patches on regression-proof evidence Do not treat a patch as complete until it has evidence that it preserves the intended invariant and does not expand the attack surface.
• Separate productivity metrics from assurance metrics Track generated-code throughput separately from defect escape rate, security test failures, and post-merge remediation effort so velocity does not mask risk.

Key takeaways

• AI is making vulnerability discovery and exploit development cheaper at the same time that secure code generation remains difficult to prove, which widens the assurance gap.
• The most exposed paths are security-critical components such as authentication, authorisation, protocol handling, and secret management, where small defects have outsized impact.
• Organisations need stronger verification, explicit specifications, and evidence-based approval for high-risk AI-assisted code if they want productivity gains without expanding attack surface.

Key terms

• Assurance gap: The mismatch between technical discovery and governance acceptance. A team can generate many findings and still fail to produce evidence that auditors, risk owners, or executives consider defensible, usually because validation, attribution, or review controls are incomplete.
• Formal Specification: A precise description of what software must do and must not do. For security-critical code, formal specifications make requirements checkable rather than implied, which is essential when AI is generating code that humans cannot reliably inspect line by line.
• Proof Checking: Independent verification that a claimed property or certificate is valid. In secure software workflows, proof checking shifts trust away from the generator and toward a system that can validate whether the code satisfies the intended rules.
• Security-Critical Path: A code path where failure creates disproportionate security impact, such as authentication, authorisation, token handling, or secret processing. These paths need stronger assurance because small defects can undermine broader trust in the application.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, and secrets management for teams that need stronger control over identity-related code paths. It helps security and engineering practitioners align access decisions, lifecycle governance, and assurance across modern delivery pipelines.