In one paragraph
Corroboration is the step where a system checks a hunt hit against other data before handing it to a person. Done well, it turns a matching row into a finding with supporting and contradicting evidence attached, and it keeps the review queue short. Done badly, it is a second look at the same log. This lesson describes what separate evidence looks like, how corroboration can mislead, and how to test it.
Guide updated September 2026 · Autonomous Threat Hunting editors
3 min read
Why a single hit is not a finding
A hunt query returns rows that match a pattern. Most matches have ordinary explanations: an administrator doing their job, a scheduled task, a new device. If every match went to a person, autonomous hunting would recreate an alert queue. Corroboration is the filter between the two: before presenting a hit, the system looks for other data that supports or contradicts it.
Vendors describe this step in different words. In alphabetical order: Artemis Security describes correlating identity, cloud, endpoint and SaaS signals during autonomous investigation; Mars Security describes handing analysts "a corroborated shortlist rather than a scored queue"; Vega says "Every step of the hunt shows its work", which puts the evidence in front of the reviewer. The side-by-side view records which vendors describe it.
What makes a second source count
The value of corroboration depends on how separate the second source is from the first. Three levels are useful to tell apart.
- Same source, different query: rerunning the hit against the same log with different filters. It can remove noise, but it cannot confirm anything the first log did not already show.
- Different source, same event: a sign-in seen in the identity provider and in the cloud audit trail. This confirms the event happened, but not that it was malicious.
- Different source, follow-on behavior: a sign-in followed by a process launch on the endpoint or a data access in cloud storage. This is the strongest kind, because it shows the next step an attacker would take.
A finding supported only by the first kind should be presented as unconfirmed. A finding with the third kind deserves a reviewer's attention first.
How corroboration can mislead
- Missing sources look like contradiction. If the endpoint log was unavailable during the hunt, the absence of a follow-on process says nothing. The report should list unavailable sources.
- Shared upstream data looks like separate evidence. Two platforms fed by the same collector are not two witnesses.
- Confident summaries hide weak evidence. A language model can write a firm conclusion over thin support, which is the false confidence risk on the risks page.
What the reviewer should see
For each finding: the original hit, every source checked afterwards, whether each supported, contradicted or was unavailable, and the exact queries used. With that, a reviewer can agree or disagree with the system in minutes. Without it, the reviewer either trusts the verdict or redoes the work.
Testing corroboration in a trial
- Pick one finding and ask the vendor to list every source it checked, including the ones that returned nothing.
- Disable one source for a day and see whether findings from that day say so.
- Ask to see hits the system decided not to present, with the reason. The discarded list shows how the filter behaves.
Next, the step after a finding is confirmed: turning hunt logic into a production detection.