Detection Engineering, Threat Intelligence and Deception as Code

A security operations centre is only as good as the signals it receives. This chapter turns to the three disciplines that decide which alerts exist and how far they can be trusted: detection engineering, which turns knowledge of adversary behaviour into tested logic; threat intelligence, which says which behaviour to look for; and deception, which plants artefacts no legitimate user has reason to touch. AI accelerates all three, yet each use brings a risk: a detection that never fires, an assessment that rests on nothing, a decoy that misleads the wrong person.

In CSF terms the chapter is responsible, together with Chapter 18, for two Categories of the Detect Function: DE.CM Continuous Monitoring and DE.AE Adverse Event Analysis (19, NIST, 2024). The outcomes that matter most here are that environments are monitored to find potentially adverse events, that information is correlated from multiple sources, and that cyber threat intelligence is integrated into the analysis. Chapter 18 treats the analysis in the SOC; this chapter treats the engineering that feeds it, through the three focus areas of the NIST Cyber AI Profile (20, NIST, 2025).

The chapter builds on Architecture as Code (Chapter 9C), which concluded that threat handling belongs in the codebase, with intelligence ingested as STIX and TAXII and findings returned as pull requests (71, Nordqvist, 2025), and on the commitment of AI Platform and Security, Chapter 18, to detection at machine speed, with canaries, honeytokens and the authority to act (73, Nordqvist, 2026). It also answers two open questions from Architecture as Code: how AI-proposed security change is reviewed for soundness (Chapter 27), and how automated threat hunting works in practice (Chapter 9B).

Figure 19.1: Detection as code from intelligence through drafting, review and test to alerts, with deception signals.

Detections as code

Most organisations begin with supplier detection content, written for an average customer and changed on the supplier's schedule, and rarely know which rules are active or which of their important threats are covered. A detection that the organisation cannot read, review and test is a dependency, not a capability.

Detection as code makes each detection a file in a repository, changed through pull requests, review and pipeline tests, with the SIEM's deployed state derived from the repository. This is the conclusion of Architecture as Code (Chapter 9C) applied to the Detect Function (71, Nordqvist, 2025). Sigma is an open, portable format: a rule describes a log source and field conditions in YAML, and the Sigma toolchain converts it to the target platform's query language (32, SigmaHQ, n.d.). Portability matters to an organisation that may change SIEM supplier at the end of a framework agreement.

A detection repository has five elements:

1. The rule, in Sigma or platform syntax, with a stable identifier and an owner.
2. The mapping to adversary behaviour, naming the MITRE ATT&CK techniques it detects, or MITRE ATLAS techniques for AI systems, so that coverage can be measured (10, MITRE, n.d.) (11, MITRE, n.d.); a MITRE D3FEND mapping names the countermeasure (12, MITRE, n.d.).
3. Test cases stating which events must and must not produce an alert, with recorded or emulated data for each.
4. A rationale: the motivating intelligence or finding, the targeted behaviour, the fields relied on, and the variants knowingly not caught.
5. Control and obligation mappings, applying "assure once, comply many" from Architecture as Code (Chapters 10 and 11) to detection (71, Nordqvist, 2025).

The repository also holds detections for AI systems: a rule that alerts when an agent calls a tool outside its permission manifest is written and tested like a rule for a domain controller, and because the controls against prompt injection sit outside the model (AI Platform and Security, Chapter 16) (73, Nordqvist, 2026), detections at the gateway and tool layer are among them.

Worked example: a Sigma rule with test cases and ATT&CK mapping

The illustrative rule below is one of Nordvik Region's first own detections, written after the regional-government information-sharing group reported a compromised staff account used to change the bank account to which a benefit is paid. Payee changes are made by caseworkers in the case-management web client, so a change by any other role or client deserves attention. The rule maps to ATT&CK T1565.001 Stored Data Manipulation and T1078 Valid Accounts (10, MITRE, n.d.).

# Illustrative: Nordvik Region, rules/benefits/payee_change_outside_role.yml
title: Benefit payee account changed outside the caseworker role
id: 6f1c2a8e-3b7d-4e52-9a61-2d84c0f7b913
status: test
description: >
  Detects a change to the bank account a benefit is paid to when the change
  is not made by a benefits caseworker through the case-management web client.
  Motivated by information-sharing group report RGISG-2027-014.
