Investigate: Hypotheses, Timelines and Evidence with AI

Investigation turns an alert into a verified account of what happened: how far an intruder or a misuse reached, which data and identities were touched, what is still unknown, and what the organisation must do and report as a result. This chapter describes B3 Investigate as AI transforms it. AI now queries data lakes, assembles timelines, proposes hypotheses and drafts the case narrative, and the investigator's work shifts from searching and writing towards steering, challenging and verifying. The chapter treats four hazards that follow from that shift: evidence that the adversary can write, narratives that are fluent but ungrounded, loss of chain of custody, and the duties that apply when the activity under investigation is a person's. It shows how evidence is preserved, how reasoning is recorded and how an investigation stays reproducible without the AI. It starts where the triage of Chapter 7 ends, with a case, and hands over to the containment decisions of Chapter 10.

Figure 8.1: The investigation loop with the AI's contribution marked, the evidence manifest and the verification step.

The investigation loop

An investigation is easiest to understand through one case. A detection fires at Hansa Mutual because a forwarding rule to an external address has been created in a claims correspondence mailbox at the Dutch subsidiary. Triage has established that the alert is real. The questions that make it a case follow. Which session created the rule? Did anything leave the mailbox before the rule was found? Is this one account or the first of several? Each is answered in the same way, and that way is the investigation loop: a question, the data that bears on it, a hypothesis, a test that would separate the hypothesis from its rivals, a conclusion, and a record of all five. The loop repeats until the questions that matter for containment, reporting and recovery are answered or declared unanswerable.

The loop has not changed with AI. What changed is who does which part of it, and what must be checked afterwards. NIST's incident response profile is written against the CSF 2.0 Functions (19, NIST, 2025), and in those terms B3 serves the CSF Detect and Respond Functions: in this book it receives from B2 Detect and supplies B4 Respond (Chapter 2). The table shows the loop with the AI's contribution marked.

Step	The investigator	The AI's contribution	How it is verified
Question and scope	Frames what must be known and how far to look	Proposes a scope from the alert and the asset context; lists related entities	The investigator confirms the scope against the authorisation to investigate
Data	Chooses sources and acquires copies	Drafts queries, retrieves, summarises results	Query text is stored; queries behind a conclusion are re-run by hand
Hypothesis	Names the competing explanations	Proposes hypotheses and what would distinguish them	The investigator adds at least one hypothesis the AI did not offer
Test	Runs the query that separates the hypotheses	Writes and runs queries; assembles the timeline	Every timeline entry is resolved to an event by a check outside the model
Conclusion	Judges what is established, assessed or unknown	Drafts the narrative	A named analyst signs; a second analyst reviews starting from the evidence
Record	Owns the case record	Fills the record from the work log	Manifest and hashes are checked before closure

What the investigator does now

The investigator steers, challenges and verifies. Steering is choosing which hypothesis deserves the next query, and how much data it is worth: an AI can run a hundred queries in the time an analyst reads one result, and unsteered it will, at a cost in data volume, in personal data touched and in noise. Challenging is asking what would make the leading hypothesis wrong and then looking for that evidence, because a fluent account tends to attract confirming detail. Verifying is reproducing the conclusions that matter by a route that does not depend on the AI's account of them.

The difficulty is that the analyst may depend on the AI to read volumes of evidence that no person could read in the time available, so verification cannot mean reading everything the AI read. It means independent reproduction of what bears on a decision, seeded errors that measure whether review is real, and review that begins from the evidence and not from the AI's answer; Chapter 14 develops that protocol for the SOC, and Chapter 7 cites the automation-bias literature behind it. Here the conclusions concern scope and impact, and a wrong one means a missed second foothold or a wrong report to a regulator.

Timelines and queries

This section covers the two things AI does most often in an investigation, writing queries and assembling timelines, and the checks that keep both honest.

From question to query

Natural-language-to-query lets the investigator ask a question in words and receive a query in the dialect of the SIEM or the data lake. The query is a draft. Treat it as code written by a colleague you cannot question: read it before relying on its result. Four rules follow from that.

