Securing the AI Lifecycle

AI security is not static—risks evolve throughout the lifecycle of your system, and adversaries target different components at each phase.

This section provides lifecycle phase–specific security guidance that builds on the baseline controls and strengthens AI systems with additional safeguards tailored to each specific phase.

Whereas baseline controls describe what every system must have, the lifecycle controls describe how those safeguards should be implemented, expanded, or adapted as the system evolves.

Some controls, such as identifying boundaries or data provenance, will necessarily appear in multiple phases. This intentional redundancy reflects the reality that these safeguards must be applied differently at each stage and that gaps in any phase can undermine the entire system.

As with the baseline controls, this section defines the AI lifecycle in four stages:

  • Design: Secure your core inputs (algorithms, data, human talent, and compute).
  • Develop: Protect training environments, pipelines, and evaluation processes to stop vulnerabilities from propagating into production.
  • Deploy: Safeguard model weights, restrict unauthorized access, and harden APIs against exploitation.
  • Operate: Maintain continuous monitoring, input validation, and anomaly detection as your system interacts with real-world users and data.

Before delving into the detailed guidance, this section begins with a Cross-Lifecycle Control Table. This table shows where major control families recur across the lifecycle, helping users understand

  • which safeguards must be applied continuously, not just once
  • where additional or expanded controls are first introduced
  • why some controls appear multiple times in the detailed phase tables.

Presence of Security Controls Across the AI Lifecycle

Control Family Design Develop Deploy Operate
Identity, authentication, and access control ✔️ ✔️ ✔️ ✔️
Data governance and provenance ✔️ ✔️ ✔️ ✔️
Secure development and environment hardening ✔️ ✔️ ✔️ ✔️
Model and artifact integrity (including verification, signing, version control) ✔️ ✔️ ✔️ ✔️
Supply chain security (datasets, tools, dependencies) ✔️ ✔️ ✔️ ✔️
Confidentiality and secure storage (data, artifacts, logs) ✔️ ✔️ ✔️ ✔️
Input validation and sanitization ✔️ ✔️ ✔️ ✔️
Output monitoring and safety checks ➖ ✔️ ✔️ ✔️
Network segmentation, API hardening, and boundary controls ✔️ ✔️ ✔️ ✔️
Logging, auditing, and observability ✔️ ✔️ ✔️ ✔️
Evaluation, red‑teaming, and safety testing ✔️ ✔️ ✔️ ✔️
Secure deployment processes (attestation, continuous integration/continuous delivery [CI/CD] safeguards) ➖ ✔️ ✔️ ✔️
Runtime monitoring and anomaly detection ➖ ➖ ✔️ ✔️
Incident response and change management ✔️ ✔️ ✔️ ✔️
Decommissioning and lifecycle documentation ✔️ ➖ ➖ ✔️

✔ = control family appears in that lifecycle phase.

Figure 1, the Operational Viewpoint-1 (“OV-1”), provides a high-level overview of an AI system’s operation and environment based on forms of generative AI, reinforced ML, and neural networks. This OV-1 serves as a reference frame for understanding the security controls that follow and does not necessarily apply in its entirety to all systems, such as symbolic reasoners or expert systems that do not use model weights.

Figure 1. AI System Operational Viewpoint (OV-1)

NOTE: R&D = research and development.

The flow chart has four main sections in columns that move from left to right. The sections are:

  1. Design: Asset
  2. Development: Process
  3. Deployment: Asset
  4. Operation: Process

Design: Asset

There are four subsections under "Design: Asset," all of which point to the next column in the chart. The sections show:

  • Internal insights and open-source knowledge, which point to Algorithms.
  • External vendors, open source, and synthetic, which point to Data.
  • Software engineers, network engineers, and all researchers, which point to Human talent.
  • Accelerators, energy, and capital, which point to Compute, which can be either on-premises or cloud.

Development: Process

There is one overall box under "Development: Process" with three elements in it. The overall box points to the next column in the chart. The elements in the overall box are:

  • Pretraining, which points to
  • Instruction/fine-tuning, which points to
  • Evaluation

Other arrows indicate iteration between these three elements.

Deployment: Asset

There is one overall box labelled "Model weights" with three subsections in it. The overall box points to the next column in the chart. The elements in the box are:

  • Model weights
    • Open-source publishing
    • On-premises deployment
    • Cloud deployment

Operation: Process

There are two boxes in "Operation:Process." These are:

  • Integration into internal operations
    • R&D support
    • Automated decisionmaking
    • Threat monitoring
  • Integration into external operations
    • Model as a service
    • Inference as a service
    • Software as a service
    • Product integration

The remainder of this section walks phase by phase through the lifecycle, aligning concrete threats to their corresponding security controls. Using the OWASP and BIML threats and vulnerabilities, we calculated the weighted sum of these threats to determine which controls potentially reduce risk the most. As a result, these controls are listed in order of how much risk they could potentially reduce. Your organization’s risk profile may differ depending on threats and current security control configurations. Therefore, this prioritization is provided as a starting point for consideration. Each phase includes a detailed control table that expands on the baseline safeguards and provides actionable, phase-specific implementation guidance. Redundancy across these tables is intentional: The same control family may require different operational choices, tooling, or guardrails depending on where the system is in its lifecycle.

For the full, extended set of controls, see Appendix B.

Next: Design