TL;DR: When AI models can surface vulnerabilities at scale, raw finding counts stop distinguishing noise from exploitable risk, according to Xbow's whitepaper. Security teams need metrics that reflect attackability, remediation progress, and operational priority, not just scan coverage or critical issue totals.
At a glance
What this is: Xbow's whitepaper argues that AI-assisted vulnerability discovery makes traditional AppSec counts less useful than metrics tied to exploitable risk and remediation progress.
Why it matters: For IAM, NHI, and broader security teams, this matters because metric design now affects prioritisation, control effectiveness, and how quickly high-risk exposure is reduced.
Context
Application security metrics are only useful when they reflect decision-making reality. In an environment where AI can surface large numbers of findings, raw counts quickly lose signal value because they do not distinguish between theoretical weaknesses and issues an attacker is likely to exploit. That creates a governance problem as much as a technical one, because teams can appear busy while still leaving the most dangerous paths open.
The identity angle is indirect but real: exploitability often depends on how a vulnerability intersects with credentials, privileges, APIs, and service-to-service access. In practice, AppSec metrics need to tell IAM, NHI, and application owners where risk concentrates, not just how many findings exist. That makes prioritisation, not volume, the more defensible programme measure.
The whitepaper's starting position is increasingly typical rather than exceptional, because many security teams still over-rely on volume-based reporting even as attack automation improves.
Key questions
Q: How should security teams manage AppSec when AI is writing code faster than humans can review it?
A: Teams should shift from discovery-centric reporting to remediation-centric governance. That means measuring mean time to remediation, prioritising exploitable findings, and embedding automated validation into the SDLC so security can keep pace with development without lowering trust in the results.
Q: Why do critical finding counts become less useful in an AI-assisted AppSec programme?
A: Because counts measure output, not attacker relevance. AI can inflate the number of reported weaknesses far faster than teams can validate them, so raw totals quickly blur together low-value noise and genuinely dangerous exposure. A useful metric has to show whether the organisation is reducing exploitable paths, not merely discovering more of them.
Q: What are the signs that AppSec metrics are failing to reflect real exposure?
A: Common signs include rising finding counts with no clear reduction in high-risk exposures, repeated issues in the same access paths, and remediation reports that celebrate closures without showing whether the attack surface shrank. When teams cannot explain which issues matter most to an attacker, the measurement model is too shallow.
Q: Should teams prioritise scan coverage or exploitable-risk metrics first?
A: Prioritise exploitable-risk metrics first if the goal is better security decisions. Scan coverage still matters operationally, but it does not tell you which findings threaten sensitive systems or identity boundaries. Coverage is a hygiene measure; exploitable risk is the metric that drives remediation order and resource allocation.
Technical breakdown
Why finding counts stop working as a security metric
Finding counts measure detection output, not attacker value. As AI-driven tooling improves vulnerability discovery, the number of issues reported can rise faster than teams can assess them, which makes raw totals increasingly noisy. The key technical problem is that not every vulnerability contributes equally to an exploitable attack path. A metric that treats all findings as interchangeable will overstate coverage and understate concentration of risk.
Practical implication: separate discovery volume from exploitability scoring so programme reporting tracks actual exposure, not just scan output.
What exploitable risk adds to AppSec prioritisation
Exploitable risk is a prioritisation lens that asks whether a weakness can be meaningfully turned into compromise in a real environment. That requires considering reachability, privilege context, exposure, chaining potential, and whether the issue sits on a path to sensitive systems or identity material. In other words, the question changes from 'how many issues did we find?' to 'which issues materially change the attacker's options?'
Practical implication: rank remediation by attackability and business impact, not by severity labels alone.
How remediation progress should be measured in an AI-assisted threat landscape
Remediation progress is stronger when it shows risk reduction over time, not just tickets closed. In an AI-assisted environment, teams need to know whether the backlog is shrinking at the high-risk end, whether exposure windows are shortening, and whether repeat findings are dropping in the same control areas. That shifts measurement toward control effectiveness, not activity completion.
Practical implication: build metrics that track closure of high-risk exposure paths, not only issue counts or scan coverage.
Threat narrative
Attacker objective: The attacker objective is to use faster vulnerability discovery to identify and exploit the highest-value paths before defenders can prioritise and close them.
- Entry begins when AI-assisted discovery rapidly identifies a large set of weaknesses, including those that are easiest to weaponise.
- Escalation occurs when attackers focus on the subset that leads to exposed systems, reachable services, or identity-sensitive pathways.
- Impact follows when the most exploitable issues are chained into meaningful compromise while teams are still triaging low-value findings.
Breaches seen in the wild
- Meta Muse agent hijack 2026: An undocumented Muse setting let local malware hijack Meta's personal AI agent, steal its authentication material and abuse user access.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Finding volume is no longer a defensible proxy for AppSec maturity. AI changes the economics of discovery, which means programs can generate more findings without improving actual security. The governance failure is treating output as outcome. Practitioners need a metric model that reflects exploitability, not just scanner throughput.
Exploitable-risk metrics are becoming the only metrics that boards and operators can trust. Once attackers can triage weaknesses at machine speed, the programme question shifts from coverage to consequence. That means application teams, IAM teams, and NHI owners all need a common language for attack paths, because a vulnerability is only as important as the access it can unlock.
AppSec metrics now need to incorporate identity and privilege context. In modern environments, many exploitable paths depend on tokens, service accounts, API access, or delegated permissions. That creates a direct bridge between AppSec reporting and identity governance. The practical conclusion is that security metrics must show where code risk becomes access risk.
Remediation reporting must move from activity completion to exposure reduction. Closing tickets is not the same as reducing risk if the remaining issues are the ones an attacker can actually use. This is why the meaningful signal is whether the organisation is shrinking the reachable attack surface and shortening the time high-risk issues remain open.
AppSec governance should treat AI as a measurement stress test, not just a detection boost. The same tooling that increases visibility also increases noise, so the programme has to prove it can distinguish signal from clutter. Teams that cannot separate exploitable issues from background findings will struggle to prioritise investment, justify controls, or demonstrate improvement.
What this signals
Exploitability will become the primary unit of AppSec governance. As AI raises the volume of discovered weaknesses, teams that still optimise for counts will drown in noise. The stronger programme is the one that can explain which findings are reachable, which ones are chained to privilege, and which ones are safe to defer.
AppSec reporting has to converge with identity governance. Vulnerabilities matter most when they intersect with tokens, service accounts, API permissions, or delegated access. That means application risk dashboards need to speak the same language as IAM and NHI governance if they are to drive real remediation.
Metric design now determines whether AI helps security or just accelerates alert fatigue. The same automation that improves discovery can overwhelm analysts unless the programme filters for attackability and time-to-remediate on the highest-risk issues. The operational goal is not more findings, but fewer exploitable paths.
For practitioners
- Adopt exploitable-risk scoring Replace raw critical-finding reporting with scoring that includes reachability, privilege impact, chaining potential, and exposure to sensitive assets.
- Measure remediation by exposure reduction Track whether the most attackable issues are closing faster, not just whether total backlog counts are falling.
- Add identity context to AppSec reporting Correlate application findings with service accounts, tokens, API permissions, and delegated access that could turn a flaw into compromise.
- Separate scan volume from security outcome Report coverage and finding volume as operational hygiene metrics, but use different measures for board-facing risk and control effectiveness.
- Prioritise repeatable attack paths Focus remediation on issue classes that recur in the same authentication, API, or privilege boundaries, because those patterns reveal systemic exposure.
Key takeaways
- AI-assisted discovery changes AppSec reporting because the volume of findings can rise without a matching increase in meaningful risk visibility.
- The most useful measures now connect vulnerability data to exploitability, identity context, and the paths an attacker could actually chain.
- Security teams should treat finding counts as a hygiene signal and use exposure reduction metrics to govern remediation priority.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.RA-05 — Threats, Vulnerabilities, and Impacts | The article is about measuring exploitable risk rather than raw findings. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | Identity and privilege context shape whether a finding becomes exploitable. | |
| Recommendation — Use ID.RA-05 to tie vulnerability reporting to attack relevance and business impact. Apply PR.AA-05 to ensure AppSec metrics account for privileges that make flaws actionable. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Attackability depends on whether weaknesses help an attacker gain or move through access. |
| Recommendation — Map high-risk findings to TA0006 and TA0008 to prioritise issues that enable access chaining. | ||
| OWASP ASVS | V8 — Authorization | Application flaws become more serious when authorization boundaries fail. |
| Recommendation — Use V8 to review whether authorization weaknesses create exploitable application paths. | ||
Key terms
- Exploitable risk: Exploitable risk is the subset of discovered issues that an attacker can realistically use to gain access, move laterally, or cause impact. It depends on reachability, privilege, exposure, and business context, not on severity labels alone.
- Attackability: The likelihood that a finding can be turned into a working attack in the real environment where the code or system actually runs. It combines exploitability, reachability, and exposure window, making it more useful than severity alone for prioritisation.
- Remediation Status: Remediation status describes whether a security tool has already quarantined, deleted, or otherwise contained the detected threat. It is a critical triage input because it tells analysts whether the event is still active, partially contained, or already neutralised on the affected host.
- Finding volume: Finding volume is the total number of issues surfaced by scanners, tests, or AI-assisted discovery tools. It is a useful operational signal, but by itself it says little about whether the programme is actually reducing the organisation's attack surface.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the NHI Foundation Level course if your programme needs a stronger link between identity governance and security outcomes.
Published by the NHIMG editorial team on August 11, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org