OWASP AISVS turns AI security into verifiable requirements with three levels

A verification standard, not a checklist

The Artificial Intelligence Security Verification Standard is described as a community-driven catalogue of testable security requirements for AI-enabled systems.

The word verification is the important one, and it comes from the lineage. AISVS is modelled after the OWASP Application Security Verification Standard and follows the same philosophy: every requirement should be verifiable, testable, and implementable.

That philosophy is what separates it from a list of risks. A list of things that can go wrong with an LLM application is useful for awareness and useless for verification, because a risk entry has no pass condition. A verification requirement has one: you can write a test that passes or fails, and an auditor can ask for the evidence.

The scope is stated precisely. It gives developers, architects, security engineers, and auditors a structured framework to design, build, test, and verify the security of AI applications throughout their lifecycle, from data collection and model training to deployment, monitoring, and retirement.

The lifecycle framing matters in practice. A standard that stops at the deployed model misses the parts of an AI system that are not the model: the training data provenance, the pipeline that produced the weights, the retrieval store, the agent tooling, the monitoring. The chapter list reflects that scope.

The project was founded by Jim Manico, and current project leadership includes Jim Manico, Otto Sulin, Rico Komenda and Russ Memisyazici. The licence is CC BY-SA 4.0, which is the usual choice for an OWASP standard document, and the latest stable version is AISVS 1.01. The last push to the repository was on 2026-10-20, the same week as the 1.0 and 1.01 releases in October 2026.

What AISVS explicitly is not

The README has a section titled What AISVS is NOT, and it is the most useful section for anyone deciding whether this is the standard they need.

It is not a governance framework, because governance is well covered by NIST AI RMF, ISO/IEC 42001 and EU AI Act compliance guides.

It is not a risk management framework. AISVS provides the technical controls that risk frameworks point to, but does not define risk assessment methodology.

And it is not a tool recommendation list. AISVS is vendor-neutral and does not endorse specific products or frameworks.

That last one is worth dwelling on, because a requirements catalogue that named tools would age badly and would undermine the point of being vendor-neutral. The requirement is a property of the system, not of a product you can buy, and the absence of product names is what makes the standard usable as a procurement requirement rather than as a shopping list.

The complement table then places AISVS against the standards it sits next to. Against OWASP ASVS, whose focus is web application security, AISVS extends ASVS concepts to AI-specific threats. Against the OWASP Top 10 for LLMs, which is about awareness of top LLM risks, AISVS provides the detailed controls to mitigate those risks. The same relationship holds with the OWASP Top 10 for Agentic Applications and with NIST AI RMF, where AISVS supplies the testable technical controls that AI RMF references. Against ISO/IEC 42001, on AI management systems, AISVS complements with implementation-level security verification.

Read together, the pattern is that awareness lists and risk frameworks sit above, and AISVS sits underneath them as the layer that says what to actually build and test.

The three verification levels

Every requirement carries a verification level of one, two or three, and the levels are the mechanism that lets an organisation adopt the standard incrementally.

Level 1 is the essential baseline controls that every AI system should implement. The README says to use this level for all AI applications, including internal tools and low-risk systems.

Level 2 is the standard controls for systems handling sensitive data or making consequential decisions. The README places this at production systems, customer-facing AI, and systems processing personal data.

Level 3 is the advanced controls for high-assurance environments requiring defense against sophisticated attacks. The README places this at critical infrastructure, safety-critical AI, high-value targets and regulated industries.

The guidance on choosing is short and direct: organizations should select a target level based on the risk profile of their AI system, and most production systems should aim for at least Level 2.

That advice is the interesting part, because it implies that Level 1 alone is not sufficient for most real systems. A tool that ships with a baseline everyone should implement is a good adoption story, but the standard is telling you that most of the people using it should be doing more than the baseline, which is a healthier framing than either making everything mandatory or making everything optional.

The levels are also what make the standard auditable. An audit of an AI system becomes a question of which level the system was supposed to meet, and the requirement list for that level is the checklist. Without the levels, an audit would have to test everything in the standard, which is not a realistic project for most teams and would result in nothing being tested.

The twelve requirement chapters

The chapter list is the standard's table of contents, and reading it tells you what the authors consider the actual attack surface of an AI system.

The first three cover the data and the model. Chapter 1 is Training Data Integrity and Traceability. Chapter 2 is Input Validation. Chapter 3 is Model Lifecycle Management and Change Control.

Chapters 4 and 5 are the parts that would look familiar in any web application standard. Chapter 4 is Infrastructure, Configuration and Deployment Security, and Chapter 5 is Access Control and Identity for AI Components and Users.

Chapter 6 is Supply Chain Security for Models, which is where the weights themselves are treated as something you have to be able to account for.

Chapter 7 is Model Behavior, Output Control and Safety Assurance, and Chapter 8 is Memory, Embeddings and Vector Database Security, which covers the retrieval side of a RAG system.

