AISOC by Quantinel Security operations platform

From alert to evidence-backed decision.

AISOC investigates each SIEM/SOAR alert, collects the evidence and returns a reasoned verdict and report in which every finding points to its source record. Response steps arrive with their blast radius assessed — and wait for an authorized person to approve them.

Operating principle AI-led investigation. Human-controlled response.

Conceptual product preview

Animated illustration: a synthetic alert for host WS-DEMO-014 is normalized, enriched with asset, user and threat-intelligence context, linked to four evidence records, mapped to ATT&CK techniques, and turned into an isolation proposal that stops at “Awaiting human approval”. No action is taken.

00What AISOC covers

One platform for the work between the alert and the decision.

  1. 01 Alert normalization Vendor formats into one common schema
  2. 02 Deterministic triage Rule-based FP/TP pre-classification, no model call
  3. 03 AI-assisted analysis Summary, MITRE ATT&CK mapping, risk level, verification questions
  4. 04 AI-led investigation Hypotheses, evidence collection, timeline
  5. 05 Threat intelligence Indicator reputation; internal addresses never sent out
  6. 06 Response preparation Blast radius, privilege and reversibility, then human approval
  7. 07 Decision ledger Chained record with plain-language replay
  8. 08 Reporting Plain-language reports in Turkish and English, with an attack-flow diagram
  9. 09 Detection engineering Natural language to Sigma, multi-SIEM query drafts
  10. 10 Multi-tenancy Per-tenant permissions and data isolation

01Illustrative investigation

Follow one alert all the way to a decision.

A synthetic case, step by step: what AISOC looks at, what it concludes, which record supports each conclusion — and where it stops so that a person decides.

Illustrative scenario · synthetic data Conceptual product preview — not a screenshot of the product interface

Suspicious PowerShell execution, followed by an outbound connection

Case
DEMO-0417
Host
WS-DEMO-014
User
demo.user
Source
SIEM alert
Case status

Awaiting human approval

All steps and case views are shown below. With JavaScript enabled, the case plays step by step.

  1. The SIEM alert is converted into the common schema. Host, user, process, rule and time become structured fields.

  2. Rule-based checks run before any model call. No allowlist match and no known benign pattern, so the alert goes to investigation.

  3. Asset, user and threat-intelligence context is gathered in parallel. Internal addresses are never sent to external sources.

  4. Two hypotheses are formed. Read-only queries collect evidence for and against each, and the timeline is rebuilt from the records.

  5. Each finding cites its evidence. ATT&CK mappings are checked against a fixed catalog, and a quality review runs before anything reaches the customer.

  6. Isolation is proposed with blast radius, privilege and reversibility assessed. It now waits for an authorized person. Nothing has been executed.

Step 6 of 6

Evidence

Records collected for case DEMO-0417
Ref Source Record Why it matters
A0 SIEM · rule match Suspicious PowerShell execution · WS-DEMO-014 · demo.user Trigger. Normalized into the common schema.
C1 Asset inventory WS-DEMO-014 · finance workstation · criticality: medium Sets the impact of any response.
C2 Directory demo.user · standard account · no admin rights Argues against an admin script.
C3 Threat intelligence update.example.invalid · 203.0.113.45 · no known reputation No match is recorded as unknown — not as clean.
E1 Endpoint · process creation WINWORD.EXE → powershell.exe -NoProfile -EncodedCommand […] An Office process started PowerShell with an encoded command.
E2 PowerShell · script block log Decoded script requests https://update.example.invalid/… Remote content requested from an unfamiliar domain.
E3 DNS update.example.invalid → 203.0.113.45 Resolution right after the script ran.
E4 Firewall WS-DEMO-014 → 203.0.113.45:443 · 3 sessions in 40 s Outbound connection to the resolved address.

Timeline

  1. E1 powershell.exe starts under WINWORD.EXE with an encoded command
  2. E2 Script block logged: request to update.example.invalid
  3. E3 update.example.invalid resolves to 203.0.113.45
  4. E4 First of three outbound HTTPS sessions to 203.0.113.45
  5. A0 SIEM raises “Suspicious PowerShell execution”
  6. ??:??:?? Not in the collected records How the document reached the workstation. Flagged as an open question.

Rebuilt from the evidence records. Times are synthetic.

Assessment

Verdict

Likely true positive

Confidence

High

An Office process launched encoded PowerShell that requested content from an unfamiliar domain, then opened outbound sessions to it. The sequence is consistent with a malicious document fetching a second stage.

Hypotheses
  • Supported A malicious document triggered a download E1E2E3E4
  • Not supported A legitimate administrative script C2E1
MITRE ATT&CK mapping
  • T1204.002 User Execution: Malicious File E1
  • T1059.001 Command and Scripting Interpreter: PowerShell E1E2
  • T1027 Obfuscated Files or Information E1
  • T1071.001 Application Layer Protocol: Web Protocols E3E4
