Impossible Travel Tuning
Runs after a case is closed. The goal is not to judge the alert again — it is to decide whether the detection itself should change so the next occurrence of this pattern is either suppressed earlier or caught with more context. Every proposal is a suggestion for human review; nothing is auto-applied.
Inputs
- Triage report — the gate that resolved, the dismissal reason code or escalation evidence, and the egress/device/MFA facts gathered.
- Investigation report — the verdict, the evidence chain, and any infrastructure indicators (ASNs, IP ranges, device fingerprints).
- Analyst verdict — the human's final disposition and any notes on why it differed (or not) from the automated verdict.
Tuning procedure
Work through these in order and stop at the first that applies.
1. Recurring benign egress
If the case was dismissed (or investigated to benign) because of egress
infrastructure that is not yet in the known-egress inventory — a new
corporate VPN range, a SASE point of presence, a carrier NAT block seen
repeatedly for this population — propose exclude with the specific range
or ASN as the value. Cite every prior case that hit the same range.
2. Over-broad exclusion
If a true positive was suppressed or delayed by an existing exclusion — or
the investigation shows an inventoried egress range now also covering
attacker infrastructure — propose include: remove or narrow that
exclusion, citing the case it hid and any others that would resurface.
3. Threshold friction
If the last 30 days show three or more benign cases whose computed travel
velocity sits just above the current threshold (within 20%), propose
modify on the velocity threshold or the minimum-distance floor. Include
the velocity distribution of recent true and false positives so the
reviewer can see what the new threshold would have suppressed.
4. Population mismatch
If the case shows the detection performing well generally but poorly for an
identifiable population — executives who travel weekly, a region with known
GeoIP drift, service accounts that should never travel at all — propose
fork: a copy of the detection scoped to that population with tightened or
loosened gates, leaving the base detection untouched.
5. No change
If the alert worked as designed — escalated a true positive or dismissed an
explained anomaly with an inventoried reason — return the action none
with no target or value. A tuning skill that always suggests something
trains reviewers to ignore it.
Output
Action
One of exclude | include | modify | fork | none. none is the
explicit no-change result — return it with reasoning rather than omitting
a proposal.
Target
The detection ID or inventory list the change applies to (empty for
none).
Value
The specific range, ASN, threshold, or fork scope to apply (empty for
none).
Evidence
Prior-case references, hit counts, and the expected alert-volume impact. One proposal per run — if several gates apply, return the one with the largest false-positive reduction and note the runners-up here.
Reasoning
Which gate applied, the case facts that satisfied it, and why the proposed
change (or none) follows from them.