The last four are the newest territory. Chapter 9 is Orchestration and Agentic Security, covering the case where the model can take actions. Chapter 10 is Model Context Protocol, or MCP, Security, which covers the protocol by which agents reach tools and context. Chapter 11 is Adversarial Robustness. And Chapter 12 is Monitoring, Logging and Anomaly Detection.

There are three appendices behind the chapters. Appendix A is a Glossary, Appendix B is an AI Security Controls Inventory, and Appendix C is AI-Assisted Secure Coding, which is the one most likely to interest an engineering team since it addresses how to use AI coding assistants without introducing new weaknesses.

Two of these chapters stand out for a reason worth naming. Chapter 8 treats the vector database as a security boundary, which follows from the fact that the retrieval store holds the content that shapes the model's answers. And Chapter 10 treats the protocol layer itself as the risk, since MCP is where an agent's capability to call tools is granted, and that grant is exactly what a prompt injection attempt is trying to obtain.

Where to get it and how to use it

The standard is distributed in two formats, and the README links both for version 1.01: a PDF, at the raw path AISVS-1.01.pdf under the 1.01/dist directory, and the Markdown source, browsable online under 1.01/en.

Reading the Markdown online is the more practical route for a working engineer, since it is the same content that produces the PDF and it links to the requirement files directly, with each chapter at a path of the form 0x10-C01 for the first chapter through 0x10-C12 for the twelfth.

The README's section on how to use AISVS lists four situations, and they are ordered by how early in the lifecycle they occur.

During design, use requirements as a security checklist when architecting AI systems.

During development, integrate requirements into CI/CD pipelines, code reviews, and testing.

During security assessments, use as a verification framework for penetration testing and audits.

For procurement, reference specific requirements when evaluating AI vendors and third-party models.

That last one is the use case that has grown the most with the standard's release history, and it is a genuine differentiator. When you are buying a model or a service, you can ask a vendor which AISVS level their product meets and point at the requirement text rather than asking a vague question about their security posture.

Behind every requirement there is a Research Wiki, and the README explains its purpose: for every requirement in the standard, it provides implementation context beyond the requirement text, in a table of columns describing what each one tells you.

The repository layout shows how the versioning works in practice. There are directories for 1.0, 1.01 and 1.02-dev, so the development version sits alongside the published ones rather than on a branch, and the MODELS.md file at the root records the models the project uses. There is also an AGENTS.md and a CLAUDE.md, which is a detail worth noting for a document project, because it tells you that the standard is being drafted with AI assistance in view, and Appendix C on AI-assisted secure coding is the counterpart in the standard itself.

Where AISVS fits, and where it stops

The comparison worth making is with the OWASP Top 10 for LLMs and with a certification body.

Against the OWASP Top 10 for LLMs, the difference is granularity and purpose. The Top 10 is an awareness artefact, ten categories you should know about, and it works because it is short enough that people read it. AISVS is the detailed control set underneath, at the granularity where a requirement can be tested. The README states that relationship directly, that the Top 10 is for awareness of top LLM risks while AISVS provides the detailed controls to mitigate those risks, and the same pairing is drawn with the Top 10 for Agentic Applications.

Against a certification body, the difference is that AISVS is a standard you can use without paying anyone to certify you. A verification standard is the input to an audit, and whether you then hire an auditor is a separate decision the standard does not make for you. That is what makes it usable by a team that cannot buy certification but has a customer who asks for evidence.

The limits are worth stating. It is a document, not a tool, so nothing here automates verification; the requirement text is only as testable as the interpretation your team brings to it, which is where the Research Wiki earns its place. It is young, at version 1.01, with 1.0 and 1.01 both released in the same week in October 2026 and a 1.02-dev directory already open, so the text will move and any requirement you map your controls to may be renumbered. And it does not do risk assessment, which the README is explicit about, so you still need a way to decide which level applies to which system.

What it does give you is a shared vocabulary for AI security that is specific enough to test and neutral enough to use in procurement. That is a narrower contribution than a governance framework, and for the layer it occupies, a more useful one.

The licence is CC BY-SA 4.0, which permits reuse and adaptation with attribution provided derivatives carry the same licence, so an organisation can adapt the requirement set into its own internal standard. The last push was on 2026-10-20 and the repository is not archived.

Editorial conclusion

AISVS suits a security engineer who needs something concrete to test against, since the standard is built around requirements that are verifiable, testable and implementable, and the three levels let an organisation pick a target that matches its risk profile rather than adopt everything at once. It is the wrong tool if you need a governance or risk methodology, because the README rules that out explicitly and points at NIST AI RMF and ISO/IEC 42001 for that, and it is the wrong tool if you want a list of recommended products, since the standard is vendor-neutral by design. Before you start, read the What AISVS is NOT section, because it sets the boundaries that prevent you from using it for the wrong purpose, and pick your level first, since the README says most production systems should aim for at least Level 2.

Frequently asked questions

Official sources

1. Issues
2. License: CC-BY-SA-4.0
3. OWASP/AISVS on GitHub
4. README
5. Releases