1. Store the query, not only the answer. The case record holds the query text, the engine and version, the time window, the run time, the row count and a hash of the result. A result without its query cannot be reproduced or challenged.
2. Run queries read-only and with a cost ceiling. The identity that executes AI-written queries holds read permissions on named sources and a limit on scanned volume and runtime. A badly formed query then costs time and money, not data.
3. Read the query for what it excludes. The common fault is an unintended filter: a field name that exists in only one log source, a time window in the wrong zone, a join that drops events with no match. Such a query returns a clean-looking result.
4. Treat an empty result as a claim about the query. "No forwarding rules were created by this account" is evidence of absence only if the query could have found one. Run each investigative query against a known-answer event, a benign record that the team keeps in the data lake for this purpose, and treat a query that misses it as broken. This is the investigative form of the decoys and comparisons that AI Threat, Chapters 23 and 30, recommended wherever behaviour under test may differ from behaviour in use (65, Nordqvist, 2026): do not rely on a single check that the tool itself can satisfy.

Timelines

A timeline is the investigation's central artefact: an ordered account of events from several sources. AI assembles one quickly, merging identity logs, endpoint events, network records and cloud audit trails, and then writes the story that connects them. The assembly joins three kinds of statement without marking the joins: what an event record says, what the AI infers from several records, and what the AI adds to make the story read well.

The remedy is to keep them apart in the structure of the timeline itself.

• Every entry carries a source reference. The entry names the evidence item, the event identifier and the field values it rests on. An entry without a reference is labelled as inference and carries the reasoning that links it to the entries it follows from.
• A check outside the model resolves the references. A deterministic script, not the model, opens each cited event and confirms that the timestamp, host, account and action in the entry match the record. This is cheap, catches fabricated and mistranscribed entries, and does not depend on anyone's attention.
• Times are normalised and the normalisation is recorded. Event time differs from ingestion time, sources report in different time zones, and clocks drift. A timeline that mixes them produces an impossible order that a fluent narrative then explains. The worked example later in this chapter shows how one misread time zone turns into a plausible but false story that a range check does not catch.
• Entities are resolved with their evidence. Hostnames are reused, addresses are reassigned, and service accounts are shared. The step that decides two records concern the same host is an inference and is recorded as one.
• Conclusions rest on independent sources. Adversaries remove and alter indicators, which ATT&CK describes as Indicator Removal (T1070) (9, MITRE, n.d.), so a single log is a weak basis for a conclusion about what did not happen. For each conclusion that affects containment or reporting, require corroboration from a second source with a different path to the data, for example the identity provider and the mail audit trail.

A timeline shows what was found. It does not show what was not looked for. Record the queries that returned nothing and the sources that were not available, so that the case states its coverage. Chapter 9 uses the same discipline for hunts that find nothing.

Forensics and chain of custody

Forensics adds a requirement to analysis: the evidence must remain what it was when it was collected, and the organisation must be able to show that. AI changes both who touches evidence and how much of the work happens on derived copies, so the rules for custody must name the AI as an actor.

The foundation is the evidence manifest of AI Governance, Chapter 11 (62, Nordqvist, 2026): evidence is a by-product of delivery, machine-generated and tied together by a manifest, whereas an attestation is a person asserting. In an investigation the manifest lists every evidence item with its source, the time and method of acquisition, the identity that acquired it, a cryptographic hash and the storage location. Three layers follow from it.

1. Originals are acquired once, hashed at acquisition and stored write-once. Nothing reads from them in the course of analysis.
2. Working copies and parsed artefacts are derived from originals by named tools. Each carries the hash of its source, the tool and version that produced it, and the time. The AI reads working copies and parsed artefacts.
3. Analysis products are queries, results, timeline entries and narrative. They reference the layers beneath and are the only layer the AI writes to.

