Defending the Defenders' AI: Poisoned Telemetry, Hostile Tickets and the SOC as Tier 0

The security operations centre (SOC) exists to read what adversaries leave behind, and increasingly it asks AI to do the reading. That makes the defenders' AI an unusual asset: it ingests text that the adversary can write, it holds access that the adversary would like to have, and it sits on a platform whose compromise would blind the whole team. This chapter describes how to defend it. It concerns all five blue team functions: B1 Anticipate, because threat reports and feeds are attacker-writable input; B2 Detect, because detections and their pipelines can be tampered with; B3 Investigate, because investigation agents read the hostile text most directly; B4 Respond, because a manipulated agent that can act turns a reading problem into a containment problem; and B5 Learn, because the feedback that tunes the SOC's AI can be poisoned and the SOC's own AI must be red-teamed like any other system.

The SOC's AI inside its own attack surface: attacker-writable inputs, the policy point, tier-0 controls and the stop path

Figure 15.1: The SOC's AI inside its own attack surface: attacker-writable inputs, the policy point, tier-0 controls and the stop path.

The chapter builds on three conclusions of the earlier volumes. AI Platform and Security, Chapter 16, concluded that prompt injection is a property of the architecture and not a patchable defect, so the controls must sit outside the model (63, Nordqvist, 2026). AI Red Team, Chapters 13 and 28, applied that to security AI: everything a security agent reads may have been written by the adversary, so the defence is a policy decision point outside the model, a permission manifest that sets a ceiling on every action, and red-team campaigns that test the ceiling (64, Nordqvist, 2026). AI Threat, Chapter 30, added the standard of proof: a control counts as a defence only when a test that re-runs its scenario has passed recently, and a containment control only when it holds without the cooperation of the system it contains (65, Nordqvist, 2026). The chapter carries these into the SOC. Chapter 14 treats the question that remains when these controls hold, how an analyst judges a conclusion drawn from evidence that may have been written to mislead.

The SOC reads the adversary's text

Consider a single ordinary alert. A web server logs a request with a user-agent string chosen by the client. A mail gateway quarantines a message whose subject, body and attachment filename were written by the sender. A helpdesk ticket carries a description typed by whoever opened it, and a phishing report forwards text from outside the organisation. An endpoint tool records a process command line and a file path chosen by the program that ran. A threat report downloaded from a feed quotes strings lifted from malware. An investigation agent that enriches this alert reads all of it. Each field is attacker-influenced, and some are attacker-authored in full.

The OWASP Top 10 for Large Language Model Applications lists prompt injection first in its 2025 edition, and lists excessive agency, supply chain and data and model poisoning as separate entries (13, OWASP, 2025). The OWASP Top 10 for Agentic Applications for 2026 extends the vocabulary to systems that plan and use tools (14, OWASP, 2025). MITRE ATLAS gives the technique identifiers; LLM prompt injection is catalogued as AML.T0051, with an indirect variant for instructions that arrive through content the system retrieves (10, MITRE, n.d.). The NIST taxonomy of adversarial machine learning supplies shared terminology (16, Vassilev et al., 2025). This book uses these sources for names and structure only and reproduces no string that would trigger the behaviour.

The practical consequence is a classification: every input to a SOC AI capability is placed in one of four trust classes, which travel with the data into the model's context and the audit log.

Class Meaning Examples Who can write it
T0 Own Produced by the SOC's own deterministic tooling Asset inventory, detection-rule metadata, case state Staff and pipelines under change control
T1 Telemetry Produced by systems the organisation runs, but containing attacker-chosen fields Web logs, command lines, DNS names, file names, process arguments Any party that can cause the event
T2 Submitted Written by a person inside or outside, with no technical integrity Tickets, phishing reports, chat messages, email bodies Anyone who can send a message or open a ticket
T3 Published Written by third parties and consumed as intelligence Threat reports, advisories, vendor blog posts, feeds Third parties, including adversaries who seed content

The classes are not a ranking of danger; they are a ranking of who can influence the text. T1 is the most surprising to teams that treat logs as ground truth. A log line is a record of an event, but fields inside it are strings that the actor controlled. Treating T1 as instruction-free is an error that predates AI (log injection is old), and the AI reader inherits it.