Quality review
  • All four findings cite evidence
  • ATT&CK IDs validated against the catalog
  • Open question: document origin is not in the collected records
Verification question for the customer

Was demo.user expecting an invoice document from an external sender this morning?

Recommended action

Proposed step

Isolate WS-DEMO-014 from the network

Stops further outbound sessions while the host is examined. E4C1

Policy assessment
Blast radius
1 asset · internal workstation
Privileged account
No
Reversible
Yes — release from isolation
Policy result
Eligible for approval
Approval gate

Awaiting human approval

Named, authorized approver (on-call L2)

Controls shown for illustration. Nothing can be executed from this page.

Nothing has been executed. The decision and the approver will be written to the decision ledger.

Also prepared — each needs its own approval
  • Block update.example.invalid and 203.0.113.45
  • Terminate active sessions for demo.user
Report drafts
  • Turkish
  • English
  • Attack-flow diagram

Conceptual product preview — not a screenshot of the product interface

02How it works

One governed path from intake to the conversation with your team.

Every alert follows the same pipeline. Each stage hands the next a defined output, so you can always see where a conclusion came from.

  1. 01

    Alert intake

    Raw SIEM/SOAR alerts are converted into a common schema. Deterministic pre-triage filters known patterns without a model call.

    Output Normalized alert

  2. 02

    Enrichment

    Asset, user and external threat-intelligence context is gathered in parallel.

    Output Context bundle

  3. 03

    Analysis

    Hypotheses, read-only evidence queries and a timeline; classification with confidence and rationale; MITRE ATT&CK mapping.

    Output Evidence-referenced findings

  4. 04

    Quality review

    Output is checked a second time before it reaches the customer. Findings without a basis do not enter the report.

    Output Reviewed verdict

  5. 05

    Response & report

    Response steps with blast radius and reversibility, an approval gate, and a Turkish or English report with an attack-flow diagram.

    Output Action plan and report

  6. 06

    Interaction

    Your team asks follow-up questions about the case through a signed, time-limited link.

    Output Answers on the record

Across every stage

  • Organizational memory

    Customer-specific and isolated. Every case is written here; similar incidents start with past context.

  • Governance layer

    Evidence classification · approval gate · decision ledger · tenant isolation · input sanitization · quality measurement.

  • OT/ICS track

    Assesses operational safety impact in industrial environments: production continuity, physical damage and human safety. Includes industrial protocol parsing.

03Specialist areas

Specialists, organized around the decisions they support.

AISOC selects the specialist each question needs. All of them work under the same governance layer.

Establish what happened

A defensible account of the incident, with the record behind every statement.

Investigation & analysis
What happened, why is it risky, and how does it map to MITRE ATT&CK?
FP/TP triage
Real threat or false alarm — and how confident is the verdict?
Evidence
Which record, and which field, led to this conclusion?
Threat intelligence
Is this address, file or domain already known to be malicious?

Decide what to do

Response options sized to their impact, and a clear line where the AI stops.

Action advisory
What should we do now, and in which order?
OT/ICS safety
What does this mean for the production line and operational safety?
L2 escalation
Is this beyond the AI’s scope? The case file is prepared; only a person escalates.

Explain it and prevent the next one

Reports people can act on, and detections that close the gap.

Visualization
Assets → attack flow → impact, as a self-contained diagram.
Detection engineering
How do we catch this next time? A rule draft with a risk note.

A red-team agent is in development. See the roadmap under Detection engineering.

04Governance

Every decision leaves a record you can replay.

AISOC never applies a modifying action on its own. What happened, which evidence supports it, which control it passed and who approved it stay linked — and can be replayed after the fact.

Decision record · illustrative DEMO-0417

Approval chain

  1. 01 Proposal
  2. 02 Policy check
  3. 03 Approval gate
  4. 04 Execution

Policy check covers blast radius, reversibility and privilege.

  1. 01

    Evidence references

    Every statement comes with the record it is based on. A finding whose basis cannot be shown does not enter the report.

  2. 02

    Tenant isolation

    Every piece of evidence is stamped with the customer it belongs to; unstamped evidence is rejected. Permissions and data are separated per tenant.

  3. 03

    Policy controls

    Blast radius, privilege and reversibility are assessed before a step is proposed. Blocking your own infrastructure, or an irreversible action on a privileged account, is never put forward.

  4. 04

    Human approval

    Every modifying action goes to a named, authorized person and the approval is recorded. Investigation queries are read-only.

  5. 05

    Replayable decision history

    A chained decision ledger lets you replay why a decision was made, in plain language.

Supporting safeguards

  • Input sanitization

    Log fields can be written by an attacker. Every text sent to the model passes through a single gate and is sanitized.

  • Anti-fabrication checks

    An address or technique the model cites must actually have been observed. ATT&CK claims are validated against a fixed catalog.

