The AI-Assisted Security Operations Centre

The security operations centre (SOC) is where an organisation finds out that something is wrong, and where most organisations first put AI to work in cyber defence, because alerts arrive faster than people can read them and the few that matter look much like the many that do not. AI that reads, summarises and correlates promises to give analysts back their time. However, it brings new risk into the one function that must not be misled, because much of what a SOC reads is written by the adversary.

This chapter follows the AI-assisted SOC from intake to closure, including investigation agents, the monitoring of AI systems, analysts' command and work with a managed security service provider (MSSP). In NIST CSF 2.0 terms the chapter is responsible for two Categories of the Detect Function: DE.CM Continuous Monitoring, in which assets are monitored to find anomalies, indicators of compromise and other potentially adverse events, and DE.AE Adverse Event Analysis, in which those events are analysed to characterise them and detect cybersecurity incidents (19, NIST, 2024). Chapter 19 treats what feeds the SOC.

SOC workflow from intake to closure with the mode and level of each AI step and the injection channel

Figure 18.1: SOC workflow from intake to closure with the mode and level of each AI step and the injection channel.

Why the SOC needs AI, and why it must be careful

Architecture as Code (Chapter 9B) concluded that manual incident response cannot scale when attacks develop within minutes, and that mean time to detect (MTTD), mean time to respond (MTTR) and the false-positive ratio are the metrics by which a security programme is judged (71, Nordqvist, 2025). This chapter takes them as its yardstick: AI in the SOC is justified when it moves them in the right direction without degrading the quality of decisions.

Mandiant's M-Trends 2026 reports that global median dwell time rose from 11 to 14 days, that organisations detected malicious activity internally first in 52 per cent of its 2025 investigations, and that the estimated mean time to exploit a vulnerability has fallen below zero, so that exploitation routinely begins before a patch exists (45, Mandiant, 2026). It urges defenders to treat routine malware alerts as indicators of an impending secondary intrusion.

AI Platform and Security, Chapter 18, committed to detection at machine speed, with the authority to act, and to AI for defence under oversight, where human verification is the bottleneck (73, Nordqvist, 2026). This chapter's answer is a SOC in which AI reads and drafts, deterministic controls decide what an AI may do, and people decide what matters, with authority to act at machine speed delegated in advance for a few reversible actions.

The caution comes from the input: alert titles, email subjects, file names and command lines are fields an adversary can influence, and prompt injection is a property of the architecture rather than a patchable defect (AI Platform and Security, Chapter 16) (73, Nordqvist, 2026); OWASP likewise notes that prompt injection vulnerabilities are possible due to the nature of generative AI and that it is unclear whether fool-proof methods of prevention exist (14, OWASP, 2025). OWASP ranks prompt injection first among LLM risks (14, OWASP, 2025), MITRE ATLAS catalogues it as an adversary technique (11, MITRE, n.d.), and the Five Eyes agencies' guidance on agentic AI describes malicious instructions in emails steering an email-monitoring agent (40, Five Eyes agencies, 2026). Every AI component that reads alert content therefore reads attacker-controlled data.

The SOC workflow, step by step

Taking the workflow apart lets AI be placed and measured step by step rather than bought as a single "AI SOC" product. Intake turns telemetry, including from AI gateways, into alerts. This is DE.CM: networks, personnel activity and technology usage, external service provider activities, and computing hardware, software and runtime environments are monitored (19, NIST, 2024). Much AI at intake is Mode 0 Ambient AI, vendor verdicts that some products already act on. Triage decides what each alert is; enrichment adds context, as DE.AE asks; investigation correlates and scopes; escalation declares an incident and hands it to Chapter 20; closure records the outcome and feeds lessons to Chapter 19.