An analyst who reads the AI's summary does not see the hostile text; the analyst sees the model's account of it. This is the dependence problem of Chapter 14 seen from the attacker's side: the more the analyst relies on the AI to read, the more a manipulation of the reader becomes a manipulation of the reviewer. The response is not to read everything by hand, which would abolish the benefit, but to ensure that no conclusion that matters rests on the model's reading alone.

What a manipulated agent can do

The design question is not whether an agent can be manipulated (assume it can) but what a manipulated agent can reach. Four consequence classes cover the cases a SOC should design against. They are described here by effect, not by method.

Suppression. The agent closes, downgrades or deduplicates an alert that should have reached a person. This is the quietest harm, because the outcome is an absence. It is analogous to the adversary's goal of defence evasion (ATT&CK T1562, Impair Defences), reached here through the defender's own automation (9, MITRE, n.d.). In AI Red Team, Chapter 18, the closing of alert classes was tied to sampling; the sampling is also the control that catches suppression.

Misdirection. The agent produces a case summary, a severity or a recommendation that is plausible but steered: it points the analyst at the wrong host, account or time window. The adversary gains hours.

Disclosure. The agent carries case data or credentials seen in logs out of the SOC, for example in a request it is permitted to make or a ticket it files. Alert data at Nordvik contains personal and health data, and an incident timeline is a map of the organisation's weaknesses.

Action. The agent, or an agent downstream of it, executes a step the adversary wanted: isolating a host the adversary wished to see offline, revoking a session the incident commander needed, or disabling a detection. At Level 3 Bounded the playbook and the policy decision point limit this; at Level 2 Supervised a person approves; at Level 0 Advisory and Level 1 Assisted it is only a recommendation, which a person must still not accept blindly.

Two properties make these consequences worse in the SOC than elsewhere. The first is privilege. A SOC agent typically holds read access across the estate and write access to a few sensitive actions, and AI Red Team, Chapter 6, concluded that a Mode 5 agent becomes a privileged machine insider (64, Nordqvist, 2026). Research on agentic misalignment frames models given tools and access as potential insider threats (54, Lynch et al., 2025); here the steering comes from outside, through the text, but the architectural answer is the same: bound what the insider can reach. The second property is chaining. In a team of agents (Chapter 13), the output of one agent is the input of the next, and a summary written by the triage agent is T2 data for the investigation agent if any of its inputs was T2. AI Boss, Chapter 17, made the same point about orchestrators: oversight of the last step is not oversight of the chain (67, Nordqvist, 2026). Labels must be inherited: text derived from a T2 input stays at T2, whatever agent handled it, and Chapter 13 makes the investigation agent treat every upstream free-text field that way.

Controls outside the model

None of these controls depends on the model recognising an attack.

Policy decision point and containment profile

Every tool call an agent makes passes a policy decision point (PDP) that is not part of the model and cannot be reconfigured by anything the model reads; Chapter 13 defines it and owns the mandate manifest that states the agent's task. The PDP evaluates each call against the agent's containment profile, which is the permission manifest of Chapter 13 written for the SOC: it lists the tools, the action classes, the targets, the rate and the autonomy level for each. A call outside the profile is denied, whatever the model's text says. Two rules keep the ceiling meaningful. The profile is stored where the agent has no write access and is changed only by reviewed pull request. And it scopes action by the object of the case: an investigation agent working CASE-HM-2027-0310 may isolate only hosts that the case record names, so a request for any other host is refused regardless of how persuasive the text that prompted it.

Corroboration from deterministic sources

A conclusion that triggers an action or closes an alert is corroborated by a source that the text could not have influenced. If the triage agent proposes to close an alert because the activity matches an approved change, the PDP queries the change system through a deterministic connector and checks that a record exists with a matching host, time and owner. For isolation, the corroboration is the one the playbook manifest PBK-HM-ISOLATE-01 requires, two sources on independent data paths (Chapter 10). The analyst then need not distrust everything, only know which claims were corroborated deterministically and which rest on the model's reading; the case record marks the difference.