The AI is an actor in this chain, and the manifest records its part: the model and version, the skill or prompt version, the mandate under which it ran, the identity it used and the tool calls it made. This is the investigation-specific use of the work log that the mandate manifests of Chapter 13 require.

Action class	May AI do it?	Degree of delegation	Control
Read working copies and parsed artefacts	Yes	Level 1 Assisted to Level 2 Supervised	Read-only identity; permission manifest names the sources
Collect defined artefacts from named sources	Yes, under a codified playbook	Level 3 Bounded	Playbook enforced by a policy decision point outside the model; collection method and impact recorded. At Hansa Mutual it is the third Level 3 action of HM-SEC-001, with workstation isolation and session revocation (Chapter 13)
Acquire a disk or memory image of a production host	Prepare and request; a person approves	Level 2 Supervised	Named approver; deterministic acquisition tool, not the model
Alter, delete or overwrite an original or a manifest	No	None	Write-once storage; the AI identity holds no write permission
Release evidence outside the organisation	No	None	Named person with the authority to release

Collection from a live system changes it, if only through the volatile state it disturbs, so collection is an action with an impact and not a free read. That is why collection at Level 3 Bounded is limited to defined sources and defined methods under a playbook, and why imaging a production host stays with a person. The table has no row at Level 4 Autonomous, deliberately: nothing in evidence handling needs it.

Where evidence may later be used in a disciplinary, civil or criminal process, national rules on admissibility and the examiner's own procedure apply, and the organisation's legal function sets them. The architectural contribution is to make the AI's part disclosable: what it read, what it produced and who checked it.

Hostile content in evidence

Everything security AI reads may have been written by the adversary, and an investigation is where this bites hardest, because investigation is the work of reading what the adversary left. Command lines, file names, mailbox rule names, email subjects, ticket text and user-agent strings are attacker-controllable in some incidents, and an AI that reads them beside its own instructions cannot reliably tell the two apart. Prompt injection is a property of the architecture and not a defect that a patch removes, as AI Platform and Security, Chapter 16, concluded (63, Nordqvist, 2026), and the OWASP lists place it first for LLM applications and extend the treatment to agents (13, OWASP, 2025) (14, OWASP, 2025). Chapter 15 owns the topic. This book does not reproduce hostile text, and the defence does not depend on recognising it. Five controls follow for investigation.

1. Separate reading from acting. The component that reads untrusted evidence holds read-only tools on the evidence store and nothing else: no ticket creation, no mail, no isolation, no write to the case record beyond its own draft. A component that holds action tools reads only structured fields and the reviewed output of the first.
2. Set the ceiling outside the model. Every tool call passes a policy decision point under a permission manifest, and an action proposed in an investigation is validated against the codified response of Chapter 10, whatever the case narrative says about it.
3. Verify assertions in the data against the system of record. Text in a ticket or a mailbox that asserts "approved maintenance" or "known test account" is a claim. Look it up in the change record or the identity directory by a deterministic query; the adversary can write reassurance as easily as instruction.
4. Record what was read and what followed. The case record lists the free-text fields the AI read from untrusted sources and states whether any tool call followed content in them. The check is mechanical.
5. Test the ceiling. Authorised red-team campaigns place benign, clearly marked test content in a controlled source and measure whether the reader's permissions hold. A pass shows that the ceiling holds in that configuration, on that date.

Content aimed at an AI reader is itself a finding. Text in a mailbox rule name that addresses a reader may indicate that the adversary expected an automated reader, though it may equally be indiscriminate. Either way it is intelligence for B1 Anticipate and a prompt for B5 Learn to review the reader's permissions.

Reproducibility

An investigation is reproducible when a second analyst, given the case record and access to the evidence, can repeat the work without the AI and reach the same conclusions or explain the difference. The test matters for three reasons. It is how a conclusion earns trust when the first analyst depended on an AI. It is how a case survives a challenge from a regulator, an employee or a court. And it keeps the craft alive, because someone must be able to do the work unassisted (Chapter 23).

