The Analyst's Own Use of AI: Querying, Drafting and Summarising in Modes 1 to 3

Before the blue team conducts a team of agents, each analyst already works beside an assistant. This chapter describes that personal use: the queries, drafts and summaries that analysts produce with conversational assistants (Mode 1), assistants embedded in the tools they already use (Mode 2) and agentic work tools (Mode 3), and the discipline needed when the data in front of the analyst is alert content, personal data and evidence. It concerns all five functions: B1 Anticipate (reading and summarising intelligence), B2 Detect (drafting queries and detection logic), B3 Investigate (summarising tickets and building timelines), B4 Respond (drafting communications and updates) and B5 Learn (writing reviews). It covers classification and routing, what must not leave the organisation, the record of AI use in a case, the line between assistance and delegation, shadow AI and the works-council dimension of logging an analyst's own tools. It does not repeat the risk analysis of security for AI systems in AI Platform and Security, Chapter 16; it applies that analysis to the work of the security operations centre (SOC).

An analyst's tools by mode and data class, with the routing and logging that apply

Figure 12.1: An analyst's tools by mode and data class, with the routing and logging that apply.

Starting points from the earlier volumes

Four conclusions of the earlier volumes frame the chapter. First, the usage mode, not the brand of the tool, sets the governance (AI Governance, Chapters 2 and 25) (62, Nordqvist, 2026): in Modes 1 to 3 the AI acts with the analyst's own identity and permissions, which is why this chapter is about the analyst's discipline rather than about an agent's mandate (AI Red Team, Chapter 6) (64, Nordqvist, 2026). Second, natural language is an instruction channel that the model cannot police, so what the assistant reads can steer it (AI Platform and Security, Chapter 16) (63, Nordqvist, 2026). Third, vendor AI in security products may act or process data at a level nobody decided, the Mode 0 blind spot (AI Red Team, Chapter 8). Fourth, the rule "agents draft; humans approve" (Architecture as Code (Chapter 20)) (61, Nordqvist, 2025) holds for the individual analyst as much as for an agent team: the analyst remains the accountable author of whatever enters a case, a detection or a message.

A day with an assistant

An analyst's use of AI is not one activity. It is a dozen small ones spread across the five functions, and the risk differs for each. Consider a shift at the Polish service centre. The analyst asks an assistant to summarise a threat report that arrived overnight (B1). A colleague asks it to turn a hypothesis into a query for the group SIEM (B2). During an investigation the analyst pastes a ticket history and asks for a timeline (B3). Later the analyst drafts an update for the duty manager and a notice for the affected business unit (B4). At the end of the week the analyst asks for a first draft of a post-incident review (B5).

Activity Function Typical mode Data usually involved Characteristic failure
Summarise a threat report or advisory B1 1 Public or internal Omission of the one detail that mattered
Draft or translate a query for the SIEM B2 1 or 3 Internal; schema names A query that runs, returns less than it should and reads as "nothing found"
Explain an unfamiliar log field or command line B2, B3 1 Internal; fragments of alert content A confident explanation that is wrong for this product version
Summarise a ticket or case history B3 1 or 2 Restricted; personal data likely Dropped or invented facts in the summary
Draft an incident update or stakeholder notice B4 1 Restricted until cleared Fluent text that states something not yet verified
Draft a post-incident review B5 1 Restricted A smooth narrative that hides the contested decision

Two failure modes recur. The first is fabricated or distorted content, which NIST names confabulation in its generative AI profile, alongside data privacy and information security as risk categories (15, NIST, 2024); this book uses the more familiar word hallucination for the same behaviour, text that reads as fact and is not grounded in the input. The second is the silent query: because an assistant writes queries fluently, a wrong one looks as authoritative as a right one, and an empty result is read as absence of evidence. Neither failure is exotic. Both are why the analyst's own use of AI needs rules that sit outside the analyst's attention on a busy night, and why the safe route must also be the easy one.

Classification and routing