Step Where AI adds value Where AI adds risk Starting autonomy level
Intake Deduplication, clustering, noise suppression Vendor verdicts that suppress or act unseen Vendor-configured; must be made visible
Triage Classification and prioritisation around the clock Injection through alert content; confident misclassification Level 1 Assisted
Enrichment Context in seconds Context from the wrong asset or a stale inventory Level 1 Assisted
Investigation Correlation, timelines, hypotheses Tool misuse, scope creep, ungrounded narratives Level 2 Supervised
Escalation Drafted incident summaries An alert reaching someone without authority to act Level 0 Advisory
Closure Drafted case notes and tuning proposals Closing a case on an unverified summary Level 1 Assisted

Escalation deserves particular care: AI Governance, Chapter 19, concluded that the July 2026 OpenAI–Hugging Face incident (64, OpenAI, 2026) failed partly because an alert reached people who did not hold the stop decision (72, Nordqvist, 2026). OpenAI's report records that, after a monitoring alert on 27 June, on-call response staff advised that stopping the evaluation run was not required (64, OpenAI, 2026).

Triage and enrichment with AI

Grounding in telemetry and asset context

A verdict in prose is a liability, because the analyst cannot tell whether it rests on telemetry, general knowledge or planted text. The service should therefore retrieve context through read-only queries and produce a structured result in which every claim cites its evidence, as the Five Eyes guidance recommends (40, Five Eyes agencies, 2026). Alert fields are passed as untrusted data and screened at the gateway (Chapter 16); statements without references are rejected; verdicts come from a fixed set, so that agreement can be measured; and the service records what it could not establish, because "no EDR telemetry for this host in 24 hours" is often the most important line: a DE.CM finding about a monitoring gap.

Worked example: a grounded triage record

The illustrative record below is produced by Nordvik Region's triage assistant NR-SEC-001 for an unusual sign-in to a caseworker's account.

{
  "record": "NR-SEC-001/triage/2027-03-14/000412",
  "alert": "SIEM-NR-88213",
  "detection": "IdP sign-in from new country with legacy protocol",
  "verdict": "investigate",
  "priority": "high",
  "statements": [
    {"text": "Sign-in used a legacy protocol blocked by policy since 2026-11",
     "evidence": ["idp:signin/7f31c2", "policy:CA-014"]},
    {"text": "No successful sign-in from this country in 90 days",
     "evidence": ["siem:query/q-2291"]},
    {"text": "Mailbox rule created four minutes after sign-in",
     "evidence": ["m365:audit/ae-55102"]}
  ],
  "not_established": [
    "Endpoint telemetry for the caseworker's laptop: no events in 26 hours"
  ],
  "model": {"id": "nr-hosted/open-weight-a", "prompt": "soc-triage/v3"},
  "autonomy_level": 1,
  "analyst_decision": null
}

At Level 1 Assisted nothing is escalated or closed until a person fills in analyst_decision.

Correlation and enrichment at scale

Enrichment reads sources the organisation controls, such as the asset inventory of Chapter 9, and cites their age, because its risk is quiet error. Correlation saves the most detection time, because twelve low-severity alerts on one host reveal a pattern no single alert does; it is the practical answer to Mandiant's warning about routine alerts (45, Mandiant, 2026).

Investigation agents

From assistant to agent

An investigation agent is a Mode 5 Autonomous production agent with its own identity and permissions. AI Governance, Chapters 19 and 25, concluded that such an agent is governed as a well-meaning insider, because instructions lower the rate of unwanted behaviour but only boundaries set a ceiling on its consequences (72, Nordqvist, 2026). In the SOC it reads the most hostile content and may hold powerful permissions, so it is also an attractive target.

AI Platform and Security, Chapters 11 and 19, expressed containment that holds whatever anyone intends in a permission manifest, a version-controlled declaration of identity, tools, scopes, limits and stop path, enforced by a policy decision point outside the model (73, Nordqvist, 2026). The Five Eyes guidance agrees: least privilege, an allow list of tools, no self-modification of privileges, no write access to logs, fail-safe defaults that stop and escalate, and graduated autonomy (40, Five Eyes agencies, 2026).

