AI vulnerability discovery is outpacing secure code generation

At a glance

What this is: This is Cogent's analysis of how AI is lowering the cost of finding and weaponising software flaws faster than it is improving secure code generation.

Why it matters: It matters because security and identity teams rely on software assurance, and faster vulnerability discovery increases the pressure on access controls, auth logic, secrets handling, and remediation workflows.

By the numbers:

• As of March 2026, it lists 78 AI-linked CVEs across tools including GitHub Copilot, Claude Code, Cursor, and Devin, with 43 rated Critical or High.
• March 2026 alone added 34 CVEs spanning authorization bypasses, XSS, path traversal, and CORS misconfigurations.

👉 Read Cogent's analysis of why AI vulnerability discovery is outpacing secure code generation

Context

AI vulnerability discovery is changing the economics of software risk faster than most assurance programmes can absorb. The primary issue is not whether models can produce code, but whether teams can prove that generated or modified code still preserves security properties, especially in authentication, authorisation, and secret-handling paths.

For IAM and NHI practitioners, that matters because insecure code often becomes insecure access. If AI-assisted development introduces bypasses, path traversal, or weak CORS handling, the downstream impact reaches identity controls, token validation, and API trust boundaries. The article's starting position is typical of where the market is heading: offensive capability is scaling before defensive assurance has caught up.

Key questions

Q: What breaks when AI-generated code reaches authentication and authorisation logic without stronger verification?

A: The control most likely to fail is the trust boundary, not just the code syntax. Small errors in request handling, token validation, or permission checks can create bypasses that are hard to spot in review but easy to exploit. That is why identity-critical code needs testing, fuzzing, and evidence-based assurance, not just developer confidence.

Q: Why do AI-assisted coding tools complicate security assurance for enterprise software?

A: They increase code output faster than teams can prove the output is safe. Security assurance is slower because it depends on review, testing, and validation of behaviour, especially where access and trust are encoded in the application. The gap widens when organisations treat generation speed as the same thing as control maturity.

Q: How can security teams tell whether AI-generated code is actually safe?

A: They should look for security regression evidence, not just test pass rates. A codebase is safer only when the agent’s output survives threat-informed checks, review of privileged paths, and validation against the vulnerability classes most likely to recur in that repository.

Q: Who is accountable when AI-assisted development introduces a privilege bypass or access flaw?

A: Accountability stays with the organisation that accepted the change, even if an AI tool helped produce it. Teams need defined ownership for secure coding standards, verification gates, and release approval. The risk is governance failure when no one is responsible for proving that identity and access controls still work after the code changes.

Technical breakdown

Why AI-assisted vulnerability discovery scales faster than defence

The article describes a workflow where a model is pointed at a codebase, varied across inspection targets, and used to triage likely issues repeatedly. That is not autonomous magic, it is industrialised search. Once the cost of inspecting code paths and generating exploit hypotheses falls, the attacker's marginal effort drops sharply. Defence does not get the same benefit automatically because finding a flaw is easier than proving its absence across versions, environments, and dependencies.

Practical implication: treat AI-assisted recon and exploit discovery as a scale problem, not a novelty problem.

Why secure code generation is not the same as assurance

The article makes a clear distinction between code that looks correct and code that is demonstrably safe. Remediation is a verification problem because a patch can introduce regressions, widen an attack surface, or violate a critical invariant. That is especially true for access control logic, where a small mistake in condition handling or request validation can become a privilege escalation path. The key gap is that generation tools can create plausible code faster than review, testing, and fuzzing can prove it is secure.

Practical implication: require verification artefacts for high-risk changes, especially in authZ and token-processing code.

What AI-linked CVEs reveal about the current failure mode

The article cites 78 AI-linked CVEs and 34 more in a single month, spanning authorization bypasses, XSS, path traversal, and CORS misconfigurations. Those categories matter because they sit at control boundaries, not just code quality boundaries. When AI-assisted development keeps producing such flaws, the bottleneck shifts from code creation to control assurance. In practice, teams are not just reviewing syntax. They are trying to preserve identity, session, and request-trust assumptions across generated changes.

Practical implication: prioritise code paths that govern identity, sessions, and trust boundaries for deeper review and testing.

Threat narrative

Attacker objective: The attacker wants to turn low-cost vulnerability discovery into reliable exploit chains that bypass controls and expose or manipulate sensitive systems.

1. Entry begins when offensive AI is aimed at large codebases to identify weak paths, misconfigurations, and latent vulnerabilities faster than manual review can.
2. Escalation follows when those findings are turned into working exploit chains or abuse paths that bypass authentication, authorisation, or request validation controls.
3. Impact occurs when the weakness is operationalised into data exposure, service abuse, or privilege escalation before the defender can verify and ship a safe fix.

