AI Red Team · Whitepaper

Chapter 19 · Detect

Detection Engineering, Threat Intelligence and Deception as Code

Key insights from Chapter 19 of "AI Red Team"

Author Conceived and directed by Gunnar Nordqvist; text written by AI agents
Published 2 November 2026
Build number 2026.11
ai-red-teaming ai-enabled-defence purple-teaming security-operations nist-csf-2
Figure 19.1: Detection as code from intelligence through drafting, review and test to alerts, with deception signals.
Figure 19.1: Detection as code from intelligence through drafting, review and test to alerts, with deception signals.

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).

Primary topics explored

  1. Detections as code
  2. From report to tested detection
  3. Threat intelligence with AI
  4. Deception: honeytokens, canaries and decoys
  5. The legal boundary
  6. Applying the series' red threads

About AI Red Team

AI Red Team is Book 4 of The Transformed Architecture. It shows how large European enterprises and public authorities put artificial intelligence to work as an active part of cyber defence: AI-assisted red teaming and adversary emulation, red teaming of AI systems themselves, the AI-assisted security operations centre, detection engineering, threat intelligence, incident response and purple teaming, all under a lawful mandate and with evidence a supervisor can inspect.

It builds on the conclusions of Architecture as Code, AI Governance and AI Platform and Security.

Who should read this

CISOs, SOC leads, red and blue team practitioners, security architects, AI architects and technical decision-makers.

Portrait of Gunnar Nordqvist

Gunnar Nordqvist

Conceived, directed and published the books of The Transformed Architecture.

Continue with the full chapter

Read the full chapter online

Chapter 19: Detection Engineering, Threat Intelligence and Deception as Code in AI Red Team gives the detailed explanations, practical examples and implementation patterns behind this summary.

This whitepaper belongs to “Detect” and is one of 32 drawn from the manuscript.