OWASP AISVS 1.0: a testable checklist for verifying AI application security

What is this?

The AI Security Verification Standard (AISVS) is a community-driven OWASP project that turns AI security from a set of aspirational principles into a checklist you can actually test. OWASP published the first stable release, AISVS 1.0, on 24 June 2026 (per the official project page; the LRQA analysis is dated 29 June 2026); it is licensed CC BY-SA 4.0 and was founded by Jim Manico, with current leadership including Otto Sulin, Rico Komenda, Russ Memisyazici and Raza Sharif. The design is explicitly modeled on the long-running OWASP Application Security Verification Standard (ASVS): every entry is written to be verifiable, testable, and implementable, so an auditor, penetration tester, or CI/CD pipeline can mark it pass or fail rather than debate it. Crucially, OWASP says what AISVS is not: it is not a governance framework, not a risk-management methodology, and not a tool-recommendation list. It supplies the technical control layer that frameworks like NIST AI RMF, ISO/IEC 42001, the OWASP Top 10 for LLM Applications, and the OWASP Top 10 for Agentic Applications point to but do not themselves specify.

How it works

AISVS 1.0 is organized into 14 requirement chapters spanning the full AI lifecycle: training-data integrity and traceability, input validation, model lifecycle and change control, infrastructure and deployment security, access control and identity, supply-chain security for models and data, model behavior and output control, memory/embeddings/vector-database security, autonomous orchestration and agentic action, Model Context Protocol (MCP) security, adversarial robustness, privacy and personal-data management, monitoring and logging, and human oversight. Each requirement carries a verification level from 1 to 3 — Level 1 is a baseline every system should meet, Level 2 targets production and personal-data systems, and Level 3 is for high-assurance environments; OWASP recommends most production systems aim for at least Level 2. Requirements use a stable identifier format, C<chapter>.<section>.<requirement>, prefixed by version for citation — for example v1.0-C9.4.3, which requires that audit logs be tamper-evident through append-only/WORM storage, cryptographic hash chaining, or an equivalent independently verifiable integrity guarantee. The published research wiki that feeds the standard covers 191 requirements across 60 pages, and the frozen 1.0/en folder is the authoritative source of the released text.

Why it matters

For anyone shipping LLM features, the value is that AI security becomes measurable. Boards can approve AI policies and risk committees can maintain model registers, but none of that proves the controls work; AISVS gives security teams a repeatable baseline to test against and produce evidence. The two chapters most relevant to the current threat landscape are the agentic and MCP chapters. The orchestration and agentic-action chapter (C9) covers execution budgets, loop control, circuit breakers, human approval for high-impact actions, tool isolation, agent identity, runtime authorization, and kill-switch mechanisms — exactly the controls that shrink the gap between a model’s output and real operational impact. The MCP chapter (C10) covers allow-listed MCP servers, per-request access-token validation, OAuth 2.1 claim validation, tool-level authorization, secure transport, schema validation, and screening of MCP tool responses for indirect prompt injection before they reach model context. That last item maps directly to the indirect-injection and tool-poisoning classes that have driven a steady stream of 2026 disclosures.

Defenses

AISVS is itself a defensive instrument, so the practical guidance is how to adopt it. Start by inventorying your AI systems and assigning each a target level by risk tier: Level 1 for internal or low-risk tools, Level 2 as the default for production and customer-facing systems, Level 3 where regulatory exposure or adversarial pressure justifies deeper assurance. Treat the requirements as a control library woven into design reviews, threat modeling, code review, and CI/CD gates — not an annual audit checklist. Prioritize the chapters that match your architecture: teams running autonomous agents should work through C9 and C10 first, RAG deployments through the memory and vector-database chapter, and any system handling personal data through the privacy chapter. Reference specific requirement IDs in penetration-test scope and vendor-procurement questionnaires so third parties are held to the same testable bar. Because AISVS complements rather than replaces ISO/IEC 42001 and NIST AI RMF, map its technical controls back to whichever governance framework your organization already reports against, so the pass/fail evidence rolls up into existing assurance reporting.

Status

This is a defensive standard release, not a vulnerability. Figures below come from the official OWASP repository and project page.

Item	Detail
Project	OWASP AI Security Verification Standard (AISVS), founded by Jim Manico
Release	Version 1.0, 24 June 2026 (per OWASP project page; LRQA analysis dated 29 Jun 2026); 1.0/en folder frozen
Structure	14 requirement chapters across the AI lifecycle; three verification levels (1/2/3)
Agent/MCP scope	C9 orchestration & agentic action; C10 Model Context Protocol security
Requirement format	C<chapter>.<section>.<requirement>, cited as v1.0-Cx.y.z; research wiki lists 191 requirements over 60 pages
Positioning	Technical control layer complementing NIST AI RMF, ISO/IEC 42001, OWASP Top 10 for LLMs and for Agentic Applications; not a governance framework
License	CC BY-SA 4.0