Autonomous Detection Engineering: How the SOC's Detection Library Can Write and QA Itself

Most security platforms treat detection content as a static library that somebody else wrote. You buy generic rules, then your detection engineers spend their careers making them relevant: tuning thresholds, chasing false positives, mapping coverage, and retiring what no longer fires. The tools ship the easy 20 percent and hand you the hard 80.

Autonomous detection engineering inverts that. Detection content becomes a living output of the environment itself, generated from your telemetry, validated against your real data, and deployed only once it has proven its value. It is, in effect, a detection engineering team operating inside the platform, running continuously.

This is the next step beyond detection-as-code. Detection-as-code gave detections version control, testing and CI/CD, which was a real advance, but a human still writes every rule, decides every threshold, and owns the backlog. Autonomous detection engineering keeps the rigour and removes the bottleneck.

The loop: observe, propose, prove, deploy

1. Coverage intelligence: what could we detect?

The pipeline starts from a live model of the environment’s detection potential, built from four signal sources:

• Telemetry and schema awareness. A real-time inventory of every ingested source, field and value distribution. When a new log source comes online or a new field appears, a new EDR module, a new API version, a custom application field, it registers as fresh detection surface and evaluates what becomes detectable that wasn’t before.
• Threat intelligence. Incoming adversary TTPs and campaign reporting are decomposed into detection opportunities and matched against the telemetry inventory: given the data we actually have here, which of these behaviours can we see?
• Hunt findings. Autonomous hunts surface behaviours no existing rule covers. Every finding is assessed as a candidate for permanent codification: if the hunt found it once, a detection should catch it every time.
• Alert history. The environment’s own record of what fired, what was confirmed, what was missed and only found during investigation, and where analysts repeatedly correlate the same signals by hand. Investigation-discovered patterns are prime candidates for promotion into standing detections.

All of it maps to MITRE ATT&CK. The result is a per-environment coverage matrix: which techniques are covered, by which detections, with what telemetry, and where the gaps are. The gap analysis is telemetry-honest, a technique is only marked coverable if the data to detect it actually exists in the environment, which also lets the platform tell you which single new log source would close the most gaps.

2. Candidate generation: what should we deploy?

From the coverage model, the platform generates candidate detections: a rule, a behavioural or statistical model, or a multi-signal use case. Each candidate carries a full engineering record, the ATT&CK techniques it addresses, the exact fields and sources it consumes, the trigger logic, the rationale (which intel item, hunt finding or alert-history pattern motivated it), and a predicted noise profile based on observed value distributions. Candidates are prioritised by risk relevance: techniques active in current campaigns against your sector, and gaps adjacent to past confirmed incidents, rank above theoretical coverage.

3. The QA gate: does it actually add value here?

No candidate reaches production on plausibility. Each passes a multi-phase validation gate, run inside your own environment against real data:

• Deduplication. Compared against every deployed detection at the logic level, not just by name, so the library never accumulates ten variants of the same rule.
• Value-add scoring. Does it close an uncovered technique, catch something the alert history shows was previously missed, or materially tighten detection latency? Candidates that duplicate existing coverage without measurable gain are rejected before a single query runs.
• Build. Compiled against the live schema and validated for correctness: fields exist, types match, joins resolve, models train.
• Shadow run. Executed silently, backtested against historical telemetry and run forward against live data, generating internal alerts visible only to the QA pipeline.
• Alert cross-check. Every shadow alert is examined by the platform’s investigation agents exactly as a production alert would be, and reconciled against ground truth: past confirmed incidents (did it catch what we know happened?) and known-benign patterns (does it fire on backup jobs, scanners, service accounts?).
• False-positive measurement. Hard numbers: alert volume, false-positive ratio, overlap with existing detections, estimated analyst load. Too noisy and it goes back for automated tuning, then re-enters the shadow phase. Fires never and covers no confirmed gap, and it is held rather than shipped as dead weight.

Only a candidate that is unique, valuable, correct and quiet is promoted.

4. Automated deployment and lifecycle

Promotion is fully automated: no change window, no professional-services engagement. Each deployed detection carries its validation evidence, the QA record, the measured false-positive ratio, the ATT&CK mapping, so coverage claims are auditable rather than asserted. And QA never ends: each live detection is continuously monitored, re-tuned when the environment drifts, and flagged for retirement when its telemetry disappears or a better detection supersedes it.

Why it matters

Legacy SIEMs leave relevance, tuning, false-positive control and lifecycle to your engineers. Autonomous detection engineering generates detection content from your environment, validates it in your environment, and deploys it only when it has proven its value in your environment. The result is a detection library that grows with your telemetry and the threat landscape, stays MITRE-aligned by construction, and gives the SOC a defensible, current answer to the one question that matters: what can we detect today?

In Blacklight this capability is the Plugin Hub, and like everything in the platform it is included at every tier, with no content packs, add-ons or professional-services fees. See it in the platform overview, or read the companion pieces on what agentic AI actually changes in the SOC and why the autonomous SOC was the wrong target.