AI as SOC / Classroom Force-Multiplier

Today’s job: AI as a force-multiplier for the SOC (and the classroom)

The first three days secured AI systems. Day 4 flips the lens: using AI to do security work faster. You build a real MCP server, drive it from a local tool-calling model, generate and validate detection rules, and triage CVEs — always keeping a human in the loop and everything offline. We close by looking at how the same capabilities empower attackers.

AI-assisted SecOps

AI helps most where analysts drown in volume and repetition: triaging alerts, summarizing logs, drafting detections, and prioritizing vulnerabilities. The durable pattern is AI drafts, human decides. Generated artifacts — a detection rule, a triage call, an incident summary — are proposals that a validator and then an analyst confirm. That discipline is what separates a force-multiplier from an automation liability.

From chatbot to agent: inference that can act

A plain chatbot is a single move: text goes in, text comes out. It cannot look anything up, cannot check its own work, and cannot tell you when it is guessing — so a confident wrong answer looks exactly like a right one. That is fine for drafting an email and dangerous for triaging an incident.

An agent is the same model placed in a loop with tools:

1. Reason about the task,
2. Act — call a tool (read the alert, look up the CVE, run the validator),
3. Observe the tool’s result,
4. repeat until it can answer — then hand the result to a human.

The difference is ground truth. A chatbot recalls a CVSS score from training and may hallucinate it; an agent fetches it from the dataset and reasons over the real number. Every Day 4 build is agentic in this sense — the model reasons, a tool provides the facts, and the loop, not the model’s memory, is what makes the output trustworthy. Tools are how a model stops guessing and starts working.

Model Context Protocol (MCP) servers

MCP is an open protocol that standardizes how an AI application connects a model to external tools, data, and context. Instead of bespoke glue for every integration, a model speaks one protocol to any MCP server.

Why standardize at all? Without a shared protocol, every (application × tool) pair needs its own custom integration — the classic N×M problem: M applications each hand-writing glue for N tools. MCP collapses that to N+M: wrap a tool once as an MCP server, and any MCP-speaking client (Claude Desktop, an IDE, your own runner) can use it. A server exposes three kinds of things behind one interface — tools (functions the model may call, like lookup_cve), resources (data it may read), and prompts (reusable templates). That is the entire pitch: write the integration once, use it from any client.

The MCP tool-call round-trip

In the lab your MCP server exposes two security tools:

• triage_logs(logs) — rule-based log classification (offline, deterministic).
• lookup_cve(cve_id) — CVE lookup from the bundled dataset (no live NVD).

The demo shows the full tool-call round-trip: a natural-language task goes to qwen2.5:3b with the tool schemas, the model returns a structured tool_call, the runner executes it against the MCP server, and the result is fed back for a grounded final answer. That round-trip — model reasons, tool provides ground truth — is the heart of agentic security tooling.

MCP or just a CLI? a live debate

MCP is not the only way — or always the best way — to give an agent tools, and through 2025 many practitioners have swung toward a simpler answer for a lot of tasks: just let the agent use a command line. It is worth understanding the trade-off, because “add an MCP server” has become a reflex that is not always right.

The case for the CLI:

• The model has seen enormous amounts of shell usage in training, so it already knows grep, jq, curl, git — there is no schema to define and maintain.
• CLIs compose: pipe one command’s output into the next, which a fixed set of MCP tools does not do naturally.
• They are inspectable and reproducible — you can run the exact command the agent ran and see exactly what it saw.
• Lower token cost: every MCP tool definition sits in the context window on every turn; a CLI is text the model emits only when it actually uses it.

The case for MCP:

• When there is no shell to reach for — a hosted SaaS app, a GUI tool, a remote service — MCP is how you expose it at all.
• Structured, permissioned access: a server enforces exactly which operations are allowed and returns typed results, rather than handing the model a shell and hoping.
• Portability: one server works in every MCP-speaking client, with no per-application wiring.

AI-generated detections (Sigma / Suricata)

Writing detection rules is skilled, repetitive work — a good AI target, with validation. The lab’s generate → validate → repair loop:

Generate, validate, repair — human at the end

1. Generate — the model writes a Sigma YAML rule from an incident description (SSH brute force, web-shell upload, encoded PowerShell).
2. Validate — sigma check statically validates structure/syntax offline. For network rules, suricata -T syntax-checks a Suricata rule with no live capture.
3. Repair — validation failures feed back into a repair prompt (up to two attempts).

The output is a syntactically-valid draft rule — which a human still reviews before it touches production. The lab deliberately uses static validation only (no live packet capture, no live SIEM) to stay offline and reproducible.

AI-assisted CVE triage

Given more CVEs than anyone can patch at once, the model helps prioritize. The lab loads 12 real 2024 CVEs from a bundled dataset and asks the model to label each Patch Immediately / Patch This Week / Monitor, with a one-line rationale referencing your org profile.

Two design choices matter and both come from the course’s offline rules (ADR-5):

• No live NVD — CVSS scores come from the trusted bundled dataset, so they are accurate.
• Grounded, not recalled — feeding real data prevents the classic failure of a model hallucinating CVSS scores or CVE details.

CI/CD and agents

The generate-validate-repair pattern generalizes to a pipeline: an AI agent proposes a change (a rule, a script, a config), automated validators gate it, and a human approves the merge. In CI/CD terms, the validator is your test suite and the human review is the required approval — the same guardrails you would demand of any automated contributor. Least privilege for the agent and an audit trail are non-negotiable.

Right-sizing the model: local vs. hosted

Day 4 needs a 3B tool-caller because sub-2B models emit malformed tool-call JSON — a concrete example of matching model capability to task complexity. The broader judgment call: escalate from a local SLM to a hosted API only when the task demands it (harder reasoning, larger context) and the data-sensitivity/compliance posture allows sending data off-box. This trade-off — cost, privacy, latency, capability, compliance — is the subject of the Day 5 roundtable.

Two gates before data leaves the box

AI-enabled attack vectors

The same power cuts both ways. Defenders must now anticipate AI-enabled offense:

• Deepfakes and voice cloning — synthetic audio/video for fraud and social engineering; identity verification must adapt.
• Automated, personalized phishing at scale.
• AI-accelerated tooling — faster reconnaissance, exploit drafting, and evasion.