OWASP Artificial Intelligence Security Verification Standard (AISVS)

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

What is AISVS?

The Artificial Intelligence Security Verification Standard (AISVS) is a community-driven catalogue of testable security requirements for AI-enabled systems. 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.

AISVS is modeled after the OWASP Application Security Verification Standard (ASVS) and follows the same philosophy: every requirement should be verifiable, testable, and implementable.

Project Leaders

This project was founded by Jim Manico. Current project leadership includes Jim Manico, Otto Sulin, Rico Komenda, and Russ Memisyazici.

What AISVS is NOT

• Not a governance framework. Governance is well-covered by NIST AI RMF, ISO/IEC 42001, and EU AI Act compliance guides.
• Not a risk management framework. AISVS provides the technical controls that risk frameworks point to, but does not define risk assessment methodology.
• Not a tool recommendation list. AISVS is vendor-neutral and does not endorse specific products or frameworks.

How AISVS complements other standards

Latest Stable Version

The latest stable version is AISVS 1.0, which can be found:

Verification Levels

Each AISVS requirement is assigned a verification level (1, 2, or 3) indicating the depth of security assurance:

Organizations should select a target level based on the risk profile of their AI system. Most production systems should aim for at least Level 2.

How to use AISVS

• 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.

Requirement Chapters

1. Training Data Integrity & Traceability
2. Input Validation
3. Model Lifecycle Management & Change Control
4. Infrastructure, Configuration & Deployment Security
5. Access Control & Identity for AI Components & Users
6. Supply Chain Security for Models
7. Model Behavior, Output Control & Safety Assurance
8. Memory, Embeddings & Vector Database Security
9. Orchestration & Agentic Security
10. Model Context Protocol (MCP) Security
11. Adversarial Robustness
12. Monitoring, Logging & Anomaly Detection

Appendices

• Appendix A: Glossary
• Appendix B: AI Security Controls Inventory
• Appendix C: AI-Assisted Secure Coding

Research Wiki

For every requirement in the standard, the Research Wiki provides implementation context beyond the requirement text:

The wiki covers all 191 requirements across 60 pages, with per-section threat landscape summaries, tooling recommendations, and references to current standards and research literature.

How to Reference AISVS Requirements

Each requirement has an identifier in the format C<chapter>.<section>.<requirement>, where each element is a number, for example C9.4.3.

• The C<chapter> value corresponds to the chapter from which the requirement comes; for example, all C9.#.# requirements are from the 'Orchestration & Agentic Security' chapter.
• The <section> value corresponds to the section within that chapter where the requirement appears; for example, all C9.4.# requirements are in the 'Agent and Orchestrator Identity' section.
• The <requirement> value identifies the specific requirement within the chapter and section; for example, C9.4.3 which as of version 1.0 of this standard is:

Verify that agent identity credentials rotate on a defined schedule.

Since identifiers may change between versions of the standard, it is preferable for other documents, reports, or tools to use the following format: v<version>-C<chapter>.<section>.<requirement>, where version is the AISVS version tag. For example: v1.0-C9.4.3.

Note: The v preceding the version number should always be lowercase.

If identifiers are used without including the v<version> element, they should be assumed to refer to the latest AISVS content. As the standard grows and changes, this becomes problematic, which is why writers or developers should include the version element.

Versioning

AISVS uses a two-part version number, v<MAJOR>.<MINOR> (for example, v1.0, v1.01, v2.0). Major versions cover chapter and section changes, minor versions cover additions, removals, and material edits to requirements within the existing structure, and patch fixes ship in-branch without a separate version. The full policy is documented in RELEASE.md.

Each stable release of AISVS is published as a numbered folder in this repository. Once a version is released, its folder is locked; all future work happens in a new folder. This mirrors the approach used by OWASP ASVS.

/
├── 1.0/        <- published stable release (locked)
├── 1.01-dev/   <- next minor release (in progress)

Contributing

We welcome contributions from the community. Please open an issue to report bugs or suggest improvements. We may ask you to submit a pull request based on the discussion.

To report a security issue with the AISVS project itself, please follow the Security Policy.

License

The entire project content is under the Creative Commons Attribution-ShareAlike 4.0 International license.