A practitioner who has to test a defence, or an AI system, on purpose needs a small number of tools before anything else: a signed statement of what may be done and who may stop it, a plan that says what will be done and what the defence is expected to do about it, a way to execute the plan safely, and a record in which the result can be read by the people who must change something. This chapter collects those tools. It serves the activity of authorised testing: adversary emulation against an organisation's defences, and AI red teaming of the organisation's own AI systems. Both are defensive in purpose. Every activity described here is authorised, scoped by written rules of engagement, run against the organisation's own or contracted systems and ends in a defensive improvement; the chapter gives no attack tooling, exploit code, payloads or test inputs, and the tools it describes contain none.
The chapter treats all four kinds of tool. The artefacts are the rules-of-engagement manifest, the emulation plan, the campaign plan, the pipeline definition and the finding record. The methods are the practical guides of AI Red Team and AI Purple for preparing a safe run, running a campaign and keeping a continuous pipeline, together with the seven-class outcome taxonomy. The third-party tools and standards are the threat-led testing framework TIBER-EU, the two open emulation libraries Atomic Red Team and MITRE Caldera, the class of breach-and-attack simulation products and the published testing rules of three cloud providers. The own tools of the series in this field are artefacts, not software: the repositories ship no emulation engine, and the chapter says so where it matters. The tools come mainly from AI Red Team (Chapters 7, 12 and 13, and Appendix A) (4, Nordqvist, 2026) and AI Purple (Chapters 6 to 9 and Appendix A) (9, Nordqvist, 2026), with smaller contributions from AI Platform and Security (3, Nordqvist, 2026), The Transformed Security Architect (6, Nordqvist, 2026) and AI Blue (8, Nordqvist, 2026).
Figure 11.1 shows the order in which the tools are used. The rules of engagement come first and the white team's signature opens the window; the plan binds each step to the rules; execution passes through a policy decision point that sits outside the executor; and the result leaves as a finding that ends in a defensive change and, in Chapter 14, a regression case.
Primary topics explored
- Rules of engagement
- Emulation plans
- Continuous emulation
- Testing AI systems
- Reading and reporting results
- Treatment of the slice
About Tools
Tools is a companion to The Transformed Architecture. It collects the tools that Books 1 to 10 describe in one reference, organised by what the practitioner is doing: artefacts (templates, manifests, records), own tools, third-party tools and standards, and methods. Each entry says what a tool is for, when to use it, what it needs and produces, and where the book that defines it explains the reasoning. The book covers choosing, adopting and retiring tools, architecture and delivery, governing AI, securing and testing, operating, agents and autonomy, and people, organisation and society, for European enterprises and public authorities. It comes with a template library, an inventory, three web tools and the Toolbox Maturity Method.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss, AI Blue, AI Purple and AI Operations.
Architects and security architects, CIOs and CISOs, platform and operations leads, heads of governance, risk, compliance and third-party risk, AI governance and AI platform teams, red, blue and purple team leads, boards and management bodies, procurement and vendor managers, supervisors and auditors, works councils and unions, data protection officers, and public-sector leaders.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 11: AI Red Teaming and Emulation Tools in Tools gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “Securing and Testing” and is one of 29 drawn from the manuscript.