Six threat classes, defined by what makes each one hard

Almost every incident a security operation handles falls into one of a small number of shapes. The six here were chosen because each is hard for a different reason, and because between them they cover the range of failures a platform can have.

Two are problems of speed. Ransomware is a race between initial access and encryption, and it is won or lost in the minutes in the middle: detection that arrives after the first files are encrypted has arrived too late to matter. Alert triage is the other, where the difficulty is not any single decision but eleven thousand of them a day, a number that neither hiring nor tuning brings down to something a team can work through.

Three are problems of legitimacy. Credential compromise produces a successful login from a valid account using an approved method against a system that user is entitled to reach: nothing in that sequence is anomalous on its own. Lateral movement has the same property one level up, where every individual hop is legitimate and only the sequence gives the attacker away. Insider threat is the extreme case, because procedurally the activity often is authorised, and the only thing separating it from ordinary work is intent expressed as a deviation from that person's own pattern.

One is a problem of ranking. Vulnerability prioritisation is not judged on how many findings a scanner produces but on the interval between a CVE becoming public and the organisation knowing whether it is actually exposed, and on whether the ordering that follows reflects reachability rather than severity score.

Five of the six defeat rule-based detection for the same underlying reason: the malicious thing is composed entirely of legitimate parts. A rule can match a known-bad indicator. It cannot easily express the idea that this particular account does not normally authenticate to that particular server at this hour using that protocol, because the rule that would catch it also catches the twenty legitimate cases a week where someone does exactly that for a good reason.

Behavioural baselining is what changes that, and it is why AI UEBA appears in four of the six use cases below. A baseline held per identity and per entity does not ask whether an action is permitted; it asks whether this actor does this. That is a much better question, and it is only answerable by a system holding enough history to know the difference.

The second thing they share is that the decision has to be followed by an action within the same window that the detection was useful in. A correct conclusion about a ransomware intrusion that sits in a queue for forty minutes is not materially better than no conclusion. This is the specific gap that agentic execution closes and that assisted tooling does not: the platform reaches the judgement and acts on it inside the policy envelope, rather than ranking it for someone to reach later.

Each page follows the same structure, so they can be compared rather than only read. It states what the threat class is and why it is hard, describes what the platform observes and how a conclusion is reached, sets out what action follows and what boundary constrains it, and names what an evaluation should test if you want to verify the claim rather than accept it.

That last part is deliberate. Every vendor in this category claims all six of these. The useful question is not whether a platform lists a use case but what it produces when the case is run against your own data, which is the subject of the evaluating autonomous defence guide.