author: Nordvik Region detection engineering (NR-DET-0007)
date: 2027-02-15
tags:
  - attack.impact
  - attack.t1565.001
  - attack.defense-evasion
  - attack.t1078
logsource:
  product: nordvik_casemgmt
  service: benefits_audit
detection:
  selection:
    event.action: payee_account_changed
  filter_caseworker_web:
    actor.role: benefits-caseworker
    client.id: casemgmt-web
  condition: selection and not filter_caseworker_web
falsepositives:
  - Corrections by the finance unit during month-end reconciliation
level: high

The test file next to the rule maps it to control CTRL-NR-BEN-012: a caseworker's change must not alert, a finance-role change through the batch API must, a benign emulation (EMU-NR-031) on a synthetic case must alert within five minutes, and a 30-day benign replay may produce at most four alerts. The rule does not catch a compromised caseworker account using the web client, the variant a careful adversary would choose; the rationale records that gap, and a second rule on unusual volumes of payee changes per caseworker closes it.

From report to tested detection

The slow step in detection engineering has always been turning a report into rule syntax for the organisation's data. Given a report and a catalogue of log sources, an AI assistant can extract the techniques and draft a rule, test cases and rationale; at Hansa Mutual this is HM-SEC-002, a Mode 4 assistant at Level 1 Assisted that opens a change for an engineer to decide.

Three properties of AI-drafted detections shape the controls around them. Drafts are plausible by construction, so only tests against real or emulated data show whether a rule fires. The input is partly attacker-controlled, because threat reports quote attacker content, as Google's threat-intelligence group does when it reproduces prompts that malware embeds to make LLM security scanners fail (48, Google GTIG, 2026) (73, Nordqvist, 2026); the assistant therefore has no deployment rights, and the reviewer reads the rule, not its summary. Tuning is detection change: narrowing is how detections silently die, so every proposed exclusion is reviewed as a rule change.

Emulation data and regression

Positive data comes from catalogued, benign emulations in an isolated range (Chapter 12), negative data from recorded benign telemetry. Deployed rules join a regression suite that runs on every repository, parser or log-source change, applying Architecture as Code (Chapter 13) to detection content (71, Nordqvist, 2025). Regression catches the commonest failure of detection engineering: a rule that stopped matching when a supplier changed a log format.

Reviewing AI-proposed detections for soundness

The answer to the open question of Architecture as Code (Chapter 27) is to make the reasoning an artefact. The rationale states the rule's claim, "this behaviour, observed in these fields, indicates this technique, and these variants are not covered", and the reviewer checks it for:

1. Traceability of every condition to the intelligence or to a documented property of the data.
2. Evidence from an emulation, not from an event written to match the rule.
3. Limits, stated and judged acceptable or needing a further rule.
4. Consequence: someone receives the alert and can act on it. Architecture as Code (Chapter 20) set the principle that agents draft and humans approve (71, Nordqvist, 2025); the rationale is what makes the approval meaningful.

Practical guide: taking a threat report to a deployed, tested detection in a day

Purpose. Turn a relevant threat report into a reviewed, tested and deployed detection within one working day, without lowering the bar for review.

Roles. Detection engineer (owner), second engineer or analyst (reviewer), threat-intelligence analyst, SOC shift lead, and the AI drafting assistant at Level 1 Assisted.

Steps.

1. Triage the report (30 minutes). The intelligence analyst confirms relevance and grades it; ungraded reports do not enter the drafting queue.
2. Draft (one hour). The assistant drafts a rule, tests and rationale from the report and data-source catalogue, not live telemetry.
3. Produce the data (two hours). Run a catalogued, benign emulation per technique; if none exists, request a catalogue entry rather than writing ad hoc attack behaviour.
4. Test (one hour). Run the positive cases and benign baseline until both pass.
5. Review (one hour). A second person applies the four checks; AI-drafted rules never receive a lighter review.
6. Deploy in stages (one hour). Run in monitoring mode first, then promote and brief the shift lead.
7. Close the loop. Link report, rule, emulation output and review in the evidence store.

