Operating the SOC

This is the day-to-day guide: how to read the board, work a case, tune what fires, approve responses, and prove compliance. Most of the work is done by AI coworkers — your job is to set direction and approve the few decisions that matter.

Reading the console

Operations → Security → SOC Console is the first screen every shift. It is built around four questions:

Below the tiles is the recent-cases list. Click a case to open its full timeline.

Working a case

A case is a group of related detections about the same asset or the same kind of attack. It moves through a simple lifecycle:

Status Meaning
New Just opened. Awaiting first triage.
Triaging A coworker is doing first-pass assessment.
Investigating Under active investigation — evidence being gathered.
Contained A response has been applied; threat is held.
Resolved / Closed Work finished. Resolved cases feed the MTTR metric.

Each case also carries a verdict — the analytical conclusion (real threat, false positive, benign, or still unknown). The verdict is evidence, not a vote: it reflects what the investigation found, and it is what tunes your false-positive rate.

Cases form two ways, and both feed the same queue:

Working with the AI SOC coworkers

The SOC ships with a roster of AI coworkers, each with a focused job and its own human-in-the-loop limits:

They escalate to each other along a defined path (triage → investigator → incident lead), and the most consequential steps require a human sign-off. You can read everything they did on the case timeline — nothing happens off the record.

Tuning what fires

Good security operations is as much about silencing noise as catching threats.

A coworker can also propose a tuning change when it sees a rule producing false positives. The proposal is recorded for you to accept or decline — the system never quietly silences a rule on its own.

Approving a response

This is the one place the platform always asks for a human. When containment is warranted, a coworker proposes an action (isolate a host, disable a key, block an address). Before anything happens, the decision kernel scores the proposal and shows you its reasoning:

You will see the proposed action, its risk class (is it reversible? how wide is the blast radius?), and the kernel’s recommendation. You approve or decline. Approved actions are carried out by the customer’s own runner — the platform proposes, your infrastructure executes. The platform never reaches into an estate unilaterally.

Proving compliance

Every case that touches a regulated control becomes compliance evidence automatically — you do not assemble an audit trail by hand. From the compliance tools you can produce framework reports for:

Each report maps your detection-and-response activity to the framework’s Detect and Respond functions, backed by real cases. Security telemetry is retained under the platform’s data-retention policy; cases that become legal or regulated records are kept rather than purged.

Running many customers (MSP / managed service)

If you operate the SOC on behalf of several customers, federation lets you see across all of them without ever pulling their raw logs. Only a minimized summary of a detection or case crosses the link between you and a customer — the timeline, the evidence, and the raw telemetry stay on the customer’s own infrastructure. You can prove coverage and coordinate response across the fleet while each customer keeps full sovereignty over their data.

A healthy SOC, day to day