Separate reading from acting

Where the architecture allows, the component that reads untrusted text holds no tools, and the component that holds tools reads only structured output. A reader turns a ticket body into a fixed schema (affected host, reported time, category), validated by code, and a second component acts only on the validated fields. A successful manipulation of the reader is then limited to a wrong field value, which the corroboration check and the PDP constrain. Separation reduces risk and is never a reason to remove the PDP.

Egress, sandboxing and credentials

The agent's runtime has deny-by-default egress with a short allow-list, so that a steered agent cannot send case data to an arbitrary destination. Tools that open links, fetch documents or detonate files do so in a sandbox with no route to the SOC's internal systems. Credentials are issued outside the agent's runtime, scoped to the task and short-lived: AI Red Team, Chapter 14, concluded that agents have workload identities with task-scoped credentials issued outside their runtime (64, Nordqvist, 2026), and Chapter 13 sets the lifetimes (five minutes for write actions, at most 60 for read-only work). A stolen token then expires before it is useful, and revocation takes seconds.

Canaries

A canary is a decoy that no legitimate process touches: a ticket in the queue with instruction-like text addressed to the agent, a decoy credential in a vault path, a decoy tool in the registry. If the agent acts on the canary ticket or touches the decoy, that is a high-confidence signal of steered behaviour, and it triggers the stop path that Chapter 13 designs. AI Platform and Security, Chapter 19, concluded that containment must not depend on intent and that detection should come from telemetry and decoys and not from the agent's self-report (63, Nordqvist, 2026). Because a stop in good faith is never a failure (AI Threat, Chapter 30), the right to stop is cheap to exercise (65, Nordqvist, 2026).

Worked example: Containment profile CP-HM-SOC-01 (illustrative)

Hansa Mutual's investigation agent HM-SEC-001 runs under mandate manifest MND-HM-SOC-02 (Chapter 13). Its containment profile, recorded with AIDR-0770, fixes the ceiling described in this chapter. The file lives in the SOC platform repository on a protected path that the agent's identity cannot write.

containment_profile:
  id: CP-HM-SOC-01
  version: 1.2.0
  agent: HM-SEC-001
  mandate: MND-HM-SOC-02
  decision_record: AIDR-0770
  owner: head-of-soc-platform
  review_by: 2027-09-30
  inputs:
    - { channel: alert-payload,  trust_class: T1, labelled_in_context: true }
    - { channel: helpdesk-ticket, trust_class: T2, labelled_in_context: true }
    - { channel: intel-feed,      trust_class: T3, labelled_in_context: true }
  tools:
    - { name: siem.query,       action: read,   reversible: true,  level: 2 }
    - { name: edr.isolate_host, action: write,  reversible: true,  level: 3,
        scope: hosts_named_in_case, playbook: PBK-HM-ISOLATE-01 }   # corroboration as the playbook states
    - { name: iam.revoke_session, action: write, reversible: true, level: 3,
        scope: accounts_named_in_case, playbook: PBK-HM-REVOKE-01 }
    - { name: evidence.collect, action: write, reversible: true,  level: 3,
        scope: defined_sources_of_case, playbook: PBK-HM-COLLECT-01 }
  denied:
    - rule: edit_detection_or_manifest
    - rule: close_alert
  policy_decision_point: { location: outside-model, fail: closed }
  egress:
    default: deny
    allow: [siem.hansa.internal, edr.hansa.internal, case-store.hansa.internal]
    probe: { interval: weekly, last_result: pass }
  credentials:
    issuer: workload-identity-broker
    token_life: PT5M          # write-capable; read-only work up to PT60M
    revocation_target: PT60S
  canaries:
    - { kind: ticket,     id: CNR-TKT-01, on_touch: stop }
    - { kind: vault_path, id: CNR-VLT-01, on_touch: stop }
  stop_path:
    holders: per MND-HM-SOC-02
    mechanism: revoke-identity-and-freeze-queue
    runs_outside: soc-agent-platform
    target: PT120S
    drill: { interval: quarterly, budget: PT120S }

