What AI-prioritized vulnerability triage actually means, mechanically, versus a raw severity score

A CVSS score is a description of a vulnerability in isolation — how bad it could be, in principle, on some unspecified system, with some unspecified set of mitigations already in place or absent. It's genuinely useful as a starting point and genuinely useless as a work queue, because a 9.8 on an asset that's air-gapped, fully patched on every other layer, and not internet-facing is not the same problem as a 7.1 on a domain controller with an exposed management port. Triage is the process of turning the first number into the second judgment, and it's worth being precise about what that process actually consists of mechanically, because 'AI-prioritized' is currently doing a lot of unexamined work in vendor marketing.

What a severity score doesn't know about your environment

• Whether the vulnerable service is actually exposed to a network path an attacker could reach, versus theoretically reachable in a topology that doesn't exist at this client
• Whether a working exploit is circulating versus the vulnerability being theoretical or requiring conditions unlikely to occur
• What else runs on that asset — a vulnerable library in a dev sandbox is not the same finding as the same library on a machine that touches student records
• Whether a compensating control already narrows the blast radius, like network segmentation or an application-level restriction that makes the underlying flaw unreachable in practice

What triage mechanically has to combine

Real prioritization is a merge of the static severity score with asset-specific context that only exists inside the client's own environment record — what the asset is, what's already been patched around it, what's actually reachable from where, and what similar findings have historically turned out to matter versus not at this client. That merge is exactly the kind of task an AI agent is well suited to draft, because it's pattern synthesis across a body of context a human would otherwise have to reassemble by hand from several places — asset inventory, patch history, network topology notes, prior ticket outcomes. The agent's output is a proposed priority order with the reasoning attached, not a silent reshuffling of a list.

A severity score answers 'how bad could this be.' Triage has to answer 'how bad is this, here, this week' — and the second question needs information the first one was never given.

The part that has to stay honest is what the AI layer is actually contributing versus what it's relabeling. A triage draft that just re-sorts CVSS scores with a confident-sounding paragraph attached isn't triage, it's a severity score with a narrator. The design direction we're building toward ties the drafted priority explicitly back to the specific evidence that produced it — this finding moved up because it's on an internet-facing asset with no compensating control, this one moved down because the vulnerable path is blocked by an existing firewall rule — so a technician reviewing the draft can check the reasoning against the actual environment instead of taking the ranking on faith. Where that stands today: it's part of the security module's roadmap direction, not a claim we're making about a shipped scoring engine, and the honest test for any vendor claiming AI-prioritized triage is the same one we'd invite for ourselves — ask to see the reasoning attached to one specific finding, not the aggregate claim that priorities are 'smarter.'