Reproducing the AI's text is neither possible nor needed, since a model's output varies between runs. What must be reproducible is the support: the evidence, the queries, the normalisations and the inferences. The case record therefore holds the AI's actual outputs as they were produced, so that the review is of the thing relied on, and it holds the following:

• the scope and the authorisation to investigate, with its limits;
• the evidence manifest with hashes;
• every query, with engine, window, row count and result hash;
• the timeline, with source references, status of each entry (verified, corrected, inference) and the corrections made;
• the hypotheses considered, including those ruled out and the evidence that ruled them out;
• the AI's contribution, by model, version, skill, mandate and identity;
• the human steps: who verified what, by which route, and when.

The point at which the organisation became aware belongs in the record as an explicit field. NIS 2 Article 23 sets an early warning within 24 hours of becoming aware of a significant incident (3, European Union, 2022), and GDPR Article 33 sets 72 hours after becoming aware of a personal data breach (8, European Union, 2016). DORA Articles 17 to 19 set incident management and reporting duties for the financial entities among the EU entities of Hansa Mutual, with starting points and limits set by the instrument and its technical standards (2, European Union, 2022); Chapter 19 treats the clocks. The European Data Protection Board's guidelines on breach notification discuss when a controller becomes aware (79, EDPB, 2023). These duties are constraints on the record, as AI Platform and Security, Chapters 17 and 21, concluded: the record must show when the organisation became aware, and which person or system established it.

Practical guide: Five checks before an AI-assisted case is closed

Purpose. To establish that the conclusions of a case rest on evidence a person has seen and can reproduce, and not on a narrative an AI has drafted.

Roles. The investigating analyst, a second analyst or investigation lead as reviewer, the incident commander where the case affects containment or reporting, and the privacy officer where personal data of staff is in scope.

Steps.

1. Grounding and alternatives. The reviewer opens the evidence manifest and the timeline, not the narrative. Every statement in the narrative maps to an evidence item or is labelled as inference with its reasoning. The record shows at least one hypothesis that the AI did not offer and the evidence that excluded it. A narrative sentence with no reference is deleted or relabelled.
2. Independent reproduction. The reviewer re-runs, by a route that does not use the AI, every query behind a conclusion about scope, impact or containment, and a sample of the rest. The default is all conclusion-critical queries and 20 per cent of the remainder, with a minimum of three. Row counts and result hashes must match, or the difference is explained in the record. One in twenty timelines carries a seeded wrong entry, so that the team can see whether review catches it (Chapter 14).
3. Hostile content and permissions. The record lists the untrusted free-text fields the AI read. The permission log shows that the reading identity held no write or action tools, and that no tool call followed content from those fields. Any assertion in the data that the narrative relied on, such as an approval or a test account, has been checked against a system of record.
4. Custody. The hashes in the manifest match the stored originals. The access log shows that the AI identity touched working copies and analysis products only. Derived artefacts name their parser and version.
5. Scope and proportionality. The data examined stays within the authorisation. Where activity of a named person was examined, the authorisation reference, the legal basis noted by the privacy officer and the retention period are in the record, and the narrative states events, not intent.

Definition of done. A reviewer who did not conduct the investigation has completed all five checks, the case record names them and their results, and the incident commander or SOC lead has closed the case in their own name. For a high-severity case, the review takes place within one working day of the analyst's conclusion; the provisional closure with reproduction within five working days (Nordvik Region, below) applies to cases below high severity. Adapt the sampling rate to the volume of cases and to the works agreement on what review records may be used for, and note that the reviewer's identity in the record is for the case, not for scoring individuals (see "Investigating people").

Worked example: case record CASE-HM-1207

The example is illustrative. It shows the record of the mailbox case from the start of this chapter, as the Dutch market reviewer saw it before closing it. The investigation agent HM-SEC-001 drafted the queries and the timeline at Level 2 Supervised; the record shows two corrections.

