A Detection Engineer's Guide for Delegating Work to AI

What it is

A Huntress detection-engineering essay built around one M365 incident, arguing a general rule: you can safely delegate work to AI only to the extent you can cheaply check its output. The existing summary covers the misfire (Outlook desktop client's app ID flagged malicious via wrong denominator). This adds the resolution and a concrete delegation framework.

How it works

The model's data was correct — the identifier appeared in a known-compromised mailbox and was rare in that org. The error was scoping: measured against the wrong denominator. Scored against the full customer base, the Outlook client appears in over 17% of customer organizations, so a rule on it fires on legitimate activity everywhere. The same query, scoped correctly, surfaced the actual malicious tooling.

What to do

The real malicious indicator, now a live rule with two true positives and no false positives so far, had this signature:

• Appeared in only three organizations
• Was in no Microsoft catalog
• Did nothing but rewrite inbox rules

The delegation test — for any AI-generated detection — is three manually-defined checks AI can then run as bounded passes:

• Is this already covered by existing rules? (In their run, most suggested detectors already existed at lower priority → one list expansion, three experimental rules.)
• Does it detect the activity it was meant to?
• How many alerts will it generate in a month?

Key operational principle: a check must be able to fail — one that always passes is not a check. When you find yourself correcting a model on the same drift repeatedly, encode the correction as a hook so it runs itself, and move attention up a layer.

Caveats

The two-questions those three checks don't answer, per the author: whether the rule is safe to ship, and whether it creates false positives at scale. The checks buy more review passes in the same time — they do not certify correctness. Risk tolerance is separate and sometimes imposed, not chosen.