Autonomous Threat Hunting

LESSON 2 · FOUNDATIONS

From advisory to hypothesis: how an autonomous system reads intelligence

The first two stages of an autonomous hunt, and where they go wrong.

In one paragraph

Every autonomous hunt begins with a piece of intelligence and a decision about whether it matters here. The system has to pull out the behavior described, check it against what the organization runs, and write a hypothesis that names the data needed to test it. Weak intake produces hunts nobody needed; a vague hypothesis produces results nobody can judge. This lesson walks through both stages and the questions that expose them.

Guide updated September 2026 · Autonomous Threat Hunting editors

3 min read

What counts as intelligence?

For an autonomous system, threat intelligence is any input that describes how an adversary operates: a government advisory, a vendor research post, a commercial or community feed, or the team's own incident notes. Vendors describe different mixes. In the directory, in alphabetical order: Artemis Security states that its continuous hunts draw on "100+ intelligence feeds"; Cotool describes agents that crawl the web to produce structured threat intel and accepts custom intel including STIX/TAXII; Mars Security names advisories from CISA, Mandiant, Unit 42 and Microsoft Threat Intelligence; Nebulock names intel from CrowdStrike, Mandiant, MISP and community feeds.

The source matters less than two properties: whether you can see which items the system read, and whether you can add your own. A system that hunts on intelligence you cannot inspect gives you results you cannot trace back to a reason.

How does a system decide an item is relevant?

Most intelligence describes activity that will never touch a given organization. Relevance checks narrow it down, typically by comparing the technologies, platforms and exposed services named in the item with what the organization actually runs. Cotool, for example, describes checking each intel item for relevance to the customer's environment before proposing detections.

A relevance check can fail in two directions. Too loose, and the system spends query budget on hunts for software you do not use. Too strict, and it drops an item because the asset inventory it relies on is incomplete. Ask what the check compares against, and ask to see the items it discarded in the last week along with the reason.

From behavior to hypothesis

Once an item is judged relevant, the system extracts the behavior it describes and writes a hypothesis: a statement that can be shown true or false with data. A usable hypothesis has four parts.

Hypotheses that skip the second or fourth part are the most common weakness. Without named sources, nobody can tell whether a clean result means the behavior is absent or that the right log was never searched. Without a description of a positive, every matching row looks equally important.

Who writes the hypothesis?

This is where the autonomy ladder shows up in practice. At Level 2, a person writes the hypothesis and the system runs the hunt; Vega's hunting page describes this pattern: "Give Vega a hypothesis and it runs the whole hunt autonomously across your sources." At Level 3 and above, the system writes hypotheses itself from incoming intelligence; Nebulock describes Vespyr as hunting "without a directive", and its LOCK framework starts with a hypothesis mapped to MITRE ATT&CK. Neither approach is better in general. What matters is that the hypothesis is visible and editable before the hunt runs.

Questions to ask

The next lesson looks at why good hypotheses describe behaviors rather than single indicators.