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

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.

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

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

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

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.

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

1. Training Data Integrity & Traceability
2. User Input Validation
3. Model Lifecycle Management & Change Control
4. Infrastructure, Configuration & Deployment Security
5. Access Control & Identity
6. Supply Chain Security for Models, Frameworks & Data
7. Model Behavior, Output Control & Safety Assurance
8. Memory, Embeddings & Vector Database Security
9. Autonomous Orchestration & Agentic Action Security
10. Model Context Protocol (MCP) Security
11. Adversarial Robustness & Attack Resistance
12. Privacy Protection & Personal Data Management
13. Monitoring, Logging & Anomaly Detection
14. Human Oversight and Trust

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

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 'Autonomous Orchestration & Agentic Action 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 'Identity & Audit' 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 audit logs are tamper-evident via append-only/WORM/immutable log store, cryptographic hash chaining where each record includes the hash of the prior record, or equivalent integrity guarantees that can be independently verified.

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.

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/        <- current stable release (locked after release)
├── 1.01-dev/   <- next minor release (pending)

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.

The entire project content is under the Creative Commons Attribution-Share Alike v4.0 license.