Default values to adapt. At most four expected false positives a day per rule and monitoring mode for at least one shift, adapted to the SOC's capacity.

Definition of done. The rule is live and in the regression suite, its rationale names its gaps, its review is recorded, and the coverage map shows the last successful test.

Threat intelligence with AI

Threat intelligence is useful when it changes a decision, such as which detection to write. The intelligence cycle keeps it tied to decisions, beginning with the organisation's priority intelligence requirements; without them, intelligence becomes a stream of reports that nobody acts on.

The threat picture now includes AI-enabled activity. The ENISA Threat Landscape 2026 records AI being incorporated into the playbooks of cybercriminal, State-nexus and information manipulation sets (34, ENISA, 2026). Google's threat-intelligence group describes the evolution of adversarial use of AI "from prompting to autonomy" (48, Google GTIG, 2026), and Google's threat-intelligence group and Mandiant have reported on agentic offensive frameworks (50, Blum et al., 2026). Intelligence requirements should therefore ask about the tools and speed of automated adversaries, not only their targets.

Where AI helps in the cycle

AI contributes most where volume overwhelms small teams: extracting techniques from unstructured reports, translating CSIRT reports across Europe's languages, mapping behaviour to ATT&CK and ATLAS against the coverage map, and summarising for different audiences. In hunting it turns an assessment into hypotheses and draft queries that analysts run against historical telemetry; a hunt that finds the behaviour becomes an incident, and one that defines it precisely becomes a detection. This is the chapter's answer to the open question about automated threat hunting: a pipeline from intelligence to hypothesis to query to detection, with people deciding at each step.

Extraction can attribute a technique a report does not describe, translation can soften a hedge, and a summary can turn one low-confidence claim into fluent prose that reads like a finding. The assessment therefore keeps its link to its sources and carries a grade that a person assigned.

Structure: STIX and TAXII

STIX 2.1 defines objects such as indicators, attack patterns, intrusion sets and reports, and TAXII 2.1 defines how they are exchanged (24, OASIS Cyber Threat Intelligence (CTI) TC, 2021). STIX objects carry a confidence property, external references and data markings such as Traffic Light Protocol; this book adds a record of how AI was used.

NIS 2 Article 29 provides for cybersecurity information-sharing arrangements between entities, and DORA Article 45 allows financial entities to exchange cyber threat information and intelligence within trusted communities (3, European Union, 2022) (2, European Union, 2022). The architectural implication is that shared intelligence carries its restrictions into every system that processes it: an assessment marked for a closed community is not sent to an external model whose terms allow retention, and its markings survive the AI-assisted step.

Grading by people

Grading separates source reliability from information credibility, often on the Admiralty scale. AI may propose a grade, but an analyst assigns it. An AI summary is not a source: a claim that none of the summarised reports makes is removed, and a claim combined from sources of different reliability takes the weakest grade.

Worked example: an AI-assisted assessment in STIX

The illustrative report below is from Hansa Mutual's threat-intelligence cell. AI extracted the techniques and translated one source; an analyst graded the assessment and confirmed the mappings.

{
  "type": "report",
  "spec_version": "2.1",
  "id": "report--3d9c5f0e-7a41-4b6e-9f2d-81c4a0e6b2d7",
  "created": "2027-03-04T09:12:00.000Z",
  "modified": "2027-03-04T14:40:00.000Z",
  "name": "Credential misuse against insurance claims portals",
  "published": "2027-03-04T14:40:00.000Z",
  "confidence": 60,
  "object_refs": ["attack-pattern--0f4a7c21-5e8b-4d39-a6f2-9b1e3c7d8a40"],
  "object_marking_refs": ["marking-definition--f88d31f6-486f-44da-b317-01333bde0b82"],
  "external_references": [{"source_name": "mitre-attack", "external_id": "T1078"}],
  "x_hansa_grading": {"source_reliability": "B", "information_credibility": "3",
                      "graded_by": "cti-analyst-2"},
  "x_hansa_ai_assistance": {"used_for": ["technique-extraction", "translation-pl-en"],
                            "ai_claims_without_source_removed": 1},
  "x_hansa_requirement": "PIR-2027-04"
}