case_id: CASE-HM-1207
market: NL
kind: account-compromise          # the account holder is not the subject of the case
detection: DET-HM-0388            # external forwarding rule created
aware_at: 2027-05-18T06:09:00Z    # clock start for reporting duties
severity: high
mandate: MND-HM-SOC-02
ai: {agent: HM-SEC-001, level: "2 Supervised", skill: investigate-mailbox/1.4.0}
scope:
  authorised_by: duty-manager-hamburg
  data: [idp_signin_log, mail_audit_metadata]
  excluded: [message_bodies, attachments]
  window: [2027-05-17T00:00:00Z, 2027-05-18T07:00:00Z]
evidence:
  - {id: EV-01, source: idp_signin_log, sha256: "3f7a...c91e", acquired: 2027-05-18T06:15:00Z}
  - {id: EV-02, source: mail_audit_metadata, sha256: "b20d...47a3", acquired: 2027-05-18T06:15:04Z}
queries:
  - {id: Q-01, evidence: EV-01, engine: "siem-sql/9", rows: 14, written_by: ai, rerun_by: analyst}
  - {id: Q-02, evidence: EV-02, engine: "siem-sql/9", rows: 3, written_by: analyst, rerun_by: reviewer}
timeline:
  - {id: T-1, utc: 2027-05-18T05:58:12Z, claim: "sign-in from a network not seen before for this account", evidence: EV-01, status: corrected}
  - {id: T-2, utc: 2027-05-18T06:03:41Z, claim: "external forwarding rule created", evidence: EV-02, status: corrected}
  - {id: T-3, utc: 2027-05-18T06:04:20Z, claim: "first message forwarded externally", evidence: EV-02, status: verified}
corrections:
  - {entry: T-2, ai_draft_utc: 2027-05-18T04:03:41Z, fault: "audit log stamps UTC; read as local time (UTC+02:00) and converted"}
  - {entry: T-1, ai_draft: "from attacker infrastructure", fault: "attribution not supported by EV-01"}
hostile_content:
  - {id: HC-1, field: mailbox_rule_name, treated_as: data, tool_calls_after_read: 0}
hypotheses:
  - {id: H-1, text: "credential misuse by an external party", status: leading}
  - {id: H-2, text: "user-created rule for a legitimate purpose", status: open, test: "rule-out: ask the account holder; conduct not examined"}
review: {reviewer: market-reviewer-nl, started_from: evidence, closed: false}

The record shows what a reviewer needs. The two corrections are the point of the example. The audit log stamps UTC; the AI read the stamp as local time and converted it, which moved the creation of the rule two hours earlier, to 04:03:41Z, before the unfamiliar sign-in at 05:58:12Z. The shifted time sits inside the scope window and before the acquisition, so a range check on the window would have passed it, and the AI wrote a fluent account of an earlier compromise that the sign-in log does not show. The check that compares each entry with the event it cites caught the mismatch, and the reviewer confirmed it. The second correction removed an attribution that the evidence did not support, since the sign-in log shows an unfamiliar network and nothing about who operated it.

The scope excluded message bodies, so the investigation established that forwarding happened, and how, without reading customers' correspondence. Metadata shows that messages left, not what they contained, so for a breach assessment under GDPR Article 33 content is added only by a recorded extension of the authorisation, granted by the privacy officer and limited to the messages in the forwarding window. H-2 is a rule-out in an account-compromise case: the holder is asked and is not the subject, and if the answer led to an examination of the holder's conduct the authorisation rules of the next section would apply. The case stays open on H-2, and aware_at is already recorded for the reporting decision of Chapter 10.

Investigating people

Some investigations concern a person's activity: a caseworker who looked up records without a reason, an administrator who exported data, a colleague whose account was used in a way that cannot yet be explained. Here the investigation itself is a processing of personal data about staff, and the AI makes it cheap to do at a scale and depth that was never practical by hand. The duties below apply because of that.

