Most of what the earlier chapters of Part V and Part IV describe happens inside one organisation. The loop does not stay there. Its emulation may pass through a managed provider's pipeline or a cloud provider's platform, its observation may depend on a provider's tagged-event outcomes, its changes may have to be made by a supplier, its findings may concern a product that someone else built, and its evidence may be wanted by a peer group, a computer security incident response team (CSIRT) or a supervisor. This chapter treats the loop where it crosses the boundary of the organisation. It concerns P2 Emulate, because the stage that touches other people's systems needs their consent and a stop path they can use, P3 Observe, because what a provider or a peer sees is part of the evidence, and P4 Improve, because a change that belongs to someone else is a request and not a merge, and because a finding in someone else's product has to be disclosed.
The chapter builds on conclusions of the earlier volumes. Vendor AI inside a managed service is the Mode 0 blind spot, and its use and autonomy are established and required by contract before they are relied on (F57, AI Red Team, Chapters 8 and 28) (90, Nordqvist, 2026). Annex MS-2 turned that into six contract terms, and a contract right is only a promise until the first sample, seed or stop request shows that it works (F97 and F111, AI Blue, Chapters 7 and 16) (94, Nordqvist, 2026). Sovereignty is a set of verifiable properties and not a location (F47, AI Platform and Security, Chapter 13) (89, Nordqvist, 2026), and the July 2026 incident showed what happens when controls at a boundary share a dependency (F28, AI Governance, Chapter 19) (88, Nordqvist, 2026). Chapter 6 gave the rules of engagement for third parties in outline and Chapter 13 gave the injected test. This chapter adds the protocol that makes both usable across a boundary, the sector and disclosure paths, and the evidence a supervisor receives.
A test crosses a provider boundary in one of three ways, and they need different permissions. The distinction is the book's own, drawn from the cases in Chapters 6 and 13.
Primary topics explored
- Testing through a provider
- Consent and shared responsibility
- Sector exercises
- Sharing without exposing
- Disclosure
- Cross-border
About AI Purple
AI Purple is Book 9 of The Transformed Architecture. It takes the loop between the red team and the blue team as its subject and asks what happens when AI sits on both sides of the table: the five stages of the loop (target, emulate, observe, improve, verify), rules of engagement and safe emulation, continuous emulation, the independence principle, coverage as a claim that needs evidence, the loop's own AI and how to defend it, operating models, decision rights, regulation, and the people involved, for European enterprises and public authorities.
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 and AI Blue.
Chief information security officers, heads of security operations, red-team leads, penetration testers, SOC managers, detection engineers, purple-team coordinators and incident commanders, security and AI architects, boards and management bodies, procurement leads, works councils and unions, data protection and audit functions, and public-sector leaders.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 22: Across Boundaries: Suppliers, Managed Providers, Sector Exercises and Authorities in AI Purple gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Loop in the Organisation” and is one of 33 drawn from the manuscript.