In one paragraph
When a hunt finds something real, the logic that found it can become a standing detection. That promotion step is where autonomous hunting touches production, so it needs the most care: a test against historical data, a reviewable change record, an approver, and a way back. Vendors describe different parts of this chain. This lesson lays out the whole chain and what to check at each link.
Guide updated September 2026 · Autonomous Threat Hunting editors
3 min read
Why promotion needs its own controls
A hunt runs once and reports. A detection rule runs continuously, raises alerts that people must handle, and keeps doing so long after anyone remembers why it was written. A poor hunt wastes an hour; a poor rule can generate a stream of false alerts for months. That is why this guide treats detection promotion as a decision point for a person, listed on the human in the loop page.
Link 1: test the rule against history
Before a rule goes live, it should run against historical data to show how often it would have fired and on what. This is a backtest or retrohunt. Two vendors in the directory publish a specific gate. Mars Security states that each rule is backtested against 30 days of the customer's own data before it goes live. Nebulock's documentation states: "Every detection rule must pass a Retrohunt before deployment."
Ask how long the test window is, what counts as passing, and whether the results are shown to the approver. A backtest that ran but was never read is not a control.
Link 2: record the change
The rule should arrive as a reviewable change, usually through detection-as-code: the rule text in version control, with a diff, an author and a history. Vendors describe this in their own terms, in alphabetical order: Anvilogic describes detection-as-code with version control; Cotool states compatibility with existing detection-as-code infrastructure; Nebulock describes rules exported to GitHub with immutable version history, compare and revert; Vega states "Every change has a diff, an author, and an approver."
Link 3: a named approver
Someone should decide that the rule ships. The approver needs the hypothesis the rule came from, the finding that confirmed it, the backtest result and the platforms it will run on. Check who can approve, whether the system can deploy without approval, and whether that setting is itself logged. The lesson on designing a human approval step covers the design.
Link 4: a portable format
Rules held only in one vendor's format are hard to review outside the product and hard to move. Open formats such as Sigma, a "generic and open signature format" with converters to platform query languages, let a person read and test the rule outside the tool that wrote it. Ask whether promoted rules can be exported as Sigma or into your own repository.
Link 5: a way back
Every promoted rule needs a rollback path and an owner. Data sources change, and a rule that worked in its backtest can stop matching or start matching too much, a problem called detection drift. The Running it track includes a lesson on retiring and revising automated hunts and the rules they produce.
Questions to ask
- Walk me through one rule from the finding that produced it to production, showing each link.
- What is the backtest window, and what result blocks a rule?
- Can the system deploy a rule with no human approval? Where is that set?
- Can we export every promoted rule to our own repository?