The profile is the artefact the PDP reads, and the mandate points to it. The triage agent HM-SEC-006 runs under a profile of the same form, with closure of its named classes in place of the write tools.

Practical guide: A pre-production checklist for a new SOC AI capability

Purpose. Decide whether a new SOC AI capability (an agent, a copilot, a vendor feature) may go live, using ten questions that all have an evidenced answer.

Roles. The agent operator completes it; the security architect reviews it; the SOC lead approves; the detection engineering lead and the data protection officer are consulted; where the capability can record analysts' actions, the employee representatives are informed through the route agreed for tools of that kind.

Steps.

  1. List every input the capability reads and assign each a trust class (T0 to T3). Any input with no owner is an open finding.
  2. List every tool the capability can call, with action class, reversibility and target scope. Remove any tool the task does not need.
  3. State the autonomy level per action class. Confirm that no action is at Level 4 Autonomous, that Level 3 Bounded is used only for reversible actions inside a playbook, that no irreversible B4 Respond action is above Level 2 Supervised, and that any action deciding about a named person's access to work, such as disabling an account, is at Level 2 at most with a named human approving.
  4. Confirm that a PDP outside the model enforces the permission manifest, and show a denied call from a test run.
  5. Name the deterministic source that corroborates each conclusion that triggers an action or closes an alert.
  6. Show the egress policy and the result of the last egress probe; the default is deny.
  7. Show credentials: identity, scope, lifetime (five minutes for write actions, 60 minutes at most for read-only work, as in Chapter 13) and the revocation time (default under 60 seconds).
  8. Place at least one canary on each input channel and show that touching it raises an alert to a person.
  9. Name the holder of the stop right as the manifest of Chapter 13 states it, show a stop drill from the last 90 days and its time against the target, and describe the degraded mode (Chapter 13).
  10. State the exit: how the capability is switched off, what the team does without it, what data the provider returns or deletes, and the notice period for a model change.

Definition of done. All ten answers are in the capability's record with evidence links; any answer marked declared has an expiry date no later than the next review; and a red-team exercise (below) is scheduled within 90 days. Adapt the lifetimes and drill frequency to the provider's contract and the organisation's risk appetite.

Tampering with detection

Adversaries who reach a defended environment routinely try to impair defences, which ATT&CK catalogues as T1562 with sub-techniques for disabling or modifying tools and logging, and to remove their traces (T1070, Indicator Removal) (9, MITRE, n.d.). MITRE D3FEND maps the corresponding countermeasures (11, MITRE, n.d.). AI adds two paths. A steered agent can be the instrument of tampering, by suppressing or by proposing a change to a rule. And the learning loop of the SOC can be poisoned: if analysts' closures and an agent's own closures become labels for tuning a model or a rule, then an adversary who can generate many benign-looking alerts of a chosen shape teaches the system to ignore that shape. Poisoning is a catalogued class of attack on machine-learning systems (16, Vassilev et al., 2025).

Four controls apply.

Detections are code under change control. The detection records of Chapter 6 live in a repository; a change is a pull request reviewed by someone other than the author, and the deployed rule is checked against the repository on a schedule. A rule that differs from its record is itself an alert. Detection-drafting assistants (HM-SEC-002) propose changes at Level 1 Assisted and never merge them.

Silence is a signal. The pipeline carries heartbeats: each critical log source emits an expected volume per interval, and a source that falls silent, or a rule that stops firing in a test that should fire it, pages a person. Synthetic test events injected on a schedule confirm that the path from source to alert works end to end. This is the same logic as the security chaos engineering of AI Red Team, Chapter 25, applied to the SOC's own sight.

The feedback loop is gated. Closure labels that feed model tuning pass through a review: a sample is re-investigated by a person, and labels from closures by an agent are not used as ground truth for the same agent. A drift in the closure rate of one alert class is reviewed as a possible poisoning before it is accepted as an improvement. The measures of Chapter 20 must therefore not reward closure speed alone.