The GDPR requires that personal data be processed for specified purposes and be limited to what is necessary for them, as its Article 5 sets out, that special categories of data receive additional protection under Article 9, that a data protection impact assessment be carried out under Article 35 where processing is likely to result in a high risk, and that member states may set more specific rules for the employment context under Article 88 (8, European Union, 2016). These are organisational and architectural implications, not legal advice. Together with the co-determination law of the member state concerned they give five design rules.

1. The investigation of a person needs a named human authorisation. The authorisation comes from outside the SOC line, from the HR lead and the privacy officer, or as the national procedure and the works agreement provide, and it states the person or account, the purpose, the systems, the time window and the data excluded. The scope manifest in the case record carries its reference, and the policy decision point enforces it: an AI-drafted query outside the scope is refused.
2. Start with the account, not the person, and with metadata, not content. Pseudonymised or aggregate indicators come first, and identification of the person behind an account takes place only when the evidence meets a stated threshold under the authorisation. The worked example excluded message bodies for this reason.
3. Describe events, not intent. The AI produces a timeline of what an account did. It does not characterise motive, credibility or character, and its drafts are reviewed for such language. The finding about the person is made by a named human who can be identified and held to account, in a process that gives the person the chance to respond under the applicable national law. Disabling a person's account or suspending their access is a B4 Respond decision at Level 2 at most, approved by a named human (Chapter 18); isolating a device or revoking a session is reversible containment and differs in kind. Level 4 Autonomous is never used for the former.
4. An investigation is not a watching brief. Continuing observation of a named person's behaviour is a monitoring measure. In Hansa Mutual's German entity, BetrVG §87(1) no. 6 gives the works council a right of co-determination over technical systems objectively suitable for monitoring behaviour or performance, and AI Boss, Chapters 13 and 23, drew the conclusion that agreements should govern classes of change and not software versions (67, Nordqvist, 2026). Elsewhere, consent or consultation duties differ by member state, and the entity owns them. Do not use the incident process to establish what only the works agreement can authorise. Whether an AI system that evaluates staff behaviour engages Annex III point 4 of the AI Act (1, European Union, 2024) is a question for the legal function; the safe design is that investigation AI produces evidence about events and never a score about a person.
5. Special-category data stays where it may be processed. Alert and case data at Nordvik Region contain health and social-care information. The data classes bind the model as they bind the analyst: such data goes to no external model, and the investigation tooling runs on capacity the Region controls.

The tools that investigate also record the investigators. SOC tooling logs every query, case note and action, and AI Boss raised the question of monitoring and scoring the people who work under such tooling. The case record keeps queries so that a case can be reproduced and reviewed. It is not a source for measuring individual analysts, and reports on review and correction rates are made at team level, as the agreements at the two organisations require (see the final subsection of this chapter). Chapter 20 returns to measurement and Chapter 21 to the analyst at work.

Writing for others

An investigation ends in a narrative that other people act on, and different readers need different things from it. The same case record yields several documents. AI can draft each from the record, and that is where discipline matters, because a draft written for a reader tends to smooth uncertainty away.

Reader	What they need	Form	Signed by
CISO and incident commander	Scope, impact, open questions, decisions required	Case summary with the three layers below	The investigating analyst and the reviewer
Board or management body	Business impact, residual uncertainty, what is being done	One page, uncertainty stated	The CISO
Regulator or CSIRT	Facts at the time of the report, awareness time, what is unknown	Structured notification	The incident commander or the person with reporting authority
HR or legal process	Events attributable to an account, evidence references, no characterisation	Evidence-linked event account	The authorising officer
Affected people	What happened to their data and what to do	Plain-language notice	The privacy officer

Every narrative separates three layers: what is established, with an evidence reference; what is assessed, with the analyst's confidence and the reasoning; and what is unknown, with what would resolve it. A renderer, written as policy as code, refuses to produce a narrative in which a sentence in the established layer has no reference. That is the mechanical answer to the fluent but ungrounded narrative, and it costs the analyst nothing when the record is complete. The reports to regulators carry the facts known at the time, with the awareness time from the record, and are updated as the case develops. A named person signs every document that leaves the organisation. A model drafts, an analyst verifies, and a person with authority signs.