Tools and permissions

Read tools query the SIEM, EDR, inventory and intelligence, and their results are themselves untrusted content. Proposal tools write hypotheses and proposed actions to the case. Action tools isolate hosts, revoke sessions or block indicators, each listed in the manifest with its own level, scope and reversal. At Level 2 Supervised a person approves each action; at Level 3 Bounded the agent executes pre-approved, reversible actions within a codified playbook while a person is informed and can stop it (autonomy levels). Level 4 Autonomous is not used in the SOC.

When an agent may act without per-action approval

AI Platform and Security, Chapter 18, and AI Governance, Chapter 13, left open when a defensive AI may act without per-action approval, and who decides (73, Nordqvist, 2026). This book's answer for the SOC has five conditions, all of which must hold:

  1. The action is reversible, with a tested reversal: isolating a workstation is, reimaging a server is not.
  2. The signal is high-confidence by a deterministic definition, such as a reviewed detection corroborated by an independent source, or a honeytoken (Chapter 19); the model's own confidence is not a criterion.
  3. The blast radius is bounded: one target per action, a maximum rate, and excluded roles such as domain controllers.
  4. A person is informed at once and holds a stop path outside the agent, and the action is recorded in a trail the agent cannot alter.
  5. The forum that owns the risk grants the authority in a decision record and revisits it when evidence changes, following the risk-tiered decisions of AI Governance, Chapter 13 (72, Nordqvist, 2026).

Who decides is therefore a named forum, on evidence, for a named list of actions. The platform, not the agent, records every tool call, approval with its latency, action and reversal in a store the agent cannot write to (40, Five Eyes agencies, 2026).

Worked example: permission manifest for the SOC investigation agent HM-SEC-001

The illustrative manifest below is Hansa Mutual's. AIDR-0311 refers to it when it moves two reversible actions from Level 2 Supervised to Level 3 Bounded, and the group platform gateway in Frankfurt enforces it outside the agent.

# Illustrative: Hansa Mutual, permission manifest for HM-SEC-001
kind: AgentPermissionManifest
id: HM-SEC-001
version: 2.1.0
decisionRecord: AIDR-0311
usageMode: 5
identity:
  type: workload-identity
  tokenLifetimeMinutes: 15
  tokenCarriesEntity: true        # acts on behalf of one entity per case
  mayModifyOwnPrivileges: false
inputs: {alertFieldsTrusted: false, injectionScreening: gateway}
egress: default-deny
tools:
  read: [siem.search, edr.process-tree, cmdb.lookup, idp.user-context, ti.lookup]
  propose: [case.add-hypothesis, case.propose-action]
  act:
    - name: edr.isolate-host
      level: 3
      scope: {assetClass: managed-workstation}
      excludedRoles: [server, domain-controller, payment-gateway]
      reversal: edr.release-host
    - name: idp.revoke-sessions
      level: 3
      scope: {accountClass: standard-user}
      excludedRoles: [break-glass, privileged-admin]
    - {name: idp.disable-account, level: 2}
    - {name: fw.block-indicator, level: 2}
level3Conditions:
  signal: reviewed-detection-tier-1-and-independent-corroboration
  modelSelfReportedConfidence: ignored
  maxActionsPerHour: 10
  maxTargetsPerAction: 1
  requiresEntityRolloutGate: true # works-council agreement where required
notify: {role: soc-shift-lead, withinSeconds: 60}
stopPath: {holder: soc-shift-lead, mechanism: out-of-band-credential-revocation}
evidence: {writer: platform, store: evidence/soc/HM-SEC-001/, recordApprovalLatency: true}

Level 3 actions are limited to classes where a mistake costs an employee minutes rather than a business process.

Monitoring AI systems

What to collect from gateways and agents