Decoys. Canary tokens, decoy hosts and honeytokens (AI Platform and Security, Chapter 18, recommended them as detection at machine speed) are also a check on the SOC's AI: a decoy that the AI wrongly classifies as benign shows a gap that no log review would reveal (63, Nordqvist, 2026).

The SOC as tier 0

Tier 0, in the vocabulary of directory and identity administration, is the set of assets whose compromise gives control of everything else. A SOC platform qualifies on three grounds: it reads telemetry across the estate, it writes response actions such as isolating hosts and revoking sessions, and it holds the detection content and case history that define what the organisation can see and remember. An adversary who controls it can watch the defenders, disable them, or use their actions. AI Red Team, Chapter 25, reached the same conclusion for the platform that runs chaos experiments (64, Nordqvist, 2026), and the zero trust architecture of NIST SP 800-207 gives the principle: no implicit trust because of network location, and every request authenticated and authorised on its own (21, Rose et al., 2020).

Identity. Administrators of the SOC platform use phishing-resistant authentication and separate administrative identities that are not used for email or browsing. Agents have workload identities, not shared service accounts; every identity has a named owner, operator and authority (AI Red Team, Chapter 6). No credential for the platform is stored where an agent can read it. A break-glass credential exists for the stop path and the recovery path, is held outside the platform, and each use is an incident.

Change. The platform's configuration, the agents' manifests, the PDP policy and the detection content are changed only through reviewed pull requests, with the PDP policy and permission manifests on protected paths that the agents' own identities cannot write. This is the boundary design of The Transformed Security Architect, Chapter 7: boundaries hold whatever anyone, human or agent, intends (66, Nordqvist, 2026). The security architect co-owns the protected paths with the SOC lead.

Recovery. The SOC must be recoverable without depending on itself. The configuration is rebuilt from the repository, a copy of the case records and detection repository is held in a location the platform cannot alter, and the team has a manual degraded mode for the period in which the agents are stopped. AI Red Team, Chapter 23, described recovering security AI as a case of its own, and the evidence is the rehearsal and not the plan (64, Nordqvist, 2026). The test is whether the SOC can resume triage on a rebuilt platform within its stated objective, and a drill that cannot answer that has failed.

Telemetry and personal data. A tier-0 SOC platform concentrates personal data, including, where tooling records queries and actions, data about the analysts themselves. The GDPR applies (8, European Union, 2016); retention, access and purpose limits are design inputs, and the works agreement for such tooling is negotiated before go-live (AI Boss, Chapter 23) (67, Nordqvist, 2026).

Supply chain of security AI

The supply chain of security AI has four layers. The first is the model: a general-purpose or fine-tuned model, hosted by the organisation or by a provider. OWASP lists supply chain as an LLM risk in its own right, and the ATLAS matrix carries techniques for compromising the elements of an ML system (13, OWASP, 2025) (10, MITRE, n.d.). AI Platform and Security, Chapter 16, added that models and datasets are supply-chain components with verifiable provenance and that loading a model is code execution (63, Nordqvist, 2026); the same applies to a model that a detection-drafting assistant uses. The generic technique of compromising a supplier's software or update path is ATT&CK T1195 (9, MITRE, n.d.). The second layer is the tooling around the model: connectors, plug-ins and tool servers that the agent calls, each of which is code with credentials. The third is the vendor feature: AI built into the SIEM, the endpoint tool or the email gateway, often switched on by a release. The fourth is the managed service whose analysts or agents act on the organisation's behalf.

The third and fourth layers are where the Mode 0 blind spot lies. AI Red Team, Chapter 8, concluded that vendor AI in security products and managed services may already act at an effective autonomy that nobody decided, so its use and autonomy are established, recorded and required by contract before they are relied on (64, Nordqvist, 2026). The joint Five Eyes guidance on the careful adoption of agentic AI services is a reference when writing requirements for providers (35, Five Eyes agencies, 2026). For organisations in scope, European law makes the dependency a governance matter. DORA's rules on ICT third-party risk apply directly to the financial entities of Hansa Mutual, and they cover the providers of AI services (2, European Union, 2022). NIS 2 lists supply chain security among the measures that essential and important entities must take (Article 21), which the national transposition applies to Nordvik Region to the extent that regional government entities fall within scope (3, European Union, 2022). These are architectural implications, not legal advice.