05Deployment

Runs where your data policy says it can.

AISOC is installed on your own infrastructure. The model layer is interchangeable: a local LLM by default, or a cloud LLM where your data classification and security policies allow it. Evidence and approval controls stay the same either way.

Deployment boundary diagram. Inside your infrastructure: SIEM/SOAR feeds AISOC read-only; AISOC uses a local LLM, organizational memory and a human approver. An optional path leaves the boundary through a policy gate to a cloud LLM, carrying only policy-approved content; in offline mode the path is not used.

Default

On-premises, offline-capable

  • Installed as containers on your own hardware
  • No external connectivity required; runs in air-gapped environments
  • Local LLM: alerts and evidence are processed inside your infrastructure
  • Read-only connection to your existing tools

Optional

Cloud LLM, where policy allows

  • Used only where your data classification and security policies permit
  • Content sent to the model is processed by the provider you choose
  • That processing also falls under your agreement with the provider
  • Approval gates, evidence references and the decision ledger do not change

What happens at deployment

  1. 01

    Installation

    On your hardware, as containers. Comes up without external connectivity.

  2. 02

    Connection

    Read-only connection to your existing infrastructure. Your setup does not change.

  3. 03

    From the first alert

    Pre-filtering → investigation → evidence-backed classification → report with attack-flow diagram.

  4. 04

    Action

    Every modifying action is put to a named person, and the approver is recorded.

  5. 05

    Organizational memory

    Each case is written to customer-specific memory, so similar incidents start with context.

06Detection engineering

Write a rule once. Draft it for every SIEM you run.

Describe a behavior in plain language and AISOC drafts a Sigma rule, then translates it into queries for the SIEMs in your environment. Every draft carries a risk note and goes to an engineer for review.

Available today

  • Natural language to Sigma rule drafts
  • Query drafts for multiple SIEM query languages
  • A risk note with every draft
  • Drafts for review, never deployed automatically
Draft · Sigma · from case DEMO-0417
title: Office application starts encoded PowerShell
status: experimental
description: Draft from case DEMO-0417. Review before use.
logsource:
  category: process_creation
  product: windows
detection:
  parent:
    ParentImage|endswith:
      - '\WINWORD.EXE'
      - '\EXCEL.EXE'
  child:
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - ' -enc'
      - ' -EncodedCommand'
  condition: parent and child
falsepositives:
  - Office add-ins that start PowerShell
level: high

Query drafts for SplunkQRadarElasticMicrosoft Sentinel

Risk note Legitimate Office add-ins that start PowerShell will match. Review exclusions before enabling.

07Questions

What security teams ask first.

01 Does AISOC replace our SIEM or SOAR?

No. AISOC works on the alerts your SIEM/SOAR already produces. It converts them into a common schema and connects read-only to your existing infrastructure for investigation, so your setup stays as it is. Sources and connection methods are confirmed for your environment during scoping.

02 Can AISOC take action on its own?

No modifying action is applied on its own. AISOC prepares response steps — isolating a host, disabling an account, terminating sessions, resetting a password, blocking an indicator or quarantining a file — assesses blast radius, privilege and reversibility, and submits each one to a named, authorized person. The approval is recorded.

03 Does our data go to the cloud?

Not in an on-premises deployment: the whole system, including the model, runs inside your infrastructure. A cloud LLM is used only where your data classification and security policies permit; in that case, content sent to the model is processed by the provider you choose. Threat-intelligence lookups never send internal addresses out.

04 Can it run fully offline?

Yes. AISOC is installed as containers on your own hardware, needs no external connectivity and can run in air-gapped environments.

05 In which languages are reports produced?

Case reports are produced in Turkish and English, in plain language, and each includes an attack-flow diagram. Other report languages are not part of the current scope.

06 Does it cover OT/ICS environments?

Yes, through a dedicated OT/ICS track that assesses an incident’s operational safety impact: production continuity, physical damage and human safety. The track includes industrial protocol parsing, and an OT/ICS safety specialist assesses what an incident means for the production line.

07 How are AI errors kept in check?

Each statement cites the record it rests on, and findings without a basis stay out of the report. Addresses and techniques the model cites must actually have been observed, and ATT&CK claims are validated against a fixed catalog. A quality review runs before output reaches you, and every modifying action still needs human approval. No AI system is error-free; AISOC is built so that errors are visible and reviewable.

08Request a demo

See an investigation end to end.

Tell us about your SOC environment. We will walk you through an investigation and the deployment option that fits your data policies.

What the demo covers

  1. 01 A full investigation, from alert to approval gate
  2. 02 On-premises and cloud LLM options against your data policy
  3. 03 How AISOC connects to your SIEM/SOAR