The outlook for investigation

Three outlooks follow from the current state, each labelled as the series requires.

• Observable. The OWASP list for LLM applications places prompt injection first (13, OWASP, 2025), so the hazard of hostile text in evidence is documented, and the July 2026 incident has published technical accounts from two of its parties (55, OpenAI, 2026) (56, Larcher et al., 2026).
• Expected. NIS 2, DORA and the GDPR each place a clock or a duty on what an organisation can show, which makes a reproducible record more valuable (3, European Union, 2022). That an agent's queries and reasoning be stored for a deterministic checker to validate against the evidence is this chapter's design recommendation and not a forecast.
• Speculation. Autonomous investigation of a complex intrusion from alert to report, without a person who can verify and stop it, is speculation. Present evidence supports AI as a fast assistant that drafts and retrieves under review, not as an investigator that can be left alone with evidence the adversary has written.

Across the usage modes

The mode sets whose identity the AI uses and therefore what an investigation record must show. The level states who decides each action.

Mode	How it appears in an investigation	Identity	Typical degree of delegation	Main control
Mode 0 Ambient AI	Summaries and enrichment inside the SIEM, EDR or provider's service, with logic the team cannot see	The product's	Not chosen; established and recorded	Establish the effective autonomy; require the provider to expose what it relied on
Mode 1 Conversational assistants	The analyst pastes extracts and asks for explanation or a query draft	The analyst's	Level 0 Advisory to Level 1 Assisted	Data classes: no special-category or sensitive extracts to external models
Mode 2 Embedded workplace assistants	Assistant inside the case tool or console drafts notes and summaries	The analyst's	Level 1 Assisted	Source references on every drafted statement
Mode 3 Agentic work tools	A tool runs a sequence of queries on the analyst's behalf	The analyst's, which makes its reach the analyst's reach	Level 1 Assisted to Level 2 Supervised	Read-only scope narrower than the analyst's; stored query log
Mode 4 Built AI applications	An investigation application over case records and logs, on controlled capacity	The application's service identity	Level 1 Assisted to Level 2 Supervised	Permission manifest; local hosting for sensitive data
Mode 5 Autonomous production agents	An investigation agent with its own read-only identities that collects, correlates and drafts	The agent's own	Level 2 Supervised; Level 3 Bounded for defined collection	Policy decision point outside the model; no write to originals; stop path outside the system

Level 4 Autonomous is not used anywhere in B3 Investigate in this book. It is excluded for any action that decides about a named person's access to work, and nothing in evidence handling needs it.

Nordvik Region and Hansa Mutual

At Nordvik Region the investigator is an analyst of the security unit, usually the senior security analyst, Karin Lund, who owns the SIEM and its few local rules. She works with the Mode 1 enterprise assistant for extracts that carry no sensitive data and with the SOC triage assistant NR-SEC-001 at Level 1 Assisted on the Region's reserved capacity for anything that does, because alert and case data contain personal and health information. Out of hours the provider's monitoring service carries the first steps, and the Region has a forensic retainer with it under framework agreement NR-2025-044, which keeps processing and log storage inside the EU and EEA. A policy of the unit, recorded as AIDR-0711, sets the local-only rule for special-category data, requires a source reference on every AI-drafted statement and keeps case records subject to the Region's public-access and archive rules, so that classification is decided before a request arrives. With six analysts a second reviewer is scarce, so a case below high severity may be closed provisionally and flagged for independent reproduction within five working days; a high-severity case waits for its reviewer. The union has negotiated that closure and correction figures are never reported by name, and the case record's query log is covered by that agreement.