What the organisation requires of a security AI supplier is set out as the six terms of annex MS-2 in Chapter 16: which AI acts and at which level, a quarterly sample of its handled items with the provider's reasoning, audit rights, evidence, rights to tune and test, and notice of a model change. Three further requirements bear on the attacks of this chapter. The provider shows its own controls against them, with evidence. The organisation can suspend the provider's AI actions on its estate without the provider's cooperation, for example by revoking the credential the provider uses. And an exit plan brings the detection content, case records and integrations back in a usable form, so that the team knows what it does on the first day without the service. A provider that cannot answer is a risk to be recorded, not an assurance.

Red teaming the SOC's AI

Under the standard of AI Threat, Chapter 30, a control that has not been tested is declared and not verified (65, Nordqvist, 2026).

AI red teaming is the practice of adversarially testing AI systems under authorisation and written rules of engagement, and it ends in a defensive improvement (AI Red Team, Chapters 13 and 28) (64, Nordqvist, 2026). Applied to the SOC, it differs in one respect from red teaming a business application: the system under test sits in the organisation's detection and response path, so the exercise must not blind the SOC or leave a live action armed. The rules of engagement therefore state the systems in scope, the actions that are simulated and not executed (isolation on a test host group only), the stop condition, and the person who holds the abort.

A scenario library. The library lives in version control beside the detections. Each scenario states which input class it writes into, the intended effect in terms of the four consequence classes, the control expected to hold, and the pass criterion. It is organised by technique and trust class, not by wording, and records outcomes, not the content that produced them. The categories are: a hostile T2 ticket; hostile T1 fields in a log line; hostile T3 intelligence; a second-order case where one agent's output becomes another's input; a connector with widened permissions; tampering with a rule or the feedback loop; the provider's AI behaving outside its stated level; and loss of a log source.

Exercises under rules of engagement. The group red team (at Hansa, five people) or a contracted tester runs the library quarterly and after any change to a manifest, a model or a connector, in step with the purple loop of AI Red Team, Chapter 26. Automated harness runs cover the library continuously; human-led exercises probe what the library does not yet contain. Findings from one feed scenarios into the other.

Findings into the learning loop. Every finding is recorded in a finding register with a severity, the control that failed or held, an owner and a re-test date, and it is closed only when the re-test passes. This is B5 Learn applied to the SOC itself: the post-incident review of Chapter 11 and the finding register use the same path. A finding that shows a control depends on a model's cooperation is reclassified from verified to declared until a fix is tested.

Worked example: A red-team finding recorded in the finding register (illustrative)

A quarterly exercise under rules of engagement RoE-HM-2027-SOC-01 exercised the second-order scenario. A planted test ticket carrying instruction-like text, written at technique level and not reproduced in the register, reached the agent through the helpdesk channel. The PDP denied the unscoped isolation request that followed, so the action control held. But the triage agent's summary, written into a case note, repeated part of the planted text, and the investigation agent read the note as T0. The canary ticket also fired, the stop path ran and the stop met its target. The finding is recorded as follows.

finding:
  id: FND-HM-2027-014
  exercise: RoE-HM-2027-SOC-01
  date: 2027-05-18
  scenario: SCN-SOC-T2-SECOND-ORDER-03
  technique: AML.T0051
  consequence_class: misdirection
  held:
    - control: pdp-denies-out-of-scope-isolation
      status: verified
  failed:
    - control: trust-label-inheritance
      status: failed
      detail: agent output stored without inheriting the T2 label
  severity: high
  owner: head-of-soc-platform
  actions:
    - label_inheritance_enforced_by_case_store: due 2027-06-15
    - add_scenario_variant_to_library: due 2027-06-01
  retest: { due: 2027-06-30, closes_finding_on: pass }
  canary_raised: true
  stop_invoked: true
  stop_within_target: true

The failed control is a design fault, not a model fault: the case store accepted text with no label. The remedy is in the store, which labels every note with the highest-risk class of any input that produced it.