The gateway through which every model and tool call passes (AI Platform and Security, Chapters 4 and 12) (73, Nordqvist, 2026) is the best sensor the organisation has for its AI. From it the SOC collects calling identity, model and prompt versions, policy decisions, injection-screening results and outbound destinations; from agent platforms it collects tool calls, approvals, stop-path events and privilege changes. The Five Eyes guidance adds that operators should flag discrepancies between stated intentions and observed behaviour, and cross-check agent reports against independent system logs (40, Five Eyes agencies, 2026). What an agent says it did is a claim; what the gateway and target systems recorded is evidence.

Event logs under AI Act Article 12

Article 12 of Regulation (EU) 2024/1689 requires high-risk AI systems to technically allow the automatic recording of events over their lifetime, and Article 26 requires deployers to keep the logs under their control for a period appropriate to the intended purpose, of at least six months unless other law provides otherwise (1, European Union, 2024). The architectural implication is that these traceability logs are also security telemetry for the SOC's pipeline, as for Nordvik's benefits-triage system and Hansa's underwriting-support model. Security AI is usually not high-risk under the Act, yet it is monitored to the same standard because of its permissions.

Detections for AI systems

The detections that matter most are concrete: a tool call outside the manifest, egress to an unlisted destination, a privilege change outside the change process, a rise in injection-screening hits, an unregistered model version, and a mismatch between an agent's reported actions and target systems' logs (Chapter 19). If HM-SEC-001 behaves unexpectedly, the alert must not depend on HM-SEC-001: its telemetry goes to a store it cannot write to, detection engineering owns the detections watching it, and alerts go to the shift lead who holds its stop path. No AI component in the SOC triages alerts about itself.

Analysts in command

Verification and approval quality

AI Governance, Chapters 10 and 21, concluded that human oversight must be designed, not declared: an interruption path, an override log and the authority to use them (72, Nordqvist, 2026). In the SOC the analyst opens the evidence behind the decisive statements and confirms or rejects with a reason. Because human verification is the bottleneck (73, Nordqvist, 2026), every escalation and proposed action is verified, and a sample of AI-closed benign alerts is reviewed each shift.

AI Governance also observed that approvals given in seconds signal rubber-stamping (72, Nordqvist, 2026). An approval in under ten seconds for evidence that takes a minute to read is not oversight, and neither is an approval rate near one hundred per cent for months, so the SOC reviews the approval-latency distribution. The outcome may be to move a class of action to Level 3 Bounded openly or to slow the queue, never to keep a Level 2 control that has silently become Level 3. Results are findings about controls and staffing, never scores for individuals.

Skill retention and measuring the effect

A SOC in which AI drafts every verdict risks losing the skill to verify, so a share of alerts is worked without AI on a rota, and exercises (Chapter 26) include an unavailable or wrong AI. The SOC also records a baseline for MTTD, MTTR, the false-positive ratio, analyst time and escalation accuracy, and afterwards tracks them alongside AI–analyst agreement and AI-closed alerts later found to be true positives. A component that saves analyst time but misses more true positives has made the SOC faster and worse. Chapter 26 brings these measures into the programme's metrics.

Practical guide: introducing an AI triage assistant at Level 1 Assisted

Purpose. Introduce an assistant that drafts a grounded verdict for every alert while analysts confirm or reject each one.

Roles. CISO (holds the decision to change the autonomy level), SOC lead, a named owner of the service identity, the data protection officer, analysts, and the MSSP where it shares the queue.

Steps.

  1. Record mode, level, hosting, readable data and the conditions for changing the level in an AI Decision Record (for Nordvik, AIDR-0301).
  2. Measure a four-week baseline for MTTD, MTTR, false-positive ratio, analyst time per alert and escalation accuracy.
  3. Give the assistant a read-only service identity and read tools only.
  4. Route every model call through the AI gateway, pass alert fields as untrusted data and enable injection screening.
  5. Require grounded output against a schema, and reject outputs that do not meet it.
  6. Run in shadow for two weeks and compare the drafts with analysts' own triage.
  7. Go live at Level 1 Assisted: nothing is escalated or closed without an analyst's decision and reason.
  8. Feed the assistant's gateway logs into the SIEM, with detections for out-of-scope queries and injection hits.
  9. Keep one alert in five per analyst per shift triaged without the assistant, and review agreement, missed true positives and analyst time monthly against the baseline.