Which data may go to which model is a question about the data first and the model second. The routing rule of this chapter has three parts: classify the data, restrict the routes by class, and enforce the restriction in the tooling rather than in the analyst's memory.

Classify. Both organisations already use a small set of data classes. This chapter uses four: public, internal, confidential and restricted. Restricted covers personal data, special-category data (the Region's social-care and health context), customer and policyholder information, case content, forensic evidence and anything the incident commander has marked as under embargo. Alert content is restricted by default, because an alert is a copy of a log line and a log line names people, devices, addresses and, often, subjects of correspondence. Under the GDPR, personal data must be adequate, relevant and limited to what is necessary (Article 5(1)(c)) and must be processed with appropriate security (Article 32) (8, European Union, 2016). The architectural implication is that the question "does this prompt need the raw log line at all?" is a design question for the tool, not a courtesy asked of the analyst.

Restrict by route. A route is a pairing of a tool, a mode and a hosting arrangement. The policy states, per data class, which routes are allowed and the highest degree of delegation permitted on each. For Modes 1 to 3 the ceiling is low by design: the analyst reads every output and carries every action, so drafting and summarising are Level 1 Assisted, and running a read-only query that the analyst has reviewed is at most Level 2 Supervised. Anything above that is delegation and leaves this chapter for Chapter 13.

Enforce in the tooling. AI Platform and Security, Chapter 15, designed the classification-routed hybrid set-up in which sensitive information is handled only by self-hosted models. The SOC applies it with two additions. The case tool and the SIEM carry the class of the record the analyst is working on, and the "ask the assistant" action offers only the routes that class permits, through the AI gateway of the reference architecture. And a pre-processing step replaces direct identifiers in a pasted fragment with stable tokens before restricted data reaches any route, including the self-hosted ones, so that retained prompts hold tokens and not names and the analyst can still ask "what does this sequence of events by USER_07 on HOST_12 suggest?" without exposing names. The mapping from tokens back to identifiers stays in the case tool.

Embedded assistants in Mode 2 deserve a separate line in the policy. A summarise button inside the SIEM or the endpoint console sends the data to the vendor's model with one click, and the analyst may not know where it is processed or whether it is retained. Treat such an assistant as a route like any other, and allow it for restricted data only where the contract states the processing location, the retention and the absence of training on the customer's data. Under NIS 2, the security of the supply chain is among the measures that essential and important entities must take (Article 21) (3, European Union, 2022), and a vendor-embedded assistant in a security product is a supplier relationship. The Mode 0 blind spot applies here too: the contract must also say what the vendor's own AI does with the Region's or the group's alerts without any button being pressed.

Cross-border telemetry sharpens the rule. Hansa Mutual's group SOC reads alerts from seven legal regimes, and the UK and Swiss entities' telemetry reaches Hamburg and the Polish service centre under transfer arrangements that the group's market overlays already encode. The routing policy reads the same overlays: restricted data from a market is offered only to routes in hansa-dc-frankfurt and never to a vendor tier outside the arrangement that covers that market. Nordvik has one jurisdiction and a different constraint, sovereignty over security data, which in practice means the same outcome: alert data goes only to models on capacity the Region controls.

What not to paste

Some content does not go to any assistant, whatever the route, because the harm of disclosure does not depend on where the model runs. The list is short enough to print on the acceptable-use sheet below.

  • Credentials and secrets. Passwords, API keys, tokens, session cookies and private keys, including those found inside evidence. A credential discovered in a log is a finding to report and rotate, not a string to explain to an assistant.
  • Live malware and exploit material. Paste indicators, hashes and behavioural descriptions. Samples belong in the analysis sandbox under the team's handling rules.
  • Customer, policyholder, resident and caseworker information outside the approved self-hosted routes: names, national identification numbers, health and social-care details, claims content.
  • Case content under embargo or legal hold, and anything that names the unreleased details of an incident whose reporting clock is running (NIS 2 Article 23 sets the early warning and notification deadlines for significant incidents; the SOC lead decides what may be shared before notification).
  • Staff information. Evidence about a colleague's conduct belongs in the case, handled under the rules for investigating people (Chapter 8).
  • Details of the organisation's own defences to routes it does not control: detection logic that is not yet deployed, the list of blind spots and the contents of the stop path.

Data minimisation turns the list into a habit. State the question before pasting, and paste the smallest fragment that answers it: the five lines around the anomaly, not the thousand around them; the field names and the types, not the values; the technique and the observed behaviour, not the host list. Where the question is about syntax or about a general technique, such as how a SIEM query language handles a join or what a given ATT&CK technique usually leaves in logs (9, MITRE, n.d.), no organisational data is needed at all, and the public route suffices.

Hostile content needs one more rule. The text an analyst pastes may have been written by an adversary: a phishing email, a command line, a ticket field. The OWASP list for large language model applications names prompt injection and excessive agency among its top risks (13, OWASP, 2025). In Mode 1 the assistant has no tools, so the consequence of a hostile fragment is a misleading summary; in Mode 3 the assistant can act with the analyst's permissions, and the same fragment can steer a command. The policy therefore keeps untrusted content out of any route that can run commands, unless a policy decision point outside the model limits what the tool can do. Chapter 15 treats this as the architectural problem it is; here it sets a rule for the analyst's own tools: read hostile content in Mode 1, never in Mode 3 with write permissions.

Recording use

The analyst's use of AI is recorded for three reasons. A case must show who or what reached each conclusion, which is the definition of a case record (Chapters 7 and 8). The regulators and the board need evidence that the policy operates. And the analyst needs protection: a record that shows the routing rule was followed is the best defence when a result is questioned afterwards.

The record is small. It is a pointer in the case record, not a transcript. Each entry says which step used an assistant, by which route and mode, for which class of data and what purpose, how the output was used (discarded, used_as_lead, edited or used_as_drafted), and what the analyst checked it against. The text of the prompt is not stored in the case record. Where the route is self-hosted, the platform keeps the prompt and the output for a short period for incident reconstruction and abuse review, and the retention is stated in the policy; on vendor routes the contract sets the retention and the policy requires it to be as short as the vendor offers.

case: CASE-HM-1318
ai_use:
  - step: timeline-draft
    route: frankfurt_assistant
    mode: 1
    data_class: restricted
    purpose: summarise-ticket-history
    output_used: edited
    checked_against: [siem-export-1318-a, edr-timeline-1318]
    analyst: shift-analyst-pl-04
  - step: query-draft
    route: frankfurt_work_tool
    mode: 3
    data_class: restricted
    purpose: draft-read-only-query
    output_used: used_as_drafted
    checked_against: [query-run-log-1318]
    analyst: shift-analyst-pl-04

The tool writes the entries where it can, since the case tool already knows the route, mode and class; the analyst adds only the purpose, the use and the check. The log serves the case, the sampled audit and the post-incident review. Whether it may also describe an analyst's behaviour is a question for the works council, taken up below.

Assistance versus delegation

The distinction between assistance and delegation is the one that keeps Modes 1 to 3 inside this chapter. Assistance means that the analyst decides what is asked, reads the output in full, owns the result and takes every action. Delegation means that a system takes an action, or closes a question, on a standing authority that a named person gave it, under a mandate. The degrees are the series' autonomy levels applied to the blue team's functions: an assistant that drafts is Level 1 Assisted; a tool that proposes an action the analyst then executes is Level 2 Supervised. Level 3 Bounded requires a codified playbook enforced by a policy decision point outside the model, and an identity of the tool's own (AI Red Team, Chapter 6). A tool in Modes 1 to 3 never holds that standing authority. If it did, it would be a Mode 5 agent by another name and would need a mandate manifest.

In practice the line blurs in four places, and the policy names each.

  1. Output used without being read. A summary pasted into a case without the analyst having read the source is no longer assistance. The log entry "used as drafted" is acceptable only with a recorded check.
  2. Output written to a system. A Mode 3 tool that writes to the case tool, the ticketing system or the SIEM does so with the analyst's identity. Writing a draft to the analyst's own workspace is assistance; writing a closure, a severity change or a detection into a shared system is an action, and falls under the closure policy of Chapter 7 or the detection pipeline of Chapter 6.
  3. State-changing commands. A Mode 3 tool that runs read-only queries is within the policy. One that runs a command that changes an endpoint, an account or a firewall is performing B4 Respond and falls under the playbook manifests of Chapter 10.
  4. Habit. An assistant that is right ninety-nine times in a hundred trains its user not to check. Chapter 14 sets out the evidence on automation bias and builds the response, seeded errors and an oversight-quality metric, and Chapter 23 treats unassisted practice as part of the analyst's craft. For this chapter the rule is modest: a share of each analyst's routine work stays unassisted, and the policy sets the share.

When the practical difference matters, the test is the question "who decided this, and could that person have stated why?" If the answer is the analyst, it is assistance. If the answer is the tool, someone must have delegated that decision to it, and the delegation profile (DLG-*) must say so. Both organisations' policies put the test on one line: no Mode 1 to 3 output is an input to a closure, a containment or a notification unless a named analyst has checked it against a primary source.

Shadow AI in security

Shadow AI is the use of AI tools that the organisation has not approved or does not know about. Security teams are not exempt from it. A team that handles the most sensitive data in the organisation is also a team with a high-stakes, repetitive workload and a strong wish for help, and an analyst who pastes a log into a personal account of a public assistant at three in the morning exposes exactly the content this chapter protects. I have no survey of its prevalence in SOCs that I can cite, so I make no claim about how common it is; the argument is architectural and is the book's own conclusion.

Analysts reach for unapproved tools for reasons that the approved tool can remove. The approved assistant is slow, or refuses anything that looks like a security question because its guardrails treat malicious-looking content as malicious. It does not know the organisation's SIEM schema, so the queries it drafts need rewriting. It sits in a separate window, away from the case. It was approved for the whole organisation and cannot see alert content, so it is useless for the one task where the analyst wants help. Each of these is a design failure with a design remedy.

  1. Make the approved route the best one for security work. Provide a self-hosted assistant with the SIEM schema and the detection records as retrieval context, security-aware guardrails agreed with the platform team and an entry point inside the case tool.
  2. Measure why people leave it. Ask the analysts, in the team's retrospective, what they could not do with the approved tool, and treat the list as a backlog with an owner.
  3. Close the gaps at the boundary, openly, and allow a fast exception. Egress controls on the SOC's workstations can restrict traffic to unapproved AI services; they are announced in the acceptable-use sheet and agreed with employee representatives, and they are not a means of reading what an individual typed, which would be covert monitoring and is outside what this book describes. A request for a new tool for a defined task is answered within five working days by the SOC lead and the data protection officer, with an expiry; an exception route that takes weeks recreates the problem.
  4. Treat disclosure as a safe act. An analyst who reports having pasted something they should not have is reported to the incident process, and the case is learning (B5), not discipline, unless the behaviour was deliberate and repeated. Otherwise the log will show only compliance and the exposure will remain unseen.

Works councils and the analyst

An AI-use log is a record of what an analyst asked, when and with what result. That is the kind of record that employee representatives have rights over. In Germany, BetrVG §87(1) no. 6 gives the works council a right of co-determination over technical systems that are objectively suitable for monitoring employees' behaviour or performance (AI Boss, Chapter 13) (67, Nordqvist, 2026), and GDPR Article 88 allows member states to set specific rules for the processing of employees' data (8, European Union, 2016). Swedish law obliges the employer to negotiate important changes with the unions, and the Region's unit operates under public-sector collective agreements and the Region's co-determination arrangements (AI Boss, Chapter 23). Whatever the national mechanism, the log of an analyst's own tools is not a neutral technical feature.

The question is how these rules apply when SOC tooling records every query, ticket and action. For the AI-use log the answer has four design consequences, which are the terms an agreement can be built around, and Chapter 14 adds the one that is specific to seeded incidents.

  1. Purpose. The log exists to reconstruct a case, to evidence compliance with the policy and to learn from incidents. It is not used to assess an analyst's performance, speed or productivity, and the agreement says so.
  2. Granularity. The case record holds a pointer (route, mode, class, purpose, use, check). The prompt text is held only in the self-hosted platform, for a stated period, and access is limited to the case owner, the data protection officer and the SOC lead for a sampled audit.
  3. Reporting. Reports to management are at team level, and no measure is published by name. The Region's union has already negotiated that closure rates and similar measures are never reported by name, and the AI-use log inherits that rule. Hansa's group works council expects the same.
  4. Change. An agreement that fixes a tool version fails with the next release. The agreement governs classes of change (a new route, a new class of data, a new field in the log), and a change in class returns to the representatives before it goes live.

The reverse also holds. The log and the sheet protect the analyst, and an agreement that makes them visible to the people they affect, and explains why they exist, is more durable than one imposed. Since Article 4 of the AI Act asks providers and deployers to take measures to ensure a sufficient level of AI literacy among the staff who use AI systems (1, European Union, 2024), the briefing on the sheet is also evidence for literacy: each analyst's competence record (CMP-*) notes that the briefing and a short practical exercise were completed, in the way that AI Governance, Chapter 14, asks for role-specific, evidenced literacy (62, Nordqvist, 2026).

Putting the policy to work

The sections above set the rules. This section turns them into a sheet an analyst can use, a policy file the tooling can read, and a comparison across the modes and the two organisations.

Practical guide: A one-page acceptable-use sheet for analysts

Purpose. Give every analyst one page that says which route to use for which data, what never to paste, what to record and whom to ask, and make the page enforceable by the tooling.

Roles. The SOC lead owns the sheet. The data protection officer reviews the classes and the retention. The platform team implements the routes and the case-tool controls. Employee representatives agree the logging terms. Analysts take part in the retrospective that revises it.

Steps.

  1. Fix the four data classes, name the data that is always restricted (alert content, case content, personal data, evidence), and mark each route as allowed or not allowed for each class. Default to not allowed, with a ceiling of Level 1 Assisted for drafting and summarising, Level 2 Supervised for reviewed read-only queries, and nothing above Level 2 in Modes 1 to 3.
  2. Print the never-paste list in no more than eight lines, and state the record: what the case tool captures, what the analyst adds, how long prompts are kept and that no individual measure is reported.
  3. State the unassisted share: by default one case in five is worked without an assistant, and one in two for analysts in their first six months, adjusted with the team.
  4. Agree the sheet with employee representatives before it goes live, name the exception route, brief every analyst and record the briefing in the competence record.
  5. Put the review date on the page.

Defaults to adapt. The five-working-day exception time, the unassisted share and the prompt retention period are starting points. Adapt them to the works agreement, the collective agreement and the risk appetite, and record the reasons in the decision record.

Definition of done. Every analyst has the sheet and has completed the briefing; the case tool offers only the permitted routes for each class; a sampled review of ten cases shows that the log entries match the routes actually used; the exception queue has an owner; and the review date is no more than six months away.

Worked example: AI-use policy for the group SOC

The sheet is the human-readable surface of a policy in the repository. The following illustrative file belongs in version control as team/ai-use-policy.yaml. The tooling reads it to decide which routes the case tool offers, and the sheet is generated from it. The decision to adopt it is AIDR-0757.

id: AIUP-HM-SOC-01
version: 1.0.0
organisation: Hansa Mutual
owner: group SOC lead
decision: AIDR-0757
works_agreement: KBV-IT-2024 (SOC annex)
effective: 2027-02-01
review_by: 2027-08-01
routes:
  enterprise_assistant:    {mode: 1, hosting: vendor_enterprise_tier}
  embedded_console:        {mode: 2, hosting: vendor, contract_check: required}
  frankfurt_assistant:     {mode: 1, hosting: hansa-dc-frankfurt}
  frankfurt_work_tool:     {mode: 3, hosting: hansa-dc-frankfurt, actions: [read_only_query, draft]}
classes:
  public:       {routes: [enterprise_assistant, embedded_console, frankfurt_assistant, frankfurt_work_tool], max_level: 2}
  internal:     {routes: [enterprise_assistant, frankfurt_assistant, frankfurt_work_tool], max_level: 2}
  confidential: {routes: [frankfurt_assistant, frankfurt_work_tool], max_level: 2}
  restricted:   {routes: [frankfurt_assistant, frankfurt_work_tool], max_level: 2, pseudonymise: true}
never_paste: [credentials, session_tokens, private_keys, malware_samples, embargoed_incident_details]
untrusted_content: {allowed_routes: [frankfurt_assistant], tools_enabled: false}
log:
  case_pointer: [step, route, mode, data_class, purpose, output_used, checked_against]
  prompt_text: {vendor_routes: not_retained, frankfurt_routes: 30_days}
  readers: [case_owner, data_protection_officer, soc_lead_sampled_audit]
  reporting: team_level_only
  use_for_performance_assessment: forbidden
unassisted_share: {default: 0.2, new_analysts: {share: 0.5, months: 6}}
exceptions: {approvers: [soc_lead, data_protection_officer], max_days: 30, answer_within_days: 5}

Three features carry the design. The routes are declared with their mode, so that the policy cannot give a Mode 3 tool the standing authority of a Mode 5 agent: the actions list for the work tool excludes anything that writes. The untrusted-content rule routes hostile fragments to a tool-less assistant only. And the last log lines state in the policy itself what the works council agreed: team-level reporting and no use for performance assessment. A tool that reads the file fails closed: a route absent from a class is not offered.

The same analyst may use all three modes within one shift. The table maps each to the data classes the policy allows and to the highest degree of delegation.

Across the usage modes

Mode Typical SOC use Data classes allowed Highest degree of delegation Logging and routing
Mode 1 Conversational assistants Summarise a report, explain a command, draft a message Public and internal on enterprise tiers; all classes only on self-hosted routes Level 1 Assisted Case pointer; prompt retained only on self-hosted routes
Mode 2 Embedded workplace assistants Summarise inside the SIEM, EDR or case tool Public only under AIUP-HM-SOC-01; wider classes only where the contract states location, retention and no training Level 1 Assisted Contract check before enabling; vendor's own AI covered by the Mode 0 clause
Mode 3 Agentic work tools Draft and run reviewed read-only queries; draft detections Self-hosted routes only; untrusted content excluded Level 2 Supervised for reviewed read-only queries; Level 1 Assisted for drafts Case pointer; actions list enforced by the tool; no write to shared systems

Anything that would need Level 3 Bounded, a standing identity or a write to a shared system is not a Mode 1 to 3 tool. It is an agent with a mandate manifest, and Chapter 13 describes it.

Nordvik Region and Hansa Mutual

Nordvik Region. The security unit's six analysts use the approved enterprise assistant (Mode 1) for public and internal material only. For alert data they use a self-hosted assistant on the Region's reserved capacity (Mode 1 in use, hosted by the Region), which sits beside NR-SEC-001 (AIDR-0301) and shares its retrieval context. The embedded assistant in the procured SIEM service is not enabled in the Region's tenant until annex MS-2 to framework agreement NR-2025-044 states processing location, retention and the provider's own use of AI (Chapter 16). Karin Lund drafted the one-page sheet AUS-NR-SOC-01, recorded as AIDR-0706, and the unit's union agreed that the AI-use log is never reported by name, the same principle that already covers closure rates. Because the six analysts have no slack, the unassisted share is lower than at Hansa, one case in ten, and the exception route runs through the CISO.

Hansa Mutual. The group SOC of about 38 people routes by classification in the hybrid set-up: public and internal material may use the enterprise tiers, and confidential and restricted material only the Frankfurt routes. The detection engineers and senior analysts also use a Mode 3 work tool on those routes. Logging of AI use was agreed with the Konzernbetriebsrat, whose chair is Thomas Brandt, in the SOC annex to KBV-IT-2024 in 2027, with team-level reporting and a ban on use for performance assessment; the Polish service centre's employee representatives and the Swedish unions were consulted under their own rules. The policy AIUP-HM-SOC-01 (AIDR-0757) reads the market overlays so that restricted data from the UK and Swiss entities stays on the routes covered by the transfer arrangements.

Nordvik controls the self-hosted route and the sheet but depends on its provider for everything embedded in the tools it buys; Hansa controls the platform and must keep policy and routes consistent across seven regimes and two sites.

Outlook

Three statements about the future carry labels. That analysts use conversational and embedded assistants in their daily work, and that security vendors embed assistants in their consoles, is observable, and the joint guidance of the Five Eyes agencies on careful adoption of agentic AI services shows that national cyber agencies now regard agentic tools as something organisations are adopting (35, Five Eyes agencies, 2026). That local or self-hosted models become good enough to handle sensitive alert data for drafting and summarising, at a cost a small authority can bear, is expected: the reserved-capacity and open-weight arrangements already in use at Nordvik are the trend on which it rests, and the expectation lapses if the quality gap to hosted models widens. That the review of AI output becomes unnecessary because the model is reliable enough is speculation, and nothing in the chapter assumes it.

Summary

The analyst's own use of AI in Modes 1 to 3 touches every blue team function: B1 Anticipate through summarised intelligence, B2 Detect through drafted queries and detection logic, B3 Investigate through summaries and timelines, B4 Respond through drafted updates and notices, and B5 Learn through first drafts of reviews. In these modes the AI acts with the analyst's identity, so the safeguards are the analyst's discipline and the tooling that makes it easy: classification of the data, restriction of routes by class and enforcement in the case tool and the AI gateway rather than in memory.

Four rules carry the chapter. Restricted data, which includes alert and case content, goes only to routes the organisation controls, and credentials, samples, embargoed details and unreleased defences go to none. Minimise first, and replace identifiers with tokens. Record each use as a pointer in the case record, and keep prompt text only where the platform is the organisation's own. And hold the line between assistance and delegation: no Mode 1 to 3 output feeds a closure, containment or notification unless a named analyst has checked it against a primary source, and anything that acts on standing authority is an agent with a mandate.

Shadow AI is a symptom of an approved route that does not serve security work, and the remedy is a better route, a fast exception path and a culture in which disclosure is safe. The log of an analyst's own tools is a monitoring-capable record, so its purpose, granularity, reporting and change rules are agreed with employee representatives. Nordvik Region shows the version for a team of six that depends on a provider; Hansa Mutual shows the version for a large group that holds the platform. Chapter 13 takes the next step: an AI agent team for the SOC, in which agents work under mandate manifests, with identities of their own and a human conductor.

Sources

  1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
  2. 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). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
  3. European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation). Official Journal of the European Union, 4 May 2016. (8, European Union, 2016)
  4. MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (9, MITRE, n.d.)
  5. OWASP Foundation. OWASP Top 10 for Large Language Model Applications, 2025 edition. OWASP GenAI Security Project. (13, OWASP, 2025)
  6. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1, July 2024. (15, NIST, 2024)
  7. Five Eyes cyber security agencies. Careful adoption of agentic AI services. Joint guidance, 1 May 2026. (35, Five Eyes agencies, 2026)
  8. Nordqvist, G. Architecture as Code. The Architecture as Code Series, Book 1. (61, Nordqvist, 2025)
  9. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 2. (62, Nordqvist, 2026)
  10. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. The Architecture as Code Series, Book 3. (63, Nordqvist, 2026)
  11. Nordqvist, G. AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 4. (64, Nordqvist, 2026)
  12. Nordqvist, G. AI Boss: When Artificial Intelligence Manages People in European Enterprises and Public Authorities. The Architecture as Code Series, Book 7. (67, Nordqvist, 2026)