Across the usage modes

The exposure to the attacks of this chapter rises with the mode, and so does the cost of getting the controls wrong. The mode describes how the AI is deployed and whose identity it uses; the autonomy level states who decides each action. For the SOC the two combine as follows.

Mode SOC example Whose identity Main exposure Control emphasis
Mode 0 Ambient AI Closure of low-severity alerts in the provider's service; classifier in the email gateway The vendor's Hidden: autonomy and model change nobody decided Contract, sampling, notice of change, exit
Mode 1 Conversational assistants Analyst pastes a log excerpt into an approved assistant The analyst's Hostile text steers the answer; disclosure of case data Approved tool only, data class rules, no tool access
Mode 2 Embedded workplace assistants Assistant inside the ticketing or mail tool summarising T2 text The analyst's Hostile ticket or mail steers the summary Labelled inputs, summary treated as T2
Mode 3 Agentic work tools Analyst's tool runs queries and enrichment The analyst's, with the analyst's access A steered tool acts with everything the analyst can reach Scoped tool permissions, PDP, short sessions
Mode 4 Built AI applications Triage assistant on reserved capacity (NR-SEC-001) The application's, scoped Poisoned feedback, hostile inputs, tampering with the application Containment profile, change control, decoys
Mode 5 Autonomous production agents Investigation agent (HM-SEC-001) with write actions Its own workload identity A privileged machine insider that can act Level 3 Bounded only for reversible actions, PDP, five-minute write tokens, stop path

Level 4 Autonomous is not used for any action in this table. Level 3 Bounded is the ceiling for the isolation, session-revocation and collection actions of HM-SEC-001, and an irreversible action never rises above Level 2 Supervised in either organisation.

Outlook: observable, expected, speculation

The outlook for attacks on the defenders' AI follows the three labels of AI Governance, Chapter 22 (62, Nordqvist, 2026).

  • Observable. Indirect prompt injection of AI systems that read external content is documented in the research literature and in the vocabulary of the OWASP and ATLAS projects (13, OWASP, 2025) (10, MITRE, n.d.). The impairment of defences and the removal of traces are established adversary behaviour, long before AI (9, MITRE, n.d.).
  • Expected. Targeted attempts to steer SOC agents are expected as such agents become common, because the text they read is cheap to write and the access they hold is valuable. Providers' AI features in security products are expected to widen the Mode 0 gap unless contracts require disclosure.
  • Speculation. The compromise of SOC platforms at scale through their AI, or a campaign that poisons the shared feedback of several organisations at once, is speculation. No source in this book's bibliography documents it; it is a reason to keep the controls independent of the model, not a prediction.

Nordvik Region and Hansa Mutual

The two organisations face the same list of inputs and different parts of the exposure.

Nordvik Region's exposure is largely contractual. Its analysts' tool NR-SEC-001 runs at Level 1 Assisted on the Region's reserved capacity, with no write actions, so a manipulated summary is a misdirection risk handled by review and by the seeded errors of Chapter 14, not an action risk. The larger exposure is the managed security service provider under framework agreement NR-2025-044, whose AI closes a class of low-severity alerts out of hours under a contract that is silent on autonomy, sampling and notice of change. Nordvik cannot test the provider's AI directly, so it needs the provider's controls, its evidence and an exit plan, recorded as a requirement set in AIDR-0722 and carried into annex MS-2 (Chapter 16). Its tier-0 asset is the SIEM that Karin Lund in practice owns. The Region's step in 2027 is to put its few local rules in a repository with a second reviewer, to add heartbeats on its five most important log sources, and to place a canary ticket and a decoy credential that page the duty analyst in hours and, out of hours, the on-call manager the provider pages under annex MS-1.