NHI Mgmt Group analysis

The real security variable is no longer code volume, it is assurance density. AI can produce more code, more bug hypotheses, and more exploit candidates, but that does not mean the security properties of the software improve at the same pace. The article correctly separates generation from verification, and that separation is where programmes are failing. For IAM-heavy systems, the concern is not just defective application logic, but any generated change that weakens authentication, authorisation, or token validation. Practitioners should measure whether assurance scales with change velocity, not whether developer throughput rises.

AI-assisted code creation is creating security debt faster than normal SDLC controls can retire it. The article's 78 CVEs and 34-month spike show a pattern that traditional review processes cannot simply absorb. This is a form of governance debt: more code paths are created with insufficient evidence that they preserve intended trust boundaries. In identity programmes, that debt surfaces when session handling, API access checks, or secrets use are introduced or modified without compensating verification. Teams should assume that AI-generated code increases the backlog of unproven control behaviour.

Trust-boundary drift: AI-generated changes often move faster than the controls meant to validate identity, privilege, and request context. That drift is especially dangerous in systems where a small authorisation mistake becomes a material incident. The article's emphasis on security-critical, spec-bounded components is the right lens because those are the places where failure is least tolerable. For identity and NHI governance, that means code review alone is not a sufficient control for access logic. Practitioners should insist on machine-checkable evidence for the code paths that protect privilege.

Offensive AI is forcing defenders to adopt proof-based assurance for the highest-risk code paths. The article's closing argument is not that AI should write more code, but that AI should help formalise intent and generate verifiable evidence. That changes the control model. In security-critical software, especially where identity decisions are encoded in application logic, the question becomes whether a system can prove its behaviour, not whether it merely appears correct. Practitioners should shift from hope-based trust in review to evidence-based confidence in constrained, high-impact paths.

What this signals

Trust-boundary drift is the operational risk to watch: AI can accelerate changes to code that governs identity, privilege, and session state faster than review processes can validate them. That means application security, IAM, and NHI governance need to converge on the same question, which is not how much code was produced, but whether the code still enforces the intended control boundary.

Programmes should expect more pressure to prove security properties in machine-checkable ways, especially for APIs, authorisation flows, and secret-handling logic. The practical signal is whether your testing and release gates can distinguish a merely working change from a change that still protects access.

Where code generation is already in use, teams should watch for an increase in defects that look like ordinary software bugs but actually weaken access control outcomes. That is the point where identity security becomes a software assurance problem, and where governance needs stronger evidence before release.

For practitioners

• Prioritise proof-backed review for identity-critical code paths Route authentication, authorisation, session handling, and token-processing changes through deeper verification than standard peer review. Use property checks, targeted fuzzing, and regression tests to confirm that security invariants still hold after AI-assisted edits.
• Create an assurance gate for AI-generated changes Require explicit evidence for any generated or heavily assisted code that touches trust boundaries. That evidence should show what was changed, what security property was preserved, and which tests or proofs validated the result before merge.
• Treat AI-linked CVEs as a control design signal Track defects by category, especially authorisation bypass, path traversal, XSS, and CORS misconfiguration, to identify where generation tools keep failing. Use that pattern to harden guardrails around the code paths most likely to fail again.
• Increase verification depth where AI speed is highest Do not let shorter build cycles compress the validation of code that affects access decisions or data exposure. Align test depth with the consequence of failure, not with the speed at which the code was produced.

Key takeaways

• AI is scaling vulnerability discovery and exploit generation faster than it is improving secure software by default.
• The main bottleneck is assurance, because code that looks correct still has to prove it preserves identity and access controls.
• Security teams should raise verification depth for auth, session, and trust-boundary code before AI-assisted change velocity outruns governance.

Key terms

• Security Assurance: Security assurance is the evidence that a system behaves as intended under defined conditions. In this article's context, it means proving that AI-generated or AI-assisted code still preserves identity, access, and trust properties after changes are made.
• Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.
• Proof-Based Assurance: Proof-based assurance is a model where software changes are supported by verifiable evidence, not just developer intent or review confidence. It matters most in security-critical code because the system must demonstrate that important properties still hold after modification.

What's in the full article

Cogent's full blog research covers the operational detail this post intentionally leaves for the source:

• The specific AI research examples cited for exploit discovery across major operating systems and browser codebases.
• The full explanation of why remediation is a verification problem, including the security invariants that can fail during patching.
• The discussion of formal specifications, certificates, and proof checking as a path to secure code generation.
• Cogent's examples of how AI-assisted hardening is being applied to open-source and browser code.

👉 Cogent's full blog research covers the proof-based assurance model and the code paths where it matters most.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance and secrets management in the context of identity risk. It helps practitioners connect identity controls to the broader security decisions that shape access, trust, and verification.