TL;DR: AI models can now generate working exploits in minutes for under a dollar, while benchmarked exploit success and detection rates show offensive capability is advancing faster than defensive review cycles, according to Checkmarx. The implication is that severity-based triage is no longer enough, and security teams need continuous attackability-led remediation and prevention at the point of code creation.
At a glance
What this is: This analysis argues that AI-speed exploit generation is making backlog-based vulnerability management obsolete and forcing a two-track model of remediation and prevention.
Why it matters: It matters to IAM and security practitioners because the same speed shift that accelerates code exploitation also increases risk around secrets, access paths, service accounts, and AI-assisted development workflows.
By the numbers:
- In 2018, it took an attacker an average of 840 days to exploit a disclosed vulnerability, but by 2026 that number had collapsed to 1.6 days.
- In independent testing, Claude Mythos achieved a 72.4% exploit success rate against known vulnerabilities, compared to 14.4% for Opus 4.6 and 4.4% for Sonnet 4.6.
- 81% of companies knowingly ship vulnerable code because backlogs are growing faster than teams can manually remediate.
👉 Read Checkmarx's analysis of AI-speed vulnerability remediation and AI supply chain risk
Context
AI-generated exploits are shrinking the time between vulnerability disclosure and weaponisation, which breaks the old assumption that teams have weeks or months to sort findings by severity. The primary problem is not just faster attackers. It is that the backlog itself now represents live attack surface, including exposed secrets, vulnerable code paths, and weak access controls embedded in modern development pipelines.
For IAM and NHI programmes, the identity angle is immediate. AI-assisted software delivery expands the number of machine identities, service integrations, API tokens, and automation paths that need governance. When vulnerabilities can be exploited quickly and cheaply, the question is no longer which findings are most important on paper, but which identities, credentials, and code paths are reachable in production right now. The article is an aggressive framing of a problem many teams already face, but at a scale that is becoming typical rather than exceptional.
Key questions
Q: What breaks when organisations still rely on severity-only vulnerability management?
A: They fix the wrong things first. Severity-only models miss whether an issue is reachable, already exploited, or likely to be automated by attackers, so limited effort gets spent on lower-value work while high-risk exposure persists. In fast-moving environments, that gap is enough to turn disclosure into compromise.
Q: Why do access sprawl and AI workflows create more identity risk?
A: Because they multiply the number of places where credentials, approvals, and delegated actions can occur without clear ownership. AI-assisted workflows can accelerate access requests and routing, but governance often remains designed for slower human processes. That mismatch creates gaps in review, revocation, and accountability.
Q: How do security teams know whether vulnerability assessment is actually working?
A: Teams should look for short triage cycles, high-confidence findings, and a clear link between scan results and remediation action. A working programme reduces uncertainty around what to fix first. If the same issues keep reappearing or the queue is dominated by false alarms, the tool is not helping governance.
Q: Should organisations treat AI coding assistants as part of the security boundary?
A: Yes. If an AI assistant can generate code, open pull requests, or influence deployment, it is operating inside the security boundary and must be governed accordingly. That means controlling its connectors, monitoring its outputs, and limiting the credentials it can access.
Technical breakdown
Why severity-based triage breaks under AI-speed exploit generation
Traditional vulnerability management assumes exploitability has friction. CVSS was useful when attackers needed skill, time, and manual effort to turn a flaw into a working exploit. Large language models reduce that friction by reasoning through code, finding attack paths, and producing payloads at machine speed. That means severity scores still help with ordering, but they no longer justify leaving a flaw unresolved. In practice, exploitable reachability matters more than the original label, because a low-severity issue in a reachable production path can now become an immediate entry point.
Practical implication: shift prioritisation from static severity to reachability and exploitability in the production environment.
What attackability scoring changes in application security
Attackability scoring tries to answer a different question from vulnerability scanning: not whether a flaw exists, but whether it can be reached and exploited in the real environment. This is especially important in codebases with authentication paths, privileged integrations, and secrets handling, where a single exposed route can convert a theoretical weakness into a live breach path. The model works best when paired with deterministic static analysis, runtime context, and confirmation of actual exposure, because generic AI output alone cannot confirm whether a vulnerability is active in production.
Practical implication: use attackability scoring to suppress noise and focus remediation on flaws with verified production reachability.
Why AI coding workflows create new identity and supply chain risk
AI coding assistants and autonomous development agents change the control plane of software creation. They can write code, open pull requests, trigger pipelines, and interact with tools through connectors such as MCP servers. That makes the AI supply chain part of the security boundary. If a malicious connector, compromised model, or insecure prompt injects flawed logic or credential exposure into the workflow, the result is not just bad code. It is identity and trust contamination across the development lifecycle, including tokens, service accounts, and automation permissions.
Practical implication: extend governance beyond code scanning to the identities, connectors, and credentials used by AI development systems.
Threat narrative
Attacker objective: The attacker’s objective is to convert dormant backlog items into fast, low-cost compromise paths that bypass human triage timelines.
- Entry occurs when attackers or AI-assisted tools identify a reachable weakness in code, often one that was previously triaged as low risk and left in the backlog.
- Escalation follows when the flaw is turned into a working exploit against a production path, such as authentication logic, secrets handling, or a privileged integration.
- Impact is realised when the exploited path exposes credentials, enables unauthorised access, or allows further compromise across connected systems.
NHI Mgmt Group analysis
AI-speed exploitation has turned vulnerability backlogs into exposure inventories. The old model treated unresolved findings as deferred work, but AI-generated exploit chains collapse the time between disclosure and abuse. That changes the governance question from backlog volume to exposure window. For identity teams, the same logic applies to service accounts, API keys, and automation tokens that remain valid long after the risk score was assigned. Practitioner conclusion: treat unresolved reachability as active access risk, not future maintenance.
Attackability is now the right concept for modern application governance. Severity alone cannot tell you whether a flaw is reachable, chainable, or practically exploitable in the environment that matters. This is especially true where code, identity, and cloud runtime intersect. The useful control question is whether the vulnerable path can be invoked through real authentication, privilege, or delegation flows. Practitioner conclusion: prioritise verified exploitability over nominal severity.
AI development pipelines create a new class of identity governance debt. Once coding assistants and autonomous agents can write, commit, and deploy code, their connectors and credentials become part of the trust boundary. That expands the attack surface beyond source code into machine identities, scoped tokens, and tool permissions. This is where NHI governance becomes relevant: if the AI system can act, it also needs lifecycle control. Practitioner conclusion: govern AI-enabled development like a privileged workload, not a simple productivity tool.
Prevention and remediation now have to run in parallel. Clearing the backlog without changing the intake path only resets the queue temporarily. The article’s core point is that release velocity and exploit velocity are now coupled, so security gates must move into the IDE, pull request, CI/CD, and AI supply chain layers. Framework alignment here is direct: NIST-CSF and NIST SP 800-53 both support continuous protection and control of access paths. Practitioner conclusion: build controls that stop vulnerable code and close existing exposure at the same time.
What this signals
AI-assisted delivery will force security teams to treat code creation as a governed runtime, not just a developer workflow. The practical change is that identity, secrets, and privilege controls must extend into the IDE, the PR, and the pipeline, because that is where insecure logic and credential exposure now enter the estate. For teams aligning to NIST Cybersecurity Framework 2.0, the message is simple: continuous protection must match continuous release velocity.
Exploitability is becoming the organising principle for remediation programmes. The old habit of deferring medium and low findings only works when attackers need time and skill. As AI lowers both, reachability, identity exposure, and production context become the signals that matter most. That means vulnerability operations, NHI governance, and application security are converging around the same operational question: what can be used right now?
AI supply chain governance is now inseparable from NHI governance. If an agent or connector can write code, it can also carry trust, credentials, and scoped permissions into the build path. Practitioners should map these assets using the OWASP NHI Top 10 and the NIST SP 800-53 Rev 5 Security and Privacy Controls to understand where machine identity becomes a control plane issue.
For practitioners
- Prioritise reachable vulnerabilities first Re-rank findings by exploitability in production, not only by CVSS score. Focus on authentication paths, secrets handling, and any code path with real privilege or external reach. This is where attackability scoring changes the queue.
- Automate closure of confirmed exposures Use agentic remediation for validated findings so teams are not waiting on manual tickets for every exploitable issue. Keep human review for high-risk changes, but remove routine fix generation from the backlog.
- Move security into the coding workflow Add real-time scanning at the IDE, pull request, and CI/CD stages so insecure code is intercepted before merge. Pair this with secrets detection and IaC scanning where developers and AI assistants create code.
- Govern AI development connectors as privileged assets Inventory MCP servers, coding assistants, AI agents, and the credentials they use. Apply least privilege, rotation, logging, and offboarding controls to those identities before they become hidden control paths.
Key takeaways
- AI-speed exploit generation has made backlog-driven vulnerability management a live exposure problem, not a prioritisation problem.
- Reachability and exploitability now matter more than severity labels when deciding what to fix first.
- Security programmes need both prevention at code creation and agentic remediation for existing findings to keep pace with attack velocity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Access control is central where code, tokens, and pipeline reachability create exploit paths. |
| NIST SP 800-53 Rev 5 | IA-5 | Authenticator management is relevant where AI workflows rely on tokens and secrets. |
| CIS Controls v8 | CIS-5 , Account Management | Account lifecycle control matters for the machine identities used in development pipelines. |
| MITRE ATT&CK | TA0006 , Credential Access; TA0001 , Initial Access | The article’s threat model centers on exploit-driven entry and credential exposure. |
Map reachable code flaws to credential access and initial access tactics to prioritise containment.
Key terms
- Attackability scoring: Attackability scoring measures whether a vulnerability can actually be reached and exploited in the environment where it runs. It combines code context, runtime exposure, and privilege paths to separate theoretical findings from issues that can become immediate attack surfaces.
- Agentic remediation: Agentic remediation is the automated generation and application of fixes for validated security findings, usually at pull request or pipeline stage. It reduces manual triage pressure by closing routine issues faster, while keeping human oversight for changes that alter business logic or introduce material risk.
- AI supply chain: The AI supply chain is the full chain of models, datasets, prompts, tools, and vendors that influence a deployed AI system. It matters because trust cannot be assigned to the application alone. Practitioners need provenance, ownership, and dependency visibility to govern risk.
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
What's in the full article
Checkmarx's full analysis covers the operational detail this post intentionally leaves for the source:
- Attackability scoring and fidelity funnel details for separating confirmed risk from raw findings
- Agentic remediation workflow examples showing how fixes can be applied at the pull request level
- AI supply chain coverage for MCP servers, AI agents, and model-integrated development tooling
- Benchmark data on detection, false positives, and remediation time that supports implementation planning
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners who need stronger control over access paths and automation. It is designed for security teams building identity governance into modern development and operational environments.
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
