By Cameron McClellan, Growth EngineerMost enterprises approaching AI security governance pick a framework and build a program around it. NIST AI RMF is the most common choice. It’s voluntary, credible, and audit-friendly. The problem is that NIST specifies no runtime controls. An organization can be fully NIST-aligned, with a completed AI inventory and a documented risk register, while its agents make ungoverned tool calls to production databases with no audit trail.
NIST AI RMF, MITRE ATLAS, and OWASP each address a different part of the problem. NIST is an organizational governance process. MITRE ATLAS is a living knowledge base of adversary tactics and techniques against AI-enabled systems. OWASP is a vulnerability taxonomy across three separate publications for different layers of the AI stack. Using any one as your complete AI security program leaves specific, predictable gaps.
This article maps all three: scope, audience, enforcement layer, and where each stops. It is a companion to What is AI security?, which covers the vendor and product landscape. The OWASP Agentic Top 10 is covered in depth in its own post: The OWASP Agentic Top 10, explained.
The table below maps all five publications across six capability dimensions.
NIST AI RMF is an organizational risk management process
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 to enumerate technical vulnerabilities or specify 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. It adds 12 GenAI risk categories and maps more than 400 suggested actions across the four functions. The categories most relevant to AI security are:
- Data Privacy — risks from training data handling and model outputs containing personal information
- Information Security — risks from unauthorized access, model misuse, and system compromise
- Value Chain and Component Integration — risks from third-party models, datasets, and tooling
The Information Security category mentions runtime controls like logging, access management, and output filtering, but does not specify what those controls must be or how to implement them.
NIST recognizes the gap. In February 2026, NIST’s Center for AI Standards and Innovation (CAISI) launched the AI Agent Standards Initiative to address agent-specific risks, with initial deliverables expected later in 2026. Until those land, the framework has no guidance on governing agentic AI at runtime.
NIST AI RMF does not specify runtime enforcement
NIST AI RMF specifies no prescriptive technical controls. There is no mandated tooling, certification, or enforcement mechanism, and no guidance on how to intercept a model call or attribute agent actions to specific users.
It is voluntary unless adopted by contract or sector regulator. The EU AI Act, for example, creates obligations for high-risk AI systems that sector regulators may satisfy by referencing NIST standards. 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 is an adversary threat catalog for AI systems
MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is a knowledge base of adversary tactics, techniques, and case studies targeting AI-enabled systems. Built on the model of MITRE ATT&CK, it maps tactics to techniques, which map to documented case studies of real-world adversary behavior.
ATLAS is developed through MITRE’s Secure AI initiative, a collaboration with funding research participants including Microsoft, CrowdStrike, JPMorganChase, and Siemens.
Version 5.1.0 (November 2025) is the current release. It includes:
- 16 tactics, 84 techniques, and 56 sub-techniques
- 32 mitigations, including Adversarial Input Detection, Model Hardening, and Segmentation of AI Agent Components
- 42 case studies drawn from real-world adversary activity
A collaboration with Zenity Labs in October 2025 added 14 agent-focused techniques, including AI agent context poisoning and exfiltration via agent tool invocation. ATLAS draws the majority of its tactics from ATT&CK and adds two AI-specific ones, AI Model Access and AI Attack Staging.
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.
MITRE ATLAS does not specify defender architecture
ATLAS is scoped to adversary behavior. Identity design, access control, governance processes, and compliance mapping are all outside its coverage. An organization that has mapped every ATLAS technique still needs separate answers to:
- who is authorized to call which tools
- how credentials are managed
- what constitutes a complete audit trail
Knowing the attacker playbook is a starting point, but ATLAS leaves the defensive infrastructure design entirely to the organization.
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 maps specific vulnerabilities across three layers of the AI stack
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 coverage spans three separate publications, one per layer:
- OWASP LLM Top 10 — the application layer. Covers risks including prompt injection, sensitive information disclosure, data and model poisoning, excessive agency, system prompt leakage, and unbounded consumption.
- OWASP Agentic AI Top 10 — the agentic layer. Covers risks including tool misuse, identity and privilege abuse, inter-agent communication vulnerabilities, cascading failures, and memory and context poisoning.
- OWASP MCP Top 10 — the protocol layer. Covers risks including token mismanagement, privilege escalation, tool poisoning, command injection, insufficient authentication, and gaps in audit telemetry.
This 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.
OWASP does not address organizational governance or compliance
As a vulnerability taxonomy, OWASP describes what can go wrong at each layer of the stack, without prescribing an organizational program for managing risk over time, mapping to regulatory frameworks, or creating accountability structures. A team that has implemented controls against every relevant OWASP category still has no compliance evidence and no governance process. That is NIST’s job.
Audience: Security engineers, architects, and platform teams building or governing AI applications and infrastructure.
Enforcement layer: Application, agentic, and protocol layers. Spans from the LLM gateway through the MCP gateway to agent hooks and identity.
No single framework is sufficient
An enterprise that adopts only one of these three frameworks will have specific, predictable gaps.
NIST AI RMF alone
NIST produces a governance process with no runtime controls. An organization that is fully NIST-aligned, with a completed AI inventory, documented risk register, and mapped GenAI risk categories, can still have agents making ungoverned tool calls to production databases with no audit trail. NIST specifies how to manage what you deploy, leaving the deployment decisions entirely to the organization.
MITRE ATLAS alone
ATLAS gives threat intelligence with no defensive architecture. Knowing that prompt injection chains and memory manipulation attacks exist is useful for detection engineering, but leaves open the harder questions:
- where in the stack to put the detection
- who is authorized to call which tools
- how to design the identity layer that makes access auditable
OWASP alone
OWASP 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
- a way to demonstrate due diligence to auditors and boards
OWASP publications are engineering references and carry no weight as compliance evidence.
Using all three together
A mature program draws from all three. NIST provides organizational process and accountability. MITRE provides threat intelligence and detection engineering. OWASP provides the specific controls to build at each infrastructure layer. The three frameworks are complementary because they address genuinely different parts of the same problem.
What each framework covers and what it misses
| 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, mapping specific vulnerability classes to the enforcement layer where each must be addressed, but stops short of prescribing implementations. In every case, the actual deployment of identity, gateway enforcement, audit logging, and agent hooks is left to the organization.
Enforcing these frameworks requires infrastructure at every layer
Each framework describes risk or process at a different layer, and enforcing that risk requires infrastructure at the same layer.
The AI control plane is the architecture that spans the full stack. It covers:
- Model calls, via an LLM gateway
- Tool calls, via an MCP gateway
- Runtime interception and tamper-evident audit logging
- A governance layer that maps to NIST’s four functions
The table below shows which layer each framework addresses and where enforcement infrastructure must fill the gap.
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.
- Production MCP deployments — start with the MCP gateway, the enforcement point for tool-call authentication, credential management, and schema validation.
- Model-call governance — start with the LLM gateway.
- AI governance initiative — start by mapping the existing stack against NIST’s four functions to surface what’s documented versus what’s actually enforced.
The AI control plane is what enforcement looks like when these frameworks are 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 is building the AI control plane, the enforcement infrastructure that all three frameworks require but none specifies.
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.