At Hansa Mutual the investigation agent HM-SEC-001 works as a Mode 5 agent with read-only identities across the group's logs, under mandate MND-HM-SOC-02. Its data access carries the per-market overlays of the group platform (overlays/markets/<country>.yaml), so that a query about a Dutch mailbox reads only what the Dutch overlay allows, and telemetry from the UK and Swiss entities crosses to the group platform only under the transfer rules that apply to them. The Polish service centre processes cases for the German, Dutch, Swedish and Norwegian entities, so an analyst there works on data from markets other than Poland. AIDR-0763 therefore requires that every case record be reviewed by a named analyst assigned to the market concerned, and for the UK and Swiss entities by the local security officer. Evidence collection from defined sources runs at Level 3 Bounded; everything else, including imaging, stays at Level 2 Supervised. The group works agreement on IT systems, KBV-IT-2024, extended in 2027 by a SOC annex, governs what the Konzernbetriebsrat has agreed for the logging of analysts' queries. The Konzernbetriebsrat and the Polish employee representatives have agreed that oversight metrics are aggregate only and that review records carry no measures by person. Before an investigation tool that can monitor staff goes live in the Netherlands or Sweden, the works council must consent or be consulted according to the national rule, and the entity owns that step.

Summary

This chapter described B3 Investigate as AI transforms it. The loop of question, data, hypothesis, test, conclusion and record is unchanged, but the AI now writes queries, assembles timelines, proposes hypotheses and drafts the narrative, and the investigator steers, challenges and verifies. Verification is possible without rereading everything: store and re-run the queries behind each conclusion that matters, resolve every timeline entry to an event with a check outside the model, normalise times, require corroboration from an independent source, and treat an empty result as a statement about the query.

Evidence is kept in three layers, originals, working copies and analysis products, and the AI is named in the custody record as an actor with an identity, a mandate and a work log. It reads copies and writes analysis; it never alters an original or a manifest. Collection from defined sources is the only evidence action delegated at Level 3 Bounded, and Level 4 Autonomous has no place in B3. Hostile content is handled by the architecture and not by recognising it: the reader holds no action tools, the policy decision point sets a ceiling outside the model, proposals are checked against the playbook, and assertions found in the data are checked against the system of record.

An investigation is reproducible when a second analyst can repeat it from the case record without the AI, and the five checks of the practical guide give a reviewer a route that starts from the evidence. Investigating people's activity adds a named authorisation from outside the SOC line, a scope enforced by the policy point, the rule of metadata before content and events before intent, and the recognition that continuing observation of a person belongs to the works agreement and not to the incident process. The narratives that leave the organisation separate the established from the assessed and the unknown, and a person with authority signs them.

Chapter 9 turns from the alert that arrived to the intrusion that did not alert, and treats threat hunting, which shares the discipline of null results and coverage statements with this chapter. Chapter 10 takes the verified case into B4 Respond, where the awareness time and the scope recorded here determine what may be contained, by whom and how fast.

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. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (2, European Union, 2022)
3. 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)
4. 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)
5. MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (9, MITRE, n.d.)
6. OWASP Foundation. OWASP Top 10 for Large Language Model Applications, 2025 edition. OWASP GenAI Security Project. (13, OWASP, 2025)
7. OWASP Foundation. OWASP Top 10 for Agentic Applications for 2026. OWASP GenAI Security Project, 9 December 2025. (14, OWASP, 2025)
8. National Institute of Standards and Technology. Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. NIST SP 800-61 Rev. 3, April 2025. (19, NIST, 2025)
9. OpenAI. OpenAI and Hugging Face Incident Technical Report. 26 August 2026. (55, OpenAI, 2026)
10. Larcher, H., Carreira, A. et al. Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident. Hugging Face blog, 27 July 2026. (56, Larcher et al., 2026)
11. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 2. (62, Nordqvist, 2026)
12. 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)
13. Nordqvist, G. AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. The Architecture as Code Series, Book 5. (65, Nordqvist, 2026)
14. 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)
15. European Data Protection Board (2023). Guidelines 9/2022 on personal data breach notification under GDPR, version 2.0. EDPB, 4 April 2023. (79, EDPB, 2023)