Concepts
Hunt Ledger and Automation
Hunt Ledger and Automation share the same tenant, audit model, and response-action receipts. They are not the same feature and must not be marketed as duplicates. One proves continuous hunting work; the other orchestrates multi-step response after a case already exists.
Why people confuse them
Both surfaces can involve scheduled work, findings, tickets, human approval, and links into incidents. From the outside that can look like “two SOAR products” or “two automation pages.” Inside the console they sit in different navigation groups and answer different operational questions.
Hunt Ledger lives under Operate. Its job is to answer: were we watching while the queue was quiet, and what did we check? Automation lives under Configure at /automation. Its job is to answer: given this incident, what governed multi-step sequence should we run?
Hunt Ledger — continuous hunting and proof of work
A hunt run is a tenant-scoped job with a time window (default last 24 hours). Celery beat schedules run_nightly_hunts once per day (86400 seconds) across tenants discovered from tenant settings or telemetry. Operators with detections:manage — or an admin role baseline — can also click Run hunt now on /hunt-ledger.
Each run executes a fixed, deterministic check set. Today that set is: IOC IP Match (recent real telemetry vs cached bad IPv4 indicators), Stale High-Severity Incidents (high/critical cases still in new/triaged/investigating beyond 24 hours), and Privilege Signal Cluster (privilege/admin/elevation-related telemetry clustered by entity with a volume threshold). Every check is recorded even when disposition is clear. An empty morning still leaves a ledger; that is the point.
Findings use disposition clear, found, or proposed. Proposed findings may open an incident and create a create_ticket response action in requested status. Hunt Ledger does not isolate endpoints, disable accounts, revoke sessions, or start multi-step playbooks by itself. The operator reviews the case in Incidents; if a playbook is warranted, they start or resume it in Automation.
- Route: /hunt-ledger (Operate)
- UI: posture strip + Checks / Findings / History tabs
- API: GET /v1/hunt-ledger, POST /v1/hunt-ledger/runs, run/findings detail routes
- Worker: beacons_worker.tasks.run_nightly_hunts on the risk queue
- Primary output: run summary, per-check coverage, findings, optional incident + pending ticket
Automation — incident-driven playbooks
Automation is the SOAR-shaped layer. Authors draft playbooks with ordered steps (trigger, enrich, condition, branch, task, approval, action, verify, wait, notify, sub_playbook, rollback, end), validate dependency order and approval gates, then publish an immutable version. Entry rules match incident lifecycle events (for example new_incident with severity conditions) and pin a published playbook version. Runs execute in live, dry_run, or shadow mode.
Destructive connector actions cannot advance past an approval step without a matching response-action receipt and the exact response scope permission (for example response:isolate_endpoint). Approving inside Automation resumes the run; cancelling or rejecting stops advancement. Runs keep step state, attempt counts, errors, and rollback eligibility.
The Automation workbench views are Overview, Playbooks, Rules, Runs, Approvals, Templates, and Documentation. Continuous overnight hunting is not this surface — that is Hunt Ledger.
- Route: /automation (Configure)
- Primary question: given this incident, what governed sequence should we run?
- Outputs: versioned playbook runs tied to incidentId, approval gates, connector receipts
Side-by-side comparison
| Dimension | Hunt Ledger | Automation |
|---|---|---|
| Nav group | Operate | Configure |
| Trigger | Nightly schedule or Run hunt now | Rule match or manual run on an incident |
| Unit of work | Hunt run + checks + findings | Playbook run + steps |
| Quiet-period value | Shows checked / clear / found / proposed | Idle until a case needs response |
| Containment | Does not execute isolation/disable/block/revoke | May request actions only after approval gates |
| Typical handoff | Finding → incident → optional playbook | Incident → playbook → approval → action → verify |
| Permissions (typical) | console:read to view; detections:manage to trigger | automation:read / author / publish / run / approve / … |
Shared infrastructure without duplication
Both write tenant-scoped records. Both can surface pending human decisions. Both can create or wait on response_actions. That shared custody is intentional: one approval and audit model across the product.
What must not happen is UI or docs that call Hunt Ledger “automation” or Automation “overnight hunting.” If a hunt needs multi-step response, open the case and run a playbook. If a playbook needs continuous hunting coverage, that coverage belongs in Hunt Ledger checks — not as a hidden nightly playbook that pretends to be a ledger.