I've been working for twenty years in banking. One thing that this time taught me is that compliance and security frameworks don't exist for bureaucratic reasons, they exist because someone, at some point, paid a steep price for not having them.
When I moved into generative AI and started building LLM systems for production, my first instinct was to look for the equivalent. I wanted to understand what the industry had already developed to avoid paying that same price in a new category of systems. What I found was a fragmented but coherent landscape. Seven distinct frameworks, each approaching the problem from a different angle. None sufficient on its own. Together, something close to a map.
This series documents how I applied that map to a real production system. But before getting into specifics, it's worth understanding what each framework actually covers, and more importantly: what it doesn't.
Why LLM systems need their own map#
The reasonable question is: why not use the security and governance frameworks that already exist?
The short answer is that LLM systems have properties that traditional frameworks weren't designed to handle:
Emergent behavior: these systems don't follow a deterministic flow. The model receives context and decides what to do (which tools to call, what to say, how to interpret ambiguous instructions). Even when the user input looks the same, behavior can change depending on retrieved context, conversation history, tool state, model version, and decoding configuration.
Semantic attack surface: attacks happen in natural language, not in network packets. An adversary doesn't need to exploit a software vulnerability, they need to construct a sentence that makes the model act in unintended ways. This is a category of attack that IT security frameworks simply didn't catalog until recently.
Opaque third-party dependency: system behavior depends on a model you didn't train, that can be updated without notice, whose internal logic you can't inspect. There are analogues in cloud services and managed SaaS platforms, but model behavior introduces a different kind of dependency: one where the logic is not fully inspectable and may change across model versions.
Direct impact on people: an LLM agent that mediates decisions affecting customers (recommendations, approvals, information) affects people in ways a CRUD system doesn't. That activates ethical and regulatory obligations that traditional security frameworks don't address.
The seven frameworks I'll describe each respond to these problems, just from different directions.
The seven frameworks#
NIST AI RMF 1.0: The process framework#
The National Institute of Standards and Technology published the AI Risk Management Framework in January 2023. It's the broadest of the seven, and deliberately the least prescriptive.
The AI RMF doesn't tell you what to do. It tells you how to think about the problem. It organizes AI risk management into four continuous functions:
GOVERN: who is accountable for the system, what values and policies guide its development and operation, and how decisions about the system get made.
MAP: identifying and contextualizing risks: who could be affected, under what circumstances, with what probability and impact.
MEASURE: defining metrics for the identified risks and monitoring them continuously.
MANAGE: responding to risks that materialize: mitigate, transfer, accept, or avoid.
The central point of the AI RMF is that these four functions aren't project phases, they're ongoing practices across the entire system lifecycle. A system that was evaluated during development but isn't monitored in production isn't managing its risk, it's ignoring risk with documentation.
Where it helps: specific technical controls. It's a process framework, not an implementation guide, and to know what to actually build, you need the other frameworks.
ISO/IEC 42001:2023: The management system#
ISO/IEC 42001 is the first international standard for an AI management system specifically. Published in December 2023, it's auditable, organizations can pursue certification against it.
The difference from the AI RMF is the level of formalism. Where the RMF prescribes functions and practices, ISO 42001 prescribes clauses with specific documentation, policy, and evidence requirements.
The requirements most relevant to LLM systems in production:
Clause 5.2 AI Policy: the organization needs a documented policy declaring its principles and commitments regarding AI use. Not a technical document, but a governance statement approved at the leadership level.
Clause 8.2 AI System Impact Assessment: for systems affecting people, the organization must formally evaluate the impact, including vulnerable populations, potential biases, and recourse mechanisms.
Clause 9.1 Monitoring and Measurement: AI system performance needs to be measured continuously with defined metrics, not just evaluated during development.
Where it stops: it prescribes that evidence must exist, but says nothing about how to build the systems that produce it. An LLM agent can be in full conformance with ISO 42001 and still be technically insecure.
OWASP LLM Top 10 (2025): The model attack surface#
The Open Web Application Security Project published the first LLM Top 10 in 2023 and updated it in 2025. It's the most widely referenced taxonomy of vulnerabilities in LLM systems.
The categories most relevant to production LLM systems include:
LLM01 Prompt Injection: the adversary manipulates model input to make the system follow unauthorized instructions. The most insidious variant is indirect prompt injection, where the attack doesn't come directly from the user's message, but from content the system retrieves from external sources: documents, search results, API data, or tool responses.
LLM02 Sensitive Information Disclosure: the model or the surrounding application exposes information it shouldn't, including user data, system context, internal instructions, or sensitive data retrieved during execution.
LLM05 Improper Output Handling: LLM output is passed to downstream systems without adequate validation, sanitization, or authorization. If the model generates code, SQL, API parameters, or commands that are executed without checks, whoever influences the output can influence the execution.
LLM09 Misinformation: the model generates factually incorrect information with confidence. In decision contexts such as financial services, healthcare, or legal support, that error can affect real people.
What it doesn’t give you: it catalogs threats but doesn't prescribe architecture. Knowing prompt injection exists doesn't tell you how to structure a system to resist it. For that, you need the controls frameworks.
OWASP Agentic Top 10 (2026): The agent attack surface#
The OWASP Top 10 for Agentic Applications 2026, published in December 2025, recognizes that systems with LLM agents carry a distinct risk category from simple LLM systems.
The fundamental difference: in a simple LLM system, the model generates text. In an agentic system, the model makes decisions that have effects in the world, calling APIs, accessing databases, sending messages, modifying records. The blast radius of a wrong decision is completely different.
The most relevant risks from the Agentic Top 10:
Inadequate authorization: the agent executes actions with more privilege than it should have. In a multi-agent system with a supervisor and subagents, a compromised agent can escalate privileges to access resources it shouldn't.
Excessive trust in other agents' outputs: in a pipeline where agents communicate, a malicious or compromised agent can send instructions disguised as legitimate results to downstream agents.
Persistent memory and context as an attack vector: state the agent maintains between interactions can be poisoned in one turn and exploited in another. Stateful systems have an attack surface that stateless systems don't.
The gap it leaves: like the LLM Top 10, it catalogs without prescribing. And being the most recent of the seven frameworks, it still has thinner coverage of edge cases in complex systems.
NIST SP 800-53r5: The security controls catalog#
NIST Special Publication 800-53 revision 5 is the security and privacy controls catalog for US federal information systems, but it's widely adopted beyond the federal context as a controls reference.
Organized into families (AC: Access Control, AU: Audit and Accountability, SI: System and Information Integrity, among others), 800-53r5 prescribes what systems should do to be secure.
The translation to LLM systems isn't direct, the framework was written for deterministic systems. But the control families do map across:
AC - Access Control applies to the fact that the LLM decides which tools to call. Least privilege means the tools accessible to the model should be strictly necessary, and the model should never have direct access to credentials.
AU - Audit and Accountability applies to the immutable record of what the system decided, not just what happened, but which parameters were passed to which tools, with what results.
SI - System and Information Integrity applies to output validation: the response the LLM generates needs to be validated before delivery, not just the input received.
What still needs to be designed: the SI control family has no specific control for semantic validation of LLM output. You can implement SI-15 (Information Output Filtering), but you'll need to interpret it for the context of natural language.
CIS v8.1: The prioritized critical controls#
The Center for Internet Security Controls version 8.1 defines 18 Critical Security Controls prioritized by impact. Where NIST SP 800-53r5 is comprehensive, CIS v8.1 is focused. It answers "if you can only do 18 things, do these."
The most relevant controls for LLM systems:
CIS Control 3 Data Protection: customer data passing through LLM context needs to be treated with the same data protection policies as any other system. The fact that the data only exists for the duration of an inference doesn't exempt it from protection obligations.
CIS Control 8 Audit Log Management: centralized logs, synchronized timestamps, retention appropriate to the risk, and protection against modification. In an LLM system, this includes logs of model decisions, not just infrastructure logs.
CIS Control 16 Application Software Security: security in development and dependencies. For LLM systems, this includes the model supply chain, where it comes from, how it was validated, who can update it.
What CIS v8.1 doesn't solve: it's an IT security framework applied to AI by extension. It has no specific controls for the semantic attack vectors in the OWASP LLM Top 10.
MITRE ATLAS: The adversarial AI knowledge base#
MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is to AI systems what MITRE ATT&CK is to traditional IT - a knowledge base of tactics, techniques, and procedures used by adversaries to attack machine learning and AI systems.
The difference from OWASP is the level of detail about attackers and their methods. Where OWASP categorizes vulnerabilities, MITRE ATLAS documents:
Tactics: the adversary's objective at each attack phase (reconnaissance, initial access, persistence, exfiltration)
Techniques: how the adversary achieves each tactic (training data poisoning, inference-time input manipulation, model extraction)
Procedures: documented instances of how techniques were used in real attacks
MITRE ATLAS is particularly useful for threat modeling. By structuring "who are the adversaries, what are their objectives, and how do they attack," you can prioritize controls based on real threats rather than abstract hypotheticals.
What MITRE ATLAS doesn't solve: like the other threat-based frameworks, it catalogs without prescribing mitigations. It's a map of where attacks come from, not a manual for building defenses.
How the seven fit together#
The temptation is to treat these frameworks as redundant, seven ways of saying the same thing, but they're not.
Each one has a different perspective on the same system:
NIST AI RMF 1.0 answers: how does the organization manage risk across the lifecycle?
ISO/IEC 42001 answers: what evidence can the organization present that it manages AI responsibly?
OWASP LLM Top 10 answers: what are the most common vulnerabilities in LLM systems?
OWASP Agentic Top 10 answers: what additional risks emerge when the LLM can act in the world?
NIST SP 800-53r5 answers: what technical controls should the system implement?
CIS v8.1 answers: which controls are most critical, prioritized by impact?
MITRE ATLAS answers: how do real adversaries attack AI systems?
A system using only OWASP knows its vulnerabilities but has no management process. A system using only the AI RMF has process but no guidance on which threats to address. A system using only ISO 42001 has documentation but may lack technical controls entirely.
For the type of system I was working on, I needed all seven perspectives.
What this series covers#
In the following articles, I apply these frameworks to a conversational agent with tool access, persistent state between turns, and integration with external systems, the kind of system many organizations are now deploying at scale, often without the full map.
I'll show where the frameworks help, where they leave genuine gaps, and what practitioners building these systems need to decide on their own because regulation hasn't arrived there yet.
Two decades in banking taught me that compliance frameworks exist because someone paid the price of not having them. In generative AI, that price is still being discovered. But the frameworks we have today are enough to avoid starting from zero.
Sources and references:
NIST AI RMF 1.0: https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
ISO/IEC 42001:2023: https://www.iso.org/standard/42001
OWASP Agentic Top 10 (2025): https://owasp.org/Top10/2025/
OWASP Agentic Top 10 (2026): https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
NIST SP 800-53r5: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
CIS v8.1: https://www.cisecurity.org/controls/v8-1?utm_source=chatgpt.com
MITRE ATLAS: https://atlas.mitre.org/