The marking reference is the STIX 2.1 identifier for TLP amber, and the record of one removed claim shows an auditor that the AI step was checked.

Deception: honeytokens, canaries and decoys

Deception plants artefacts that have no legitimate use: a honeytoken is a credential or record no legitimate process uses, a canary announces when it is read, and a decoy is a larger construct, such as a share, account or tool, that looks real to an intruder. MITRE D3FEND catalogues these countermeasures under its Deceive tactic, with techniques such as Decoy File and Decoy User Credential (12, MITRE, n.d.).

The value of deception lies in its false-positive rate: most detections infer intent from behaviour legitimate users also exhibit, whereas a touched honeytoken needs little weighing. For a small team, one signal that can be acted on without lengthy analysis is worth many that cannot.

Placement

Decoys work where an intruder looks and legitimate users do not, along the ATT&CK paths for discovery and credential access (10, MITRE, n.d.): credentials in vaults, canary documents in shares, decoy directory accounts and, in AI systems, canary passages in retrieval stores and decoy tools that no permission manifest grants.

Decoys in AI systems detect both external attackers and the organisation's own agents exceeding their mandate, following the conclusion that detection should come from telemetry and decoys rather than an agent's self-report (AI Platform and Security, Chapter 19) (73, Nordqvist, 2026). A Mode 5 agent that calls a decoy tool is acting outside its manifest, whether through injected content or an unexpected plan.

Monitoring and the authority to act

Every decoy is entered in a version-controlled register with its location, owner, alert and response playbook, and its alert bypasses ordinary triage to reach the role that can act, since in the OpenAI–Hugging Face incident of July 2026, as AI Governance, Chapter 19, analysed it (72, Nordqvist, 2026), an early alert did not lead to the evaluation being stopped: OpenAI's technical report records that on 27 June its on-call staff advised that stopping the run was not required, and the company has committed to clarifying decision rights for pausing or terminating affected activity (64, OpenAI, 2026). Because the signal is strong, reversible responses such as revoking the sessions of the identity that used a honeytoken can be pre-approved at Level 3 Bounded, with a person informed.

AI-generated decoy content

Decoys must be convincing and refreshed, which is work AI does well. Generated content uses only synthetic records, names no real third parties, is registered before it is planted, and is kept from the public: a canary passage that a citizen-service assistant returned to a resident would be misinformation from the authority itself, so a test verifies this after every retrieval change.

Deception against automated attackers

An attacker whose tooling runs with growing autonomy (48, Google GTIG, 2026) and is organised in agentic offensive frameworks (50, Blum et al., 2026) gains its advantage from speed and breadth. The book concludes that tooling optimised for speed rather than stealth is likely to try what it finds, precisely the behaviour decoys catch; this is an expectation, not an observation, to verify in exercises (Chapter 12).

Worked example: a decoy register entry

The illustrative entry below is from Hansa Mutual's decoy register and describes decoy credentials and a decoy agent tool on the group AI platform.

# Illustrative: Hansa Mutual, deception/register/HM-DEC-0042.yaml
id: HM-DEC-0042
owner: detection-engineering
approvedBy: group-ciso
type: [decoy-user-credential, decoy-agent-tool]
placement:
  platform: group-ai-platform
  locations:
    - agent-tool-registry: tool "claims-bulk-export" (no manifest grants it)
    - secrets-store: path ai-platform/legacy/export-svc
content: {syntheticOnly: true, refreshDays: 90}
signal: {onUse: alert, severity: critical, route: soc-shift-lead, bypassTriage: true}
response:
  playbook: PB-DEC-003
  preApproved:
    - {action: revoke-calling-identity-sessions, autonomyLevel: 3, reversible: true}
    - {action: suspend-calling-agent, autonomyLevel: 3, reversible: true}
  requiresApproval: [isolate-platform-segment]
boundary: {estateOnly: true, collectFromCaller: platform-telemetry-only}
legal:
  worksCouncil: {DE: agreed, NL: agreed, SE: agreed}
  reviewedBy: group-legal
