AI SOC Agent vs SIEM Rules: What Each One Should Do
SIEM rules and AI SOC agents solve different problems: rules give deterministic detection, while an agent gathers context and explains what to do next.
AI SOC Agent vs SIEM Rules: What Each One Should Do
SIEM rules and AI SOC agents solve different problems. Rules provide deterministic detection; an agent helps an analyst gather context, investigate, and explain what to do next.
Use rules for repeatable detection
Rules are the right tool when the condition is known: impossible travel, a disabled account logging in, or a process launching from an unusual parent. They are testable, versioned, and easy to audit.
Use an agent for context and investigation
An agent is useful after a signal fires. It can find related events, compare asset and identity context, translate a hunting question into a reviewable query, and draft an evidence-backed summary.
A practical boundary
Do not ask an agent to replace a detection rule that can be expressed clearly. Do not ask a rule to explain a multi-source incident. Connect both through a workflow where an analyst can review the evidence.
Why a model should never be the only judge of "malicious"
A rule is a function: the same events in, the same alert out, so you can replay last month's logs against a rule change, version it and explain why it fired. A model's verdict also depends on the prompt, the context and the model version, so two runs over one incident can disagree. When the model alone decides, a miss leaves nothing to debug: no rule that failed to match, only a paragraph that sounded reasonable.
Agents add a second problem. Many fields that reach a SIEM are text an attacker can shape: user-agent strings, URLs, file names, command lines, email subjects, usernames typed at a login. OWASP describes indirect prompt injection as a model accepting input from external sources, such as websites or files, whose content can change its behaviour. Its definition names websites and files, so applying it to log fields is our inference. A rule matches those fields as data; an agent reads them as language.
A worked example: failed logons, then a success
Microsoft documents Event ID 4625 as logged for any logon failure and 4624 as generated when a logon session is created. The 4625 monitoring notes flag status 0xC000006A (bad password) for critical and service accounts.
Recommended pattern: keep the detection replayable. This sketch is pseudo-logic, not zcrSIEM syntax:
A: count of 4625 (status or sub status 0xC000006A)
by (target account, source address) >= N within T
B: distinct target accounts in 4625 by source address >= M within T
C: (A or B), then a 4624 for a targeted account within T2,
from the same source address when 4624 has one -> alert
N, M, T and T2 are customer configuration, set from your own baseline. A and B read 4625 only; Microsoft also documents 4771 (Kerberos pre-authentication failure, domain controllers only) and 4776 (NTLM credential validation, recorded by the computer authoritative for the credentials), so add the failure events your environment produces.
After C fires, the agent's job is bounded: gather the account's other logons and draft a summary where every statement cites an event ID. Whether the success was the account owner, and whether to contain, is the analyst's call.
Watch the source join: on 4624, NTLM logons carry no TCP/IP details. Where the source is missing, C rests on the account alone, so the agent must say so, not guess.
Task-by-task: who owns what
| SOC task | What SIEM rules and queries should own | What an AI agent may assist with | What a human keeps | If the roles are swapped |
|---|
| Detect and tune a known behaviour | A versioned rule; exceptions with an owner and expiry | Drafting a candidate rule; listing what an exception would hide | Approving the rule and each exception | Verdicts shift between runs; a miss leaves no rule to debug |
| Group alerts into an incident | Correlation on shared host, user, IP and sequence | Reading the incident; reporting joins it could not make | Confirming which accounts, hosts and dates belong | Events linked by similar names; real links silently missed |
| Rank the queue | A risk score from stated factors, shown with them (severity, confidence, asset criticality, privilege, ATT&CK) | Explaining a ranking by citing those fields | Overriding the order; owning escalation | A fluent ranking nobody can reproduce |
| Contain (disable account, isolate host) | Not the SIEM (zcrSIEM has no SOAR): a zcrSOAR playbook step set to Autonomous, Approval or Blocked | Recommending a step, with evidence | Approving at the zcrSOAR Approval step | A free-form tool call hits the wrong target, no approval on record |
This split is a recommended pattern, not a zcrSIEM screen description. zcrSIEM documents predefined, custom and Sigma-based rules, UEBA risk scoring, correlation of alerts into incidents, AI summaries and natural-language questions turned into reviewable queries. Rule versioning, exception owners and expiry dates, drafting rules, an event ID for every statement and replaying rules over past logs are practices you apply, not documented zcrSIEM features. The last row belongs to zcrSOAR, which records each execution; which steps need approval, and who approves, is customer configuration.
Limits, failure modes and escalation triggers
A rule cannot see what never arrived. If a parser change or a stopped log source keeps a rule from matching, the console goes quiet and a model cannot notice an absence either, so monitor source health separately from detections. Also, do not let an agent close or suppress an alert a rule raised, because that false negative is invisible. A suppression is an explicit exception with an owner and an expiry.
Stop the agent and involve a person when a summary states something the raw event lacks, a cited event ID is not in the incident, a privileged account or domain controller is involved, or the agent recommends containment. Recommended pattern: send containment to a zcrSOAR step you have set to Approval.
Frequently asked questions
Can an AI SOC agent replace my SIEM detection rules?
No. Detection has to be repeatable and testable, and a rule is. An agent works best on events a rule has already raised, adding context, a summary and a drafted query. If it drafts a rule, a person reviews and replays it first.
If zcrSIEM has no SOAR, where does automated response run?
In zcrSOAR, which does not require zcrSIEM. Autonomous steps run immediately, Approval steps wait for a role-gated sign-off, and Blocked steps never run until the gating is changed.
How do I check an agent's output, and what if a log line tries to steer it?
Every summary statement should cite an event ID that exists in the incident, and an analyst should read a sample. Track how often analysts edit or reject drafts: that is observed behaviour, unlike another model's score. To limit the damage from steering, a recommended pattern is to treat log fields as untrusted data, give the agent no state-changing tool without approval, and keep detection on the rules and the malicious-or-benign verdict with an analyst.
Sources
- OWASP Gen AI Security Project, LLM01:2025 Prompt Injection, 2025, accessed 2026-09-28
- Microsoft Learn, 4625(F) An account failed to log on., 2026-03-29, accessed 2026-09-28
- Microsoft Learn, 4624(S) An account was successfully logged on., 2021-09-07, accessed 2026-09-28
- Microsoft Learn, 4771(F) Kerberos pre-authentication failed., 2021-09-07, accessed 2026-09-28
- Microsoft Learn, 4776(S, F) The computer attempted to validate the credentials for an account., 2021-09-13, accessed 2026-09-28
Continue: Human-in-the-Loop SOC, How AI Agents Reduce Alert Fatigue Without Hiding Evidence and the AI SOC Agent guide
Explore zcrSIEM · Compare pricing · Contact zcr
If you'd rather talk through your own environment, here's how to reach us.