All case studies
Case study · Security operations

An agentic security operations centre that clears the queue and shows its working.

An enterprise security operations team was drowning in alerts. We built a verifier-graded agent system that triages, enriches, and closes the routine ones, so analysts spend their shift on real incidents.

Client
Enterprise with an in-house SOC, 4,000+ staff
Engagement
Discovery sprint, then a 14-week build
Team
Four CoServe engineers alongside the client's SOC lead
Deployment
An on-premise SLM box beside the analyst team, inside the security network
The challenge

Thousands of alerts a day, a handful of analysts, and no room to add more.

The security operations centre took in alerts from a SIEM, endpoint detection, identity, and cloud tooling. Most were benign: known scanners, expected admin activity, misconfigured rules firing on schedule. Each one still needed a human to open it, pull context from three or four consoles, and write a note before closing it.

Analysts were spending the bulk of every shift on this routine work. Mean time to acknowledge was climbing, the backlog was growing over weekends, and the genuinely serious alerts were queuing behind the noise. Hiring was not an option on the timeline leadership had set.

The team had tried a hosted AI assistant and rejected it. It could not see the internal tooling, it sent alert data outside the network, and when it was wrong there was no way to tell why.

What we did

Agents that do the analyst's first twenty minutes, graded by a verifier before they touch the queue.

On-premise SLM boxLocal investigation, no outside APIVerifier-graded agentsTool-using agent runtimeSIEM and EDR integrationHistorical replay evaluationAppend-only audit logAnalyst feedback loopModel inventory and governance

We started with a two-week discovery embedded in the SOC, shadowing shifts to map exactly what an analyst does with each alert class. That gave us the playbooks, the tools involved, and the evidence an analyst needs before closing or escalating.

The build centred on a triage agent that reads each alert, pulls the same context an analyst would from the client's own tools, and writes a structured verdict with its evidence. A separate verifier, defined with the SOC lead before any model work began, decides what counts as a correct verdict. Only alert classes where the agent met the verifier's bar in replay were released to auto-close. Everything else is enriched and handed to a person with the context already assembled.

The whole system runs on an SLM box: a self-contained server that sits beside the analyst team inside the client's security network. The small language model on it does the investigation, pulling logs and context from the client's own tools, so alert data never leaves the building and there is no metered bill. Every decision, every tool call, and every verifier score is logged, so an auditor can replay any closure.

The outcome

What changed once it was running.

72%Of routine alerts triaged and closed without an analyst
11 minMedian time to acknowledge, down from several hours
100%Of automated closures carry a verifier score and evidence trail
14 wksFrom kickoff to running in production
What we built

Six components, one system the client owns.

Handed over with runbooks
  1. 01

    Alert intake and normalisation

    A single pipeline that takes alerts from the SIEM, endpoint, identity, and cloud sources and maps them onto one schema the agents reason over.

  2. 02

    Triage agent with tool access

    Reads each alert, queries the client's own asset inventory, threat intelligence, identity logs, and ticketing, and writes a structured verdict with its evidence.

  3. 03

    On-premise SLM box

    A self-contained server that sits alongside the analysts and runs the small language model. It keeps every alert, log, and verdict inside the building and does the investigation on local data, with no outside API in the loop.

  4. 04

    Verifier and release gates

    An independent checker that scores each verdict against the SOC's definition of correct. Alert classes are released to auto-close only after passing on historical replay.

  5. 05

    Analyst workbench

    A queue where every escalated alert arrives with the context already gathered, the agent's reasoning visible, and one-click feedback that feeds the next evaluation run.

  6. 06

    Audit log and model inventory

    Append-only records of every decision, tool call, and score, with the model inventory and evaluation history the client's risk function asked for.

What this means for you

An agentic SOC is not a chatbot bolted onto a console. It is a set of narrow, verifiable agents that do the repetitive first steps of analysis inside your network, and a human queue that only receives what deserves a human. The same system fits any organisation running its own security operations, whatever the sector.

Get started

Tell us about your roadmap.

A 30-minute call. No pitch deck — just a conversation about what you're building.

tech@coserve.io
What happens next
01
We listen30 min call

You walk us through the problem, the constraints, and the deadline.

02
We scope itWithin a week

You get an approach, a shape for the first release, and a cost range.

03
You decideNo obligation

If we are not the right team, we will say so.