Industry

AI in the SOC,
an analyst on the trigger.

Triage at machine speed. Analysts decide. Alert triage, threat intelligence and NIS2 and DORA evidence for security teams, built on the assumption that every log line may be written by an attacker. The investigation is accelerated; containment stays an analyst’s call.

Last reviewed 30 October 2026 · Engineering guidance, not legal or regulatory advice.

In context

AI in cybersecurity, for a SOC, means agents that enrich and investigate alerts, summarise threat intelligence and assemble compliance evidence, so analysts start each case with the context gathered. Because attackers control much of the data a SOC reads, the system must treat it as untrusted, and containment actions need a person’s approval.

Where it breaks today

More alerts than analysts

SIEM and EDR tools raise far more alerts than a team can investigate properly, most of them benign. Each still needs the same first steps (look up the host, the user, the hash, the history) before anyone can tell. That repetition burns out the people a SOC can least afford to lose.

The attacker writes the input

A SOC’s data is partly written by its adversary: email bodies, file names, user agents, command lines. An AI agent that reads them can be instructed by them. Prompt injection is not a theoretical risk in security operations; it is the obvious attack on any AI SOC.

Evidence for regulators is manual

NIS2 and DORA expect documented risk management, incident reporting on tight timelines and testing records. The evidence exists across tickets, scans and policies, and is assembled by hand under deadline.

OUR APPROACH

How AI is used in cybersecurity, safely

We build AI SOC tooling on two rules. First, alert content is data, never instruction: the agent’s permissions are set by the analyst’s task, not by anything it reads, and tools that change the environment are outside its reach. Second, read freely, act narrowly: enrichment queries against Splunk, Microsoft Sentinel, Elastic or the EDR run automatically, while isolating a host, disabling an account or blocking an address waits for an analyst’s approval, with the evidence attached.

Within those rules the gain is real. The first fifteen minutes of most investigations are the same lookups in the same order, and an agent can have them done, and written up against MITRE ATT&CK, before an analyst opens the case. The analyst’s time moves from gathering context to judging it. Every step the agent takes is logged as it would be for a person, which is what an incident review or a regulator will ask for.

HOW IT DEPLOYS

PHASE 01

Replay closed cases

Run the agent over alerts your team has already resolved and compare its write-up and verdict suggestion with what the analyst concluded.

PHASE 02

Read-only in production

Enrichment and write-ups on live alerts, with no response actions available, while analysts rate the output.

PHASE 03

Approved actions

Response actions added one at a time as playbook steps an analyst approves, each with a defined scope and rollback.

What we build

SOC alert triage

An AI SOC analyst assistant that enriches each alert, investigates the standard questions and writes up the case with a suggested disposition for a human analyst to confirm.

SEE ALERT TRIAGE →

Threat intelligence summaries

Reports, advisories and feeds summarised against your own estate, with indicators extracted to STIX and techniques mapped to ATT&CK, every claim cited to the source.

SEE THREAT INTELLIGENCE →

NIS2 and DORA evidence

Evidence for risk-management measures, incidents and testing gathered from the systems that hold it and mapped to the requirements, for the compliance owner to review.

SEE NIS2 & DORA EVIDENCE →

Guardrails for agents

Input isolation, tool permission scopes and output checks designed for agents that read untrusted content, which every SOC agent does.

SEE GUARDRAILS →

Controls we implement

ALERT CONTENT TREATED AS UNTRUSTED ANALYST APPROVES EVERY ACTION READ-ONLY BY DEFAULT SELF-HOSTED MODELS AVAILABLE EVERY AGENT STEP LOGGED NO TRAINING ON YOUR TELEMETRY

These are engineering controls we build into the architecture, not certifications. QQuantum.ai holds no security certifications, and your NIS2, DORA and other regulatory obligations remain yours — see our security notes.

Cybersecurity use cases

CYB.01

SOC Alert Triage

An AI SOC analyst that enriches alerts through read-only SIEM, EDR and identity lookups and writes the case with a suggested disposition. It never closes alerts or contains hosts itself.
Open page
CYB.02

Threat Intelligence Summaries

Reports and advisories matched against your asset inventory and detection coverage, indicators extracted to STIX and techniques mapped to ATT&CK, with every claim cited to its source.
Open page
CYB.03

NIS2 & DORA Evidence

NIS2 and DORA evidence collected continuously from tickets, scans, IAM and policies, mapped to requirements with gaps flagged. Scope, significance and sign-off stay with your compliance owner.
Open page

Questions

Questions about Cybersecurity & SOC.

How can generative AI be used in cybersecurity?

On the defensive side, mainly to take on repetitive analysis: enriching and summarising alerts, drafting investigation notes, translating natural-language questions into SIEM queries, summarising threat reports and assembling compliance evidence. It is useful wherever an analyst reads a lot to decide a little. It is risky wherever it can act on its own or be steered by attacker-controlled text, so those paths need tight limits.

What is an AI SOC?

The term usually means a security operations centre where AI agents handle the first stages of alert investigation: gathering context, running standard lookups and proposing a disposition, so human analysts review cases rather than build them from scratch. In the systems we build, the agent recommends and documents; an analyst decides on verdicts and approves any containment action.

Will SOC analysts be replaced by AI?

The repetitive tier-one work of enrichment and first-pass triage will shrink. Judgement about ambiguous cases, incident response, threat hunting and the accountability for decisions that affect the business remain with people, and attackers adapt to whatever automation a SOC relies on. Teams that use AI well tend to move analysts up the work, not out of it.

Can attackers manipulate an AI security analyst?

Yes, if it is built naively. Text in an email, a file name or a log line can contain instructions aimed at the model, which is prompt injection. Defences are architectural: treat all alert content as data, limit the agent’s tools to read-only enrichment, check outputs, and require human approval for any action. No model is immune, so the limits matter more than the model.

Do NIS2 and DORA allow AI in security operations?

Neither prohibits it. Both require effective risk management, incident handling and, for DORA, ICT third-party risk management, so an AI tool in the SOC becomes part of what you manage and evidence. If it relies on a third-party model provider, that provider may need to be in your third-party register. The assessment is yours to make; we document the design to support it.