Notifications
Clear all
Topic starter
02/08/2026 12:21 pm
TL;DR: Agentic security workflows that rely on CVSS and scanner output can miss exploitable paths while over-prioritising non-actionable findings, according to Horizons.ai. Continuous verification and proof of exploit shift remediation toward attack paths that are real in the environment, not just severe on paper.
NHIMG editorial — based on content published by Horizons.ai: Beyond Triage, How Exploitability Data Transforms Agentic Security Workflows
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should security teams prioritise vulnerabilities when exploit timelines are shrinking?
A: Prioritisation should combine exploitability, reachability, internet exposure, identity proximity, and business criticality.
Q: Why do scanner scores often mislead remediation teams?
A: Scanner scores describe theoretical severity, not operational reality.
Q: What do security teams get wrong about vulnerability remediation automation?
A: They often automate ticket creation but not end-to-end closure.
Practitioner guidance
- Prioritise exploitable paths over score-only findings Rank remediation by proof of exploit, downstream reach, and business impact instead of CVSS alone.
- Build a Find-Fix-Verify loop for remediation Require retesting after each change so the ticket closes only when the same attack path fails against the remediated asset.
- Rotate and scope credentials when exploit chains expose access If exploitability testing shows credential harvesting or valid-account abuse, rotate exposed service account credentials, enforce MFA on administrative access, and reduce the reachable privilege set before resuming automation.
What's in the full article
Horizons.ai's full blog covers the operational detail this post intentionally leaves for the source:
- The specific NodeZero-driven exploitability workflow and how the agent consumes proof-of-exploit data
- Step-by-step examples of how business context is merged with technical findings for prioritisation
- The mini Find-Fix-Verify loop and how retesting updates tickets when a fix fails
- Compensating-control patterns such as honey tokens, SIEM rules, and segmentation when patching is not possible
👉 Read Horizons.ai's analysis of exploitability data in agentic security workflows →
Exploitability data for agentic workflows: what changes for security teams?
Explore further
02/08/2026 1:21 pm
Exploitability is the new prioritisation boundary: security teams are moving from score-based triage to proof-based remediation. CVSS, scanner output, and generic advisories still matter, but they do not tell you whether a path reaches credentials, privilege, or business systems. The discipline changes once teams accept that a severe but non-exploitable issue is not the same as a medium-severity path to domain admin. Practitioners should treat exploitability as the control variable, not the score.
A question worth separating out:
Q: How do organisations prove a control remediation is working?
A: They need repeated evidence over a meaningful period, not a single clean test. That means the control must operate under normal conditions, produce auditable artefacts, and address the original root cause. In practice, sustained performance matters more than a one-time validation exercise.
👉 Read our full editorial: Exploitability data is reshaping agentic security workflows