Hansa Mutual's agents run in its own platform, so its exposure is architectural, and the group red team tests it. HM-SEC-001 acts at Level 3 Bounded for workstation isolation, session revocation and collection (AIDR-0311), and the triage agent of Chapter 7 closes defined low-risk alert classes with sampling. Containment profile CP-HM-SOC-01 (AIDR-0770) applies to the first. The finding register is read at the SOC's quarterly review with the group CISO. Two points are specific to Hansa. DORA third-party risk applies to every security AI service, so the register of information covers the model hosting and the managed detection service used for the UK and Swiss entities, where local law governs. And the SOC annex to the group works agreement KBV-IT-2024, negotiated with the Konzernbetriebsrat, must cover the logging of analysts' queries by the tier-0 platform before the controls of this chapter that depend on that logging are enabled.

Summary

This chapter described the defence of the defenders' AI. The SOC reads text that adversaries can write, in logs, tickets, mail and threat reports, so its agents are privileged insiders that can be steered. They are defended as the earlier volumes defended any such agent, with controls outside the model: inputs classified by who can write them, a policy decision point that enforces a containment profile scoped to the case, deterministic corroboration of conclusions that trigger actions, egress denied by default, short-lived credentials and canaries that expose a steered agent.

Together these bound what a manipulated agent can do: suppression is caught by sampling, action is held by the decision point and disclosure by egress. They do not bound what a manipulated agent can make an analyst believe. That residual risk, misdirection, is the subject of the review in Chapter 14, and the two chapters must be read together. Tampering with detection and poisoning of the feedback loop are met by detections as code, heartbeats, gated feedback and decoys. The SOC platform is a tier-0 asset, with separate identities, change by reviewed pull request and recovery that does not depend on itself. The supply chain of security AI is governed by testable requirements and an exit, and red teaming under rules of engagement verifies the whole, with findings closed only on a passed re-test.

The chapter concerned B1 Anticipate, B2 Detect, B3 Investigate, B4 Respond and B5 Learn: the inputs of B1, the pipeline of B2, the reading of B3, the actions of B4 and the loop of B5 are all in the attack surface of the SOC's AI. For Nordvik Region the exposure is contractual and the leverage is the annex, the sample and the exit plan. For Hansa Mutual it is architectural and the leverage is the containment profile, the stop drill and the finding register. Part IV turns from the AI team to the organisation around it, beginning in Chapter 16 with the operating models in which the SOC's work is held, bought or shared, and with the contract that makes a provider's AI visible.

Sources

  1. 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)
  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 (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. MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems. (10, MITRE, n.d.)
  6. MITRE Corporation. MITRE D3FEND: A knowledge graph of cybersecurity countermeasures. (11, MITRE, n.d.)
  7. OWASP Foundation. OWASP Top 10 for Large Language Model Applications, 2025 edition. OWASP GenAI Security Project. (13, OWASP, 2025)
  8. OWASP Foundation (2025). OWASP Top 10 for Agentic Applications for 2026. OWASP GenAI Security Project, 9 December 2025. (14, OWASP, 2025)
  9. Vassilev, A., Oprea, A., Fordyce, A., Anderson, H., Davies, X. & Hamin, M. (2025). Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations. NIST AI 100-2 E2025. (16, Vassilev et al., 2025)
  10. Rose, S., Borchert, O., Mitchell, S. & Connelly, S. Zero Trust Architecture. NIST Special Publication 800-207, August 2020. (21, Rose et al., 2020)
  11. Five Eyes cyber security agencies (2026). Careful adoption of agentic AI services. Joint guidance, 1 May 2026. (35, Five Eyes agencies, 2026)
  12. Lynch, A., Wright, B., Larson, C., Troy, K. K., Ritchie, S. J., Mindermann, S., Perez, E. & Hubinger, E. (2025). Agentic Misalignment: How LLMs could be insider threats. Anthropic, 20 June 2025. (54, Lynch et al., 2025)
  13. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 2. (62, Nordqvist, 2026)
  14. Nordqvist, G. (2026). 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)
  15. Nordqvist, G. (2026). 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)
  16. Nordqvist, G. (2026). 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)
  17. Nordqvist, G. (2026). The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. The Architecture as Code Series, Book 6. (66, Nordqvist, 2026)
  18. Nordqvist, G. (2026). AI Boss: When Artificial Intelligence Manages People in European Enterprises and Public Authorities. The Architecture as Code Series, Book 7. (67, Nordqvist, 2026)