By Cameron McClellanSecurity teams picking an AI security framework in 2026 are choosing between three distinct approaches with almost no overlap. NIST AI RMF is an organizational governance process. MITRE ATLAS is an adversary threat catalog. OWASP is a practitioner-facing vulnerability taxonomy, maintained across three separate publications for different layers of the AI stack. None of them address the same problem. Using any one as your complete AI security program leaves real, specific gaps in your coverage.
This piece maps all three side by side: scope, audience, enforcement layer, and where each stops. It is a companion to What is AI security?, which maps the vendor and product landscape. The OWASP Agentic Top 10 is covered in depth in its own post: The OWASP Agentic Top 10, explained.
NIST AI Risk Management Framework
AI RMF 1.0 was published in January 2023. It is voluntary, non-regulatory, and sector-agnostic. Its purpose is to give organizations a structured process for identifying, assessing, and managing AI risk — not a catalog of technical vulnerabilities or a list of controls to deploy.
The framework organizes AI risk management into four functions:
- Govern. Establish organizational practices, policies, and accountability structures for AI risk.
- Map. Categorize AI systems, identify context and stakeholders, and enumerate risks associated with each system.
- Measure. Analyze, assess, benchmark, and monitor AI risks using qualitative and quantitative methods.
- Manage. Prioritize, respond to, and document actions taken to address identified risks.
The GenAI Profile (NIST AI 600-1), published July 2024, extends the framework to generative AI specifically. It formalizes 12 GenAI risk categories — including Data Privacy, Information Security, and Value Chain and Component Integration — and maps more than 200 suggested actions across the four functions. The Information Security category gestures toward runtime controls like logging, access management, and output filtering, but without specifying what those controls must be or how they must be implemented.
In February 2026, NIST’s Center for AI Standards and Innovation (CAISI) launched the AI Agent Standards Initiative, with initial deliverables expected later in 2026.
Where NIST AI RMF stops
NIST AI RMF specifies no prescriptive technical controls. It does not mandate tooling, certification, runtime governance, or enforcement mechanisms. It does not describe how to intercept a model call, enforce tool-call policy, detect prompt injection in production, or attribute agent actions to specific users.
It is voluntary unless adopted by contract or sector regulator. An organization can satisfy NIST AI RMF entirely through documentation and governance process without deploying a single runtime control.
Audience: Governance, risk, compliance, and AI leadership teams.
Enforcement layer: Organizational / process. NIST provides the accountability structure but does not prescribe the infrastructure that enforces it.
MITRE ATLAS
MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is a knowledge base of adversary tactics, techniques, and case studies targeting AI and ML systems — the AI equivalent of MITRE ATT&CK. Tactics map to techniques, which map to documented case studies of real-world adversary behavior.
ATLAS launched with founding contributors including Microsoft, IBM, Bosch, and NVIDIA, and is now maintained through MITRE’s Secure AI collaboration with a broader set of enterprise partners. Version 5.1.0 (November 2025) includes 16 tactics, 84 techniques, 56 sub-techniques, 32 mitigations, and 42 case studies. A collaboration with Zenity Labs in October 2025 added 14 agent-focused techniques and sub-techniques, including AI agent context poisoning and exfiltration via agent tool invocation. ATLAS draws the majority of its tactics from ATT&CK and adds ML-specific ones: ML Model Access, ML Attack Staging, and AI-tuned variants of Discovery and Resource Development.
For blue teams, ATLAS is the most direct input to detection engineering: it tells you which adversary techniques to instrument against and what events to capture. Its 32 mitigations — input filtering, adversarial training, model sandboxing — are directional starting points, not prescriptive controls.
Where MITRE ATLAS stops
ATLAS describes adversary behavior, not defender architecture. It does not cover identity design, access control, governance processes, or compliance mapping. An organization that builds every ATLAS-suggested mitigation still needs separate answers to questions like: who is authorized to call which tools, how are credentials managed, and what constitutes a complete audit trail.
Audience: Red teams, threat-intelligence practitioners, security engineers building detection rules.
Enforcement layer: Threat model / detection. ATLAS informs what to detect; the enforcement infrastructure must be built separately.
OWASP
The Open Worldwide Application Security Project takes an engineer-first approach to AI security. Unlike NIST (governance process) and MITRE (adversary behavior), OWASP enumerates specific vulnerability classes at each layer of the AI stack and maps what must be defended against at each point.
OWASP’s AI security scope spans three layers. At the application layer, the framework addresses how model calls go wrong: prompt injection, sensitive information disclosure, data and model poisoning, excessive agency, system prompt leakage, and unbounded consumption. At the agentic layer, it addresses the threat categories that emerge when agents operate with tools, persistent memory, and multi-step plans — tool misuse, identity and privilege abuse, inter-agent communication vulnerabilities, cascading failures, and memory and context poisoning. At the protocol layer, it addresses risks specific to how agents connect to external tools and data sources: token mismanagement, privilege escalation, tool poisoning, command injection, insufficient authentication, and gaps in audit telemetry.
This coverage is the most prescriptive of the three frameworks. OWASP names specific vulnerability classes, describes the attack pattern, and maps each risk to the enforcement layer where it must be addressed.
Where OWASP stops
OWASP is a vulnerability taxonomy. It describes what can go wrong at each layer; it doesn’t prescribe an organizational program for managing risk over time, map to regulatory frameworks, or create accountability structures. For compliance evidence and governance process, that is NIST’s lane.
Audience: Security engineers, architects, and platform teams building or governing AI applications and infrastructure.
Enforcement layer: Application → system → protocol. Spans from the LLM gateway through the MCP gateway to agent hooks and identity.
What each framework gives you
| NIST AI RMF | MITRE ATLAS | OWASP | |
|---|---|---|---|
| Core purpose | Organizational governance process | Adversary threat intelligence | Vulnerability taxonomy |
| Key question | ”Are we managing AI risk responsibly?" | "What will attackers do to our systems?" | "What can go wrong at each layer of the stack?” |
| Primary output | Risk register, accountability documentation, AI inventory | Adversary technique catalog, detection engineering inputs | Control requirements mapped to each layer of the AI stack |
| Who uses it | GRC, AI leadership, boards | Red teams, threat-intel practitioners, security engineers | Platform engineers, architects, security teams |
| Regulatory value | Yes — structured evidence for auditors | No | No |
| Runtime enforcement | Not addressed | Not addressed | Mapped by layer; implementation not prescribed |
The last row highlights the enforcement gap each framework leaves. NIST tells you to govern your runtime controls but doesn’t specify what they are. MITRE tells you which adversary techniques to instrument against but not where in the stack to put the instrumentation. OWASP goes furthest — it maps specific vulnerability classes to the enforcement layer where each must be addressed — but stops short of prescribing implementations. In every case, the actual deployment — identity layer, gateway enforcement, audit logging, agent hooks — is left to the organization.
No single framework is sufficient
An enterprise that adopts only one of these three frameworks will have specific, predictable gaps.
NIST AI RMF alone produces a governance process with no runtime controls. An organization that is fully NIST-aligned — documented risk register, completed AI inventory, mapped GenAI risk categories — can still have agents making ungoverned tool calls to production databases with no audit trail. NIST doesn’t specify what to deploy; it specifies how to manage what you deploy.
MITRE ATLAS alone gives threat intelligence with no defensive architecture. Knowing that prompt injection chains and memory manipulation attacks exist tells you what to detect. It doesn’t tell you where in the stack to put the detection, who is authorized to call which tools, or how to design the identity layer that makes access auditable.
OWASP alone gives precise vulnerability taxonomy with no organizational governance. A team that has implemented controls against every relevant OWASP category still needs an accountability structure, a risk management process, and a way to demonstrate due diligence to auditors and boards. OWASP publications are not compliance evidence; they are engineering references.
A mature program draws from all three: NIST for organizational process and accountability, MITRE for threat intelligence and detection engineering, and OWASP for the specific controls to build at each infrastructure layer. The three frameworks are complementary by design — not because they were coordinated, but because they address genuinely different parts of the same problem.
The architectural answer
Each framework describes risk or process at a different layer. Enforcing that risk requires infrastructure at that layer.
The AI control plane is the architecture that spans the full stack: a shared identity foundation beneath model calls (via an LLM gateway or agent hooks architecture) and tool calls (via an MCP gateway), providing runtime interception, tamper-evident audit logging, and an organizational governance layer that maps to NIST’s four functions. Speakeasy is building this control plane as a unified platform — the first to address both the model and tool call layers — with enterprise controls still in active development.
The practical starting point for most enterprises is the layer where exposure is most immediate. For organizations with production MCP deployments, that’s the MCP gateway — the enforcement point for tool-call authentication, credential management, and schema validation, where AI infrastructure vulnerabilities are most actively concentrated. For organizations primarily concerned with model-call governance, it’s the LLM gateway. For organizations running an AI governance initiative, it’s mapping the existing stack against NIST’s four functions to surface what’s documented versus what’s actually enforced.
The frameworks in this piece are the map. The AI control plane is what enforcement looks like when that map is turned into deployed infrastructure. For the full vendor and product landscape across all five enforcement layers, see What is AI security?.
A note on Speakeasy
Speakeasy builds the AI control plane — the enforcement infrastructure that all three frameworks require but none specifies.
All three frameworks exist to help organizations navigate the same challenge: secure and controllable AI adoption. Speakeasy is building the AI control plane to enforce the policies these frameworks help organizations define. The MCP gateway enforces tool-call authentication, access policy, and credential management on every agent-to-tool interaction. The LLM gateway governs model calls. Agent hooks intercept tool execution at runtime. Tamper-evident audit logging covers the audit trail that NIST’s Manage function requires but doesn’t specify how to build.
The AI control plane is the reference architecture that maps this enforcement infrastructure across all three frameworks.