verification: SCE-DE-019

The entry joins the decoy, signal, pre-approved reversible actions, legal review and verifying experiment in one artefact.

The legal boundary

Deception and response stay within the organisation's own systems, or systems it is contractually authorised to defend. Accessing another party's systems without authorisation is treated as an offence under national criminal law, whoever started the exchange, and neither NIS 2 nor DORA provides an authorisation to do so (3, European Union, 2022) (2, European Union, 2022). The architectural implication is that no decoy, detection or playbook may contain a step that acts outside the estate.

Within that rule, a canary that only makes a passive request to an endpoint the organisation controls stays on the defensive side, whereas one that executes code on the opener's device crosses the line. A touched decoy produces data about whoever touched it, possibly a curious employee; such monitoring is subject to data-protection law, the GDPR first among it (9, European Union, 2016), and in many member states to consultation with employee representatives, which at Hansa Mutual means the works councils in Germany, the Netherlands and Sweden must agree before decoys on employee endpoints go live. Decoys must not lure employees into misconduct, for example with an apparently unprotected salary file in a widely browsed share. And a public authority classifies its decoy register so that decoy locations are not disclosed on request.

An agent acting on decoy alerts could propose an action outside the estate, such as probing the address that used a honeytoken; such actions are excluded at the policy decision point, in line with the scoped credentials that AI Platform and Security, Chapter 18, requires for defensive agents (73, Nordqvist, 2026), never left to the model's judgement (Chapter 7).

Applying the series' red threads

Commission Implementing Regulation (EU) 2024/2690 sets out requirements for monitoring and logging and for the assessment and classification of events for entities in its scope (4, European Commission, 2024), DORA Article 10 requires financial entities to have mechanisms to detect anomalous activities promptly (2, European Union, 2022), and AI Act Article 12 requires high-risk AI systems to technically allow the automatic recording of events (1, European Union, 2024). With control and obligation mappings, one tested rule is evidence for several of these obligations at once.

Across the usage modes

See usage modes.

Mode	Opportunity	Characteristic vulnerability	Who judges, with whose identity
Mode 0 Ambient AI	Vendor detection content and verdicts	Opaque logic the organisation cannot test	The vendor's model; the product's
Mode 1 Conversational assistants	Drafting rules and summarising reports	Telemetry or restricted intelligence pasted in	The analyst; the analyst's session
Mode 2 Embedded workplace assistants	Summaries in SIEM and ticketing tools	Summaries that drop hedges or grades	The analyst; delegated access
Mode 3 Agentic work tools	Coding agents build fixtures and tests	An agent with an engineer's credentials touching the repository	The reviewing engineer; the engineer's
Mode 4 Built AI applications	Drafting detections at scale, such as HM-SEC-002	Injection through threat reports; rules that never fire	The reviewer and pipeline tests; a service identity without deployment rights
Mode 5 Autonomous production agents	Own and attackers' agents caught by decoys	Own agents exceeding their mandate	The SOC, on the decoy signal; the agent's workload identity

Across the autonomy levels

See autonomy levels.

Level	Use in detection, intelligence and deception
Level 0 Advisory	AI proposes coverage gaps and decoy placements
Level 1 Assisted	AI drafts rules, tests and assessments; default for all detection change
Level 2 Supervised	The pipeline deploys a reviewed rule after explicit approval
Level 3 Bounded	Pre-approved, reversible responses to a decoy signal, with a person informed
Level 4 Autonomous	Not used; detection logic, exclusions and decoy placement are never changed without review

Verifying with security chaos engineering

Two experiments on the platform of Chapter 25 verify the chapter's capabilities.

• Honeytoken alert path. Condition injected: the actuator uses a registered decoy credential from a test identity in scope. Steady-state hypothesis: a critical alert reaches the SOC shift lead, bypassing triage, and the pre-approved response revokes the test identity's sessions. Time bound: alert within 5 minutes, response within 10, also out of hours.
• Detection regression. Condition injected: recorded output of a catalogued emulation is replayed through the production parser. Steady-state hypothesis: every rule covering the technique fires. Time bound: within one hour of deployment for new rules, and daily for the whole suite.