Default values to adapt. Four weeks of baseline, two of shadow running, one alert in five unassisted; a SOC handling special-category data keeps the data protection officer in the shadow review. The guardrail policy in Chapter 16 codifies these boundaries.

Definition of done. The assistant runs at Level 1 Assisted with a decision record and grounded output, its telemetry is monitored, and results are reported monthly against the baseline.

Working with an MSSP

DE.CM includes monitoring external service provider activities, and an organisation that contracts an MSSP stays accountable for its own detection (19, NIST, 2024). NIS 2 Article 21 lists supply-chain security, including the security aspects of relationships with direct suppliers and service providers, among the required risk-management measures (3, European Union, 2022), and for financial entities DORA's ICT third-party risk rules apply to the MSSP as to any ICT service provider (2, European Union, 2022). The MSSP's AI is therefore part of the organisation's supply chain and must be visible to it.

When both parties use AI, the contract answers four questions: whose AI sees which data and where it is processed; whose verdict counts when tooling disagrees (normally the MSSP analyst, with the disagreement recorded); which actions the MSSP and its AI may take at which autonomy level; and which evidence is shared, including which steps AI drafted or executed.

The Five Eyes guidance advises never granting agentic AI broad or unrestricted access to sensitive data or critical systems, and aligning agentic AI risk with the organisation's existing security model (40, Five Eyes agencies, 2026); applied to an MSSP, the customer's security model governs the provider's AI on the customer's estate. Because public procurement moves slowly, start by making a register of the MSSP's AI services a deliverable at renewal, and make sure whoever receives an out-of-hours escalation holds the authority to act on it.

The SOC across modes, levels and focus areas

Across the usage modes

The SOC uses every usage mode at once, each needing its own verification (usage modes).

Mode Opportunity in the SOC Characteristic vulnerability Who judges, with whose identity
Mode 0 Ambient AI Vendor verdicts in endpoint and email protection Verdicts that act unseen; unchosen model changes The vendor's model; the product's identity
Mode 1 Conversational assistants Explaining a command line or technique Alert content pasted outside SOC telemetry The analyst; the analyst's
Mode 2 Embedded workplace assistants Summaries in SIEM, SOAR and ticketing Omitted decisive detail; injection through ticket text The analyst; delegated access
Mode 3 Agentic work tools Engineers build queries, parsers and playbooks An agent touching SOC tooling before review The engineer at review; the engineer's
Mode 4 Built AI applications Grounded verdicts for every alert Injection through alert fields; ungrounded verdicts The analyst at Level 1; a read-only service identity
Mode 5 Autonomous production agents Correlation, proposals and bounded action A well-meaning insider steerable by crafted alerts The analyst at Level 2, the decision record at Level 3; the agent's workload identity

Across the autonomy levels

Level Use in the SOC
Level 0 Advisory AI suggests classifications or incident criteria; default for escalation
Level 1 Assisted AI drafts the verdict or case note; default for triage and closure
Level 2 Supervised AI executes containment after an analyst approves it; default for investigation agents
Level 3 Bounded AI executes pre-approved, reversible containment on high-confidence signals; the shift lead holds the stop path
Level 4 Autonomous Not used in the SOC

Verifying with security chaos engineering

Detection is where silent failure is most common, so the SOC is verified continuously (Chapter 25). The first experiment injects silence: a log forwarder for one host stops for 35 to 45 minutes, and the hypothesis is that a "log source silent" alert reaches the queue within 30 minutes, is triaged within a further 30, and that the triage record names the gap.

