In one paragraph
A human approval step is a point where an autonomous system stops and waits for a named person to say yes or no. A good one sits at a decision that is costly to undo, shows the approver the evidence rather than only a verdict, records who decided and why, and does nothing if no one answers. Designing it before a trial is easier than adding it afterwards.
Guide updated September 2026 · Autonomous Threat Hunting editors
3 min read
Where should approval sit?
The human in the loop page names four decision points: which intelligence and data the system may use, whether a finding is real, whether a detection ships, and whether any response action runs. Not every point needs a click on every run. A useful test is reversibility: the harder a step is to undo, the more it needs a person. Granting access to a new data source and running a response action are hard to undo. Reading a finding is not.
What should the approver see?
- The request in one sentence: what will happen, and on which systems.
- The evidence: the queries run, the data sources and time range, and the hits that support the request.
- What the system did not check, stated plainly.
- The effect of saying yes, and the effect of saying no.
What should be recorded?
Each decision should leave a record with the approver's name, the time, the choice and an optional reason. Detection-as-code workflows already do this for rules, where a change carries a diff, an author and an approver. The same record should exist for response actions and for changes to data access.
What if no one answers?
The default for an unanswered request should be no action. Set a time limit after which the request expires or passes to a second person, and review expired requests every week. A steady pattern of expiry means the step is in the wrong place or goes to the wrong people.
Who can change the rules?
The setting that decides which steps need approval should itself need approval, and every change to it should be logged. In a trial, ask the vendor to show where that setting lives and who can edit it. The checklist has related questions on human controls.
A short test before you rely on it
- Send one request to an approver who is away, and check that nothing happens when the time limit passes.
- Change the approval setting with an account that should not be allowed to, and check that the change is refused and logged.
- Approve one request and reject another, then find both decisions in the audit trail with names and times.
If any of the three fails in a trial, it will fail in production. Fix the setting, or the process around it, before the system is given more scope.