Treat an LLM-drafted Sigma rule as a first draft from a fast junior colleague. Check that the log source exists in your environment, that field names are real, that the logic means what you intend, and that it has been tested against both malicious and normal data. Parsing cleanly proves little.
Why drafts need review
Models write fluent YAML that looks right. The failure modes are quiet: a field name that does not exist in your logs, a condition that never matches, or a filter so loose it fires on every admin session. The rule parses, so nothing warns you.
The checklist
1. Required fields. Sigma requires title, logsource and detection. Confirm all three exist and the condition sits inside detection.
2. Log source fit. Is the log in the rule actually collected? If the rule needs process creation events and you do not gather them, it will never fire. Check the logsource against your real inventory.
3. Field names. Compare each field in the rule with a real event from your tool. Models sometimes borrow field names from other products.
4. Selection logic. Remember how Sigma combines things: pairs inside a selection are AND, lists of values are OR. Read the condition aloud in plain English and see whether it matches your intent. Make sure every selection is used in the condition.
5. Exclusions in logic. If the draft lists known good cases only in falsepositives, move the real ones into a filter selection. That field is a note for analysts and converters do not act on it.
6. Severity and status. Level and status are optional metadata, so a model may guess them. Set status to test or experimental for a new rule, and choose a level you would be willing to be woken for.
7. Behavior, not tool names. A rule that matches one tool's exact name is easy to bypass. Ask whether it describes the behavior.
Test it both ways
Run the converted rule against logs from a safe simulation of the behavior, and confirm it fires. Then run it against a period of normal activity and count the matches. A rule you cannot test is a rule you cannot trust. Keep the test data with the rule in version control; detection as code basics explains the workflow.
Roll out in stages
Send alerts to a review queue first, not a pager. Watch for a while, tune the exclusions, then promote the rule. Keep a person as the approver for every rule change, whoever or whatever wrote it.
Keep the prompt and the output
Save the prompt, the model name and the draft next to the final rule. When a rule misbehaves, you can see what was asked and what was changed by the reviewer.
Quick check
Can I trust a rule that converts without errors?
No. Conversion shows the syntax is valid, not that the logic is correct or that the log source exists in your environment.
Should the model also review its own rule?
A second model pass can catch some mistakes, but it is not a substitute for a human reviewer and a test against real data.
Sources
Last reviewed: 19 October 2026.
