Detection engineering by agents: tuning, health and coverage

Detection engineering is the upstream fix for alert volume

Triage agents deal with the alerts you have. Detection engineering decides which alerts exist. A noisy rule that fires 500 times a day with three real hits costs more than any triage agent can save. Tuning it is cheaper.

That is why detection engineering is one of the seven use cases in the index. Mate and Prophet document it as a product; Intezer, Exaforce and 7AI document adjacent features.

Tuning starts from verdict data

An agent that investigates every alert knows which rules produce false positives and why. Intezer says investigation results feed back into detection rules. Mate's detection engineering covers tuning as a named capability. Prophet's AI Detection Engineer builds detections alongside triage.

Ask for the loop in writing: verdicts feed a tuning proposal, a human reviews, the change is backtested on historical data, then applied. Prophet says learned changes are previewed and backtested before they apply.

Rule health catches what stopped working

Rules break silently. A log source changes format, a field is renamed, a connector fails, and the rule never fires again. Nobody notices because silence looks like safety.

Mate lists rule health under detection engineering and tool and data-source health under security engineering, though the security engineering item is a one-line tile with no product page. Ask any vendor to show a rule that stopped firing and how the platform flagged it.

Coverage needs a map and an honest denominator

Coverage means: of the attacker techniques that matter to you, how many do you detect. The usual map is MITRE ATT&CK. Simbian's home page says the best of 32 products covers 45.1 percent of ATT&CK tactics and that only 7 of 13 clear 50 percent; the runner and date are not stated there, and Simbian publishes its own ranking that puts itself first.

Pick the denominator yourself: the techniques in the threat reports relevant to your sector. A coverage percentage against all of ATT&CK flatters nobody and helps nobody.

Detection-as-code makes agent changes reviewable

If your rules live in a repository with tests, an agent's proposed change is a pull request a human can review. If rules live only in a SIEM console, agent changes are harder to audit. Prefer platforms that can write to your repository and run your tests.

Three numbers show whether it works

Track false-positive rate per rule before and after tuning, the count of rules flagged as unhealthy and fixed, and coverage against your chosen technique list each month. A vendor that cannot produce these from its own data after 30 days is doing triage, not detection engineering.

Retiring rules is part of the job

Detection estates grow and rarely shrink. Rules written for a tool you replaced, a threat that no longer matters, or a test that ran once stay in place and keep producing noise. An agent with verdict data can show which rules have not produced a true positive in 12 months and which overlap with others.

Ask any vendor whether its platform proposes retirements as well as new rules and tuning. Retirement needs the same review as any other change, with a record of why the rule was removed in case the threat returns.

Low-severity alerts hold more signal than their label suggests

Intezer's AI SOC Report 2026, built on 25 million alerts from its customer base, says more than 60 percent of alerts are never reviewed by SOC or MDR teams and that nearly 1 percent of real incidents trace back to the lowest-severity alerts. It is a vendor-run figure, grade B in our audit, and the report itself was not read.

If the pattern holds in your environment, severity labels on rules are worth revisiting. An agent that investigates every alert, as Intezer and Prophet both claim to do at every severity, produces the data to re-rank rules by the outcomes they actually lead to.

Keep a human owner for every rule

Agents can draft and tune, but a rule without a named owner decays. Assign each rule, or each rule family, to a person who approves changes and answers for its noise. Review agent proposals in the same queue as human ones, using the same tests.

Prophet's statement that learned changes are previewed and backtested before they apply is the model to ask for. Mate lists tuning, health and coverage under Agentic Detection Engineering; ask Mate, and every other vendor, to show the review step and the backtest result for one real change.

Match the platform to your rule language

Rules are written in the query language of your SIEM or EDR: Splunk SPL, Microsoft KQL, Sigma, or a vendor format. Ask which languages the agent can read and write, and whether it can translate between them. A detection engineering agent that only writes its own format locks your rules to its platform.

Count rule changes, not rule drafts

A platform that drafts fifty rules a week and ships none has not done detection engineering. Measure approved, deployed changes per month and the noise each removed.

Platforms discussed in this guide

• Mate Security, rank 1, 6.70
• Prophet Security, rank 7, 5.90
• Intezer, rank 8, 5.90

Terms used

• Detection-as-code
• Rule health

More guides

• How to run a 30-day agentic defense proof of value
• Gamebooks versus playbooks: what changes when procedures become structured guidance
• Reading an AI SOC accuracy claim: sample, method, date