By OWASP just shipped something developers have been building AI apps without: a testable security checklist purpose-built for AI systems. AISVS 1.0, released at OWASP Global AppSec Vienna this month, contains 514 verifiable requirements across 14 chapters covering everything from prompt injection to MCP server authentication. It is not a governance document or an aspirational framework. Every requirement is written to be checked — pass or fail.
The Gap It Fills
The AI security landscape already has frameworks: NIST AI RMF tells you what risks exist. ISO/IEC 42001 and the EU AI Act tell you what practices are good. None of them tell you what to verify in your code. That is the gap AISVS fills.
AISVS is modeled after OWASP ASVS, the gold standard for web application security verification. Jim Manico — who led ASVS — leads AISVS too, which is why it carries the same core design principle: if you cannot check it, it does not belong in the standard. The result is a checklist engineers can actually use, not a document to attach to a compliance report.
Three Levels, 14 Chapters, One Starting Point
Requirements are organized into three assurance levels. L1 is the essential baseline — where every AI application should start. L2 covers production systems, and most teams shipping real products should be targeting this. L3 is reserved for critical infrastructure and high-assurance environments. Requirements follow a consistent reference format: v1.0-C<chapter>.<section>.<requirement> — for example, v1.0-C9.4.3.
The 14 chapters span the full AI lifecycle: training data integrity, input validation, model lifecycle, infrastructure, access control, supply chain, model behavior, memory and vector databases, agentic orchestration, MCP security, adversarial robustness, privacy, monitoring and logging, and human oversight.
Prompt Injection: Finally, Testable Controls
Chapter C02 covers user input validation — and it does not treat prompt injection as a theoretical risk. Research published in 2026 shows 73% of production AI deployments are currently vulnerable to prompt injection. AISVS translates that into specific, verifiable controls:
- Enforce an instruction hierarchy where system and developer messages override user input, even after processing user instructions.
- Apply Unicode NFC canonicalization, homoglyph mapping, and bidirectional text neutralization before tokenization — not after.
- Treat all text extracted from image-to-text and speech-to-text processing as untrusted, and screen it accordingly.
- Block inputs flagged as adversarial before they reach the model.
These are pass/fail requirements, not guidelines to consider. That distinction matters.
MCP Security Gets Its Own Chapter
Chapter C10 covers MCP security, and its timing could not be better. MCP has become the dominant protocol for connecting AI systems to external tools and services in 2026, and most implementations have no formal security guidance to follow — until now.
AISVS C10 requires that tool discovery responses filter results by authorized scope. Every tool invocation must validate user authorization — server-side, on every call, not just at session establishment. For transport, production environments must use authenticated, encrypted streamable-HTTP. The stdio and SSE transports are restricted to local or tightly controlled environments only. Refer to the AISVS MCP Security chapter for the full requirement list.
If your application connects to MCP servers, C10 is where you start.
Supply Chain: Models Are Dependencies Too
C06 applies software supply chain thinking to AI models. Every third-party model artifact must include a signed origin record identifying the source repository and commit hash. Models must be scanned for Trojan triggers and malicious layers before import. Transfer-learning fine-tunes must pass adversarial evaluation to detect hidden behaviors introduced during fine-tuning.
Chapter C03 adds the AIBOM requirement: a machine-readable AI Bill of Materials in SPDX or CycloneDX format, covering models, adapters, and safety classifiers. The same tooling your team already uses for software SBOMs applies here. If you would not ship a product without knowing what third-party libraries it contains, apply the same logic to the models powering it.
How to Start
The AISVS GitHub repository has the full 1.0 release. The practical path for most teams:
- Start with L1 across all 14 chapters to identify your current gaps.
- Prioritize C02 (prompt injection) and C10 (MCP security) based on your architecture.
- Produce an AIBOM for your models using existing SPDX or CycloneDX tooling.
- Target L2 compliance before your next production release.
AISVS 1.0 will evolve — this is v1.0, built with the same versioning discipline as the software it is designed to secure. But it is the first time the industry has a testable AI security baseline built by people who understand both AI systems and security verification. If you are shipping AI applications without it, you are guessing. The checklist exists now. Use it.
