AI Platform and Security · Whitepaper

Chapter 9 · Data, Models and DevSecMLOps

Risks and Vulnerabilities Across the DevSecMLOps Loop

Key insights from Chapter 9 of "AI Platform and Security"

Author Conceived and directed by Gunnar Nordqvist; text written by AI agents under his direction.
Published 1 November 2026
Build number 2026.11
devsecmlops ai-security agentic-architecture digital-sovereignty
Figure 9.1: The stages of the loop that carry risk. Revision management connects to them, either as the cause of a failure or as the control that contains it. The table names the main risk at each stage.
Figure 9.1: The stages of the loop that carry risk. Revision management connects to them, either as the cause of a failure or as the control that contains it. The table names the main risk at each stage.

This chapter walks the loop of Chapter 8 stage by stage and sets out the risks large organisations actually meet, the documented incidents of 2024 to 2026 behind them, and the controls that contain them. Revision management gets particular weight, because most of the loop's risks are either caused by weak version control or contained by strong version control. The chapter also treats unmanaged skills as a risk class, maps the risks to ISO/IEC 27001:2022 Annex A, and closes with a risk register as code.

The chapter is written for defenders: what happened, why the control failed, and what prevents it, never how to reproduce an attack. Figures carry their month and year, because they age quickly. Three taxonomies sit behind the stage risks: NIST AI 100-2 E2025 on adversarial machine learning (144, Vassilev et al., 2025); MITRE ATLAS (28, MITRE, n.d.); and the OWASP lists for large language model and agentic applications (27, OWASP, 2025) (102, OWASP, 2025). This chapter applies them to the delivery loop, and refers to the July 2026 OpenAI–Hugging Face incident, which AI Governance, Chapter 19 tells in full.

Reading the incidents of 2024 to 2026 side by side, the same three failures recur. The first is the mutable reference, such as a Git tag or registry alias that can be pointed at different content while consumers keep trusting the name. The second is the shared CI cache that lets a low-privilege job plant content a release job later consumes. The third is the credential believed revoked but still valid. Immutable digests, isolated release workflows, signed provenance, and verified revocation address all three; provenance alone does not, as the dependency section shows. This synthesis is my interpretation of the cases below.

Primary topics explored

  1. How to read this chapter
  2. Revision management decides most outcomes
  3. Source control and CI
  4. AI coding assistants and agents in the loop
  5. Dependencies and package mirrors
  6. Data and training

About AI Platform and Security

AI Platform and Security is Book 3 of The Transformed Architecture. It shows how large European enterprises and public authorities build, secure and operate the platform on which artificial intelligence runs: data, models and DevSecMLOps, retrieval and agents, infrastructure and sovereignty, AI security engineering, evaluation, observability and cost.

The companion volume AI Governance covers risk management, governance, assurance, organisation and leadership; Architecture as Code supplies the underlying discipline.

Who should read this

Platform engineers, security architects, MLOps teams, 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 9: Risks and Vulnerabilities Across the DevSecMLOps Loop in AI Platform and Security gives the detailed explanations, practical examples and implementation patterns behind this summary.

This whitepaper belongs to “Data, Models and DevSecMLOps” and is one of 29 drawn from the manuscript.