NIST published the AI Risk Management Framework (NIST AI 100-1) in January 2023, organizing AI risk into four functions — Govern, Map, Measure, Manage — and it remains the closest thing the industry has to a common vocabulary for the problem. Since then the threat catalog has grown fast: MITRE ATLAS, modeled directly on the ATT&CK matrix, reached version 5.1.0 in November 2025 and now documents 16 tactics, 84 techniques, 56 sub-techniques, and 32 mitigations drawn from 42 real-world case studies, spanning model inversion, training-data poisoning, evasion, and RAG poisoning. OWASP's Top 10 for LLM Applications, revised in November 2024, still ranks prompt injection — both direct and indirect, via content the model ingests from the web or a document — as risk LLM01, and added two new categories: System Prompt Leakage and Vector/Embedding Weaknesses. What most of these frameworks share is a blind spot in practice, not in theory: teams read them cover to cover and then build a program that only covers one layer, usually the runtime prompt-injection layer, because that's the layer that produces headlines. This post lays out a lifecycle framework — model, data, deployment — for closing that gap, and grounds each layer in a specific, checkable risk pattern rather than a generic warning.
What does the model layer actually put at risk?
The model layer puts your environment at risk the moment a weights file is treated as inert data instead of executable code. PyTorch's default serialization format is Python's pickle module, and a pickle payload can embed a call to os.system or subprocess that runs the instant the file is deserialized — there is no sandbox step in between. This is not theoretical: it is the exact reason model-scanning tools map pickle findings to CWE-502 (unsafe deserialization) and CWE-94 (code injection), the same weakness classes used for any other untrusted-deserialization vulnerability. ONNX models carry a parallel but different risk — external-data references inside the model graph can point outside the model directory using ../ path segments, absolute paths, or UNC paths, which maps to CWE-22 (path traversal) and can be used to read or write files the loader never intended to touch. Beyond malicious payloads, MITRE ATLAS separately catalogs backdoor and trojan-trigger attacks, where a model behaves normally except on a specific attacker-chosen input pattern that forces a controlled output — a risk that only shows up under statistical testing of the weights, not casual inspection.
What does the data layer put at risk?
The data layer puts your organization at risk through what went into a model, not what the model does at inference time — and that risk is legal and reputational as much as it is technical. Fine-tuning a model on a dataset with an unclear or copyleft license can create downstream obligations nobody signed up for, and fine-tuning on regulated data — PII, PHI, PCI — without documented controls turns the model itself into a compliance artifact that needs the same handling as the source records. MITRE ATLAS documents training-data poisoning as a distinct tactic: an adversary who can influence even a small, targeted slice of training or fine-tuning data can shift model behavior in ways that are very hard to detect after the fact, because the poisoned examples look statistically unremarkable next to the rest of the corpus. The practical failure mode here is lineage loss — a team fine-tunes a model, ships it, and eighteen months later cannot answer "which dataset snapshot produced this checkpoint, and what license did it carry?" without archaeology through old training scripts and Slack threads.
What does the deployment layer put at risk?
The deployment layer puts you at risk through how a model is invoked in production, which is where OWASP's LLM Top 10 concentrates most of its attention. LLM01, prompt injection, now explicitly covers indirect injection — an attacker doesn't need access to your prompt at all if the model reads a web page, PDF, or email that contains hidden instructions and your application later acts on the model's output. The November 2024 revision added System Prompt Leakage as its own category, reflecting how often system prompts contain business logic, credentials, or internal tool names that a sufficiently persistent user can coax the model into revealing verbatim. Agentic deployments compound this: once a model can call tools, a successful injection doesn't just produce a bad answer, it can trigger an unauthorized action — a file write, an API call, a database query — through a tool surface the developer assumed only trusted logic would invoke. Shadow AI adds a fourth failure mode at this layer: models and API keys provisioned outside any inventory, invisible to every control built for the sanctioned deployment path.
How do NIST AI RMF, OWASP, and MITRE ATLAS fit together?
These three frameworks fit together as different altitudes of the same problem, not competing standards. NIST AI RMF operates at the governance altitude: Govern sets accountability and policy, Map establishes context for a specific system, Measure quantifies the risks that Map identified, and Manage allocates resources and response — it tells you what a program should look like but not which specific attacks to test for. OWASP's LLM Top 10 operates at the application altitude, giving developers a concrete, rankable checklist — prompt injection, insecure output handling, system prompt leakage — that maps naturally onto the deployment layer. MITRE ATLAS operates at the adversary altitude: it documents actual tactics, techniques, and 42 real-world case studies, giving red teams and detection engineers a common vocabulary for what an attack looks like in telemetry, the same role ATT&CK plays for conventional intrusions. A mature program uses NIST AI RMF to structure the program, OWASP to scope the deployment-layer checklist, and ATLAS to build detections and test cases — using only one leaves the other two altitudes uncovered.
How should a team actually operationalize a lifecycle-wide program?
Operationalizing a lifecycle-wide program means treating model weights and datasets as inventoried, versioned artifacts with the same rigor applied to source code and open-source dependencies — because the underlying supply-chain problem is identical. That starts with an inventory: every model in use, where its weights came from, whether they're signed, and what dataset and license lineage produced any fine-tune, captured in a queryable format such as a CycloneDX ML-BOM or the SPDX 3.0 AI profile rather than a spreadsheet someone updates quarterly. On top of inventory, static checks at load time — scanning pickle, PyTorch, safetensors, GGUF, and ONNX artifacts for hidden code-execution instructions before they ever run — catch the model-layer risk before it becomes an incident, the same way SCA and SAST catch a vulnerable dependency before it ships. Safeguard's AI-BOM and AI-SPM capabilities apply exactly this pattern: they capture weight provenance, signing status, and fine-tune lineage as a signed attestation, statically scan model files across those five formats for CWE-502, CWE-94, and CWE-22 findings, run statistical backdoor detection on weights, and enforce load-time policy so unsigned or unsafe weights simply don't load in production — closing the model and data layers with the same discipline OWASP and ATLAS demand for the deployment layer.