The second injects a catalogued, benign emulation of the observable artefacts of an attacker technique on a managed test workstation, mapped to MITRE ATT&CK (10, MITRE, n.d.). The hypothesis is that an alert is raised within five minutes, the AI verdict is "investigate" or higher with grounded statements, and an analyst has the case within fifteen minutes. For an agent at Level 3 Bounded, a variant verifies that the shift lead is notified within 60 seconds and the stop path halts the agent.

The three AI focus areas

The NIST Cyber AI Profile treats each Category through three focus areas (20, NIST, 2025).

Securing AI systems. The SOC monitors AI systems through gateway logs, agent telemetry and AI Act Article 12 event logs, and its own security AI is watched by components it cannot influence.

AI-enabled cyber defence. AI triages, enriches and investigates with grounded conclusions, and its effect is measured against a baseline.

Thwarting AI-enabled attacks. The SOC detects at machine speed and holds, in advance, the authority to act on high-confidence signals with reversible actions at Level 3 Bounded. It treats alert content as a channel for steering its own AI, and red teams that channel continuously.

Nordvik Region and Hansa Mutual

Nordvik Region runs NR-SEC-001 as a Mode 4 service at Level 1 Assisted on reserved capacity, because alert data contains personal and health data that it will not send to an external model. In office hours its six analysts confirm or reject each grounded summary, and only the CISO may change the level (AIDR-0301). Out of hours the MSSP works the queue under framework agreement NR-2025-044, with its own AI tooling disclosed and logged inside the EU/EEA.

Hansa Mutual's SOC in Hamburg and at the Polish service centre uses every mode, up to the Mode 5 agent HM-SEC-001, for which AIDR-0311 moves two reversible actions to Level 3 Bounded under ceilings set by the group AI governance board. Red-team campaigns under HM-SEC-003 test whether crafted alert content can steer the agent, and the works councils in Germany, the Netherlands and Sweden were consulted before the agent could act on telemetry affecting their staff. Nordvik thus uses AI to stretch six analysts without letting security data leave its control; Hansa uses it to act at machine speed while showing that people remain in command.

Summary

Under DE.CM Continuous Monitoring and DE.AE Adverse Event Analysis, AI adds most value in reading and assembling and most risk in deciding and acting, so every conclusion must be grounded in evidence the analyst can inspect.

Investigation agents are governed as well-meaning insiders through a permission manifest enforced outside the model, and authority to act without per-action approval covers only reversible actions on deterministically defined high-confidence signals, with a person holding the stop path and a decision recorded by the forum that owns the risk.

The SOC also monitors AI systems, its own included, and treats alert content as an injection channel for every mode. Analysts stay in command only if verification is designed and approval quality, skills and effect are measured, and an outsourced SOC needs the same rules in its contract. Chapter 19 turns to what feeds the SOC: detections as code, threat intelligence and deception.

Sources

  1. NIST. The NIST Cybersecurity Framework (CSF) 2.0. (19, NIST, 2024)
  2. National Institute of Standards and Technology. Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile). (20, NIST, 2025)
  3. Nordqvist, G. Architecture as Code. (71, Nordqvist, 2025)
  4. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (72, Nordqvist, 2026)
  5. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (73, Nordqvist, 2026)
  6. Five Eyes cyber security agencies: ASD's ACSC, CISA, NSA, Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK. Careful adoption of agentic AI services. (40, Five Eyes agencies, 2026)
  7. Mandiant. M-Trends 2026: Data, Insights, and Strategies From the Frontlines. (45, Mandiant, 2026)
  8. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (1, European Union, 2024)
  9. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (2, European Union, 2022)
  10. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). (3, European Union, 2022)
  11. MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (10, MITRE, n.d.)
  12. MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for AI Systems. (11, MITRE, n.d.)
  13. OWASP Foundation. OWASP Top 10 for Large Language Model Applications, 2025 edition. (14, OWASP, 2025)
  14. OpenAI. OpenAI – Hugging Face Incident Technical Report. (64, OpenAI, 2026)