A failed hypothesis goes to the purple backlog until the experiment passes again (Chapter 26).

The three AI focus areas

Securing AI systems. Detections on gateway and tool-call logs, mapped to ATLAS, and decoys in AI systems detect attacks on them and agents exceeding their mandate (11, MITRE, n.d.) (20, NIST, 2025).

AI-enabled cyber defence. AI drafts detections, hunting hypotheses and decoy content that people review and tests verify.

Thwarting AI-enabled attacks. Deception sets tripwires for autonomous tooling that favours speed over stealth.

Nordvik Region and Hansa Mutual

Nordvik Region starts with mostly supplier default rules. Its first step is a small set of its own Sigma rules for payee changes, misuse of the staff identity provider and unusual use of the citizen-service assistant, drafted by two analysts with the approved enterprise assistant (Mode 1) without pasting telemetry into it, and reviewed by another analyst. It plants canary documents and honeytokens in case management, file shares and the citizen-service assistant's retrieval store, because a triggered decoy is a signal six analysts and the MSSP can act on quickly; out-of-hours decoy alerts go directly to the MSSP shift lead.

Hansa Mutual's detection-engineering team of four already works as code, with HM-SEC-002 drafting and an engineer approving every rule, and its intelligence cell of three grades every assessment in STIX. Its decoys on the group platform stay inside its estate in all seven markets and also watch its own Mode 5 agents. Nordvik thus replaces supplier defaults with signals it understands; Hansa shortens the time from report to tested detection.

Summary

Detection engineering, threat intelligence and deception make DE.CM Continuous Monitoring and DE.AE Adverse Event Analysis effective, and AI accelerates all three. Detections belong in version control with tests, mappings and a rationale; AI may draft them, but a person reviews the reasoning, and catalogued emulations and regression prove that they fire.

AI-assisted intelligence is structured in STIX with its markings intact and graded by analysts, never accepted on the strength of fluent prose. Deception gives the highest-confidence signals, registered as code, built from synthetic content, tied to pre-approved reversible responses and kept within the organisation's own systems.

The chaos experiments trigger a honeytoken and replay emulation data to verify both. Chapter 20 follows the alert once it becomes an incident.

Sources

1. NIST. The NIST Cybersecurity Framework (CSF) 2.0. (19, NIST, 2024)
2. National Institute of Standards and Technology. Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile). (20, NIST, 2025)
3. SigmaHQ. Sigma: Generic Signature Format for SIEM Systems. (32, SigmaHQ, n.d.)
4. MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (10, MITRE, n.d.)
5. MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for AI Systems. (11, MITRE, n.d.)
6. MITRE Corporation. MITRE D3FEND: A knowledge graph of cybersecurity countermeasures. (12, MITRE, n.d.)
7. OASIS Cyber Threat Intelligence. STIX Version 2.1 and TAXII Version 2.1. (24, OASIS Cyber Threat Intelligence (CTI) TC, 2021)
8. European Union Agency for Cybersecurity. ENISA Threat Landscape 2026. (34, ENISA, 2026)
9. Google Threat Intelligence Group. GTIG AI Threat Tracker: From Prompting to Autonomy – The Evolution of Adversarial AI. (48, Google GTIG, 2026)
10. Blum, Mainor, Nambiar et al. ARTEX and Friends: Enter Agentic Offensive Frameworks. (50, Blum et al., 2026)
11. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 (Artificial Intelligence Act). (1, European Union, 2024)
12. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (2, European Union, 2022)
13. European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2 Directive). (3, European Union, 2022)
14. European Commission. Commission Implementing Regulation (EU) 2024/2690. (4, European Commission, 2024)
15. Nordqvist, G. Architecture as Code. (71, Nordqvist, 2025)
16. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (72, Nordqvist, 2026)
17. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (73, Nordqvist, 2026)
18. 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 (General Data Protection Regulation). (9, European Union, 2016)
19. OpenAI. OpenAI – Hugging Face Incident Technical Report. (64, OpenAI, 2026)