2.6.3. AI Use Cases in the SOC
💡 First Principle: Use AI where the task is reading, summarizing, comparing or drafting at a scale humans cannot match — and keep the analyst in the loop wherever an output becomes a finding, a report or an action.
The six use cases CompTIA lists:
| Use case | What AI contributes | What the analyst still does |
|:---------|:--------------------|:----------------------------|
| Comparing artifacts | Highlights functional differences between two scripts, emails, configs or malware samples' strings; explains obfuscated code | Confirms differences with a direct diff or hash comparison; decides what the differences mean |
| Analyzing log files | Summarizes large log sets, surfaces rare values, drafts SIEM queries and regular expressions | Reviews the query logic, runs it against the full data in the SIEM, checks results against raw events |
| Document creation | Drafts incident reports, executive summaries, playbooks and communication templates | Verifies every fact, tailors detail to the audience, removes data the audience must not see |
| Incident investigation | Proposes hypotheses, suggests next investigative steps, maps observed behavior to ATT&CK techniques | Tests each hypothesis against evidence; the evidence wins when they disagree |
| Event correlation | Links related events across separate tools and logs into one storyline (a failed-MFA burst, a new inbox rule and a bulk download for the same user) | Validates that the linked events really belong together; judges scope |
| Automation and orchestration | Enriches alerts, recommends playbook actions, executes low-risk steps through SOAR integrations | Approves high-impact actions; keeps the AI's integrations least-privilege |
The verification loop. Every use case above shares the same shape: AI drafts, the analyst verifies against the source, and only verified output becomes evidence, a report or an action.
AI in automation — the agency question. When an AI can act (through SOAR, APIs or an agent framework) and not just advise, a hallucination or an injected instruction becomes an action. OWASP's Excessive Agency (LLM06) names the three causes to design out: excessive functionality (tools the AI does not need), excessive permissions (a read task running with write or admin rights) and excessive autonomy (high-impact actions with no human approval). The design pattern the exam rewards: the AI enriches and recommends freely; low-risk, reversible actions may be automated; high-impact actions such as isolating a production server or disabling an executive's account require analyst approval; and the AI's service account holds only the permissions its task needs.
Where AI output must not go unverified:
-
Into evidence — preserve originals; an AI's deobfuscated or summarized version is an analysis product, not the artifact
-
Into a closed ticket — "the AI found nothing" is not a disposition; the analyst's review of the underlying events is
-
Into an external report — regulators, customers and executives act on what the report says
-
Into an attribution — two samples sharing strings is a lead, not proof of the same actor
⚠️ Exam Trap: Asking the AI the same question again and getting the same answer does not verify it. Consistency is not correctness — a model can repeat the same hallucination. Verification means checking against something outside the model: the raw log, the NVD entry, the file hash, the mail gateway record.
Reflection Question: An AI assistant's investigation summary states that the attacker moved laterally from WS-114 to the file server at 02:10. EDR telemetry shows WS-114 was powered off from 22:00 to 07:30. What does this tell you about the summary, what do you investigate next, and how should the discrepancy be recorded?