OWASP AISVS: AI Security Verification Standard Guide

Most AI security guidance tells you what can go wrong; very little gives a tester or auditor a list of specific, checkable requirements to pass or fail an AI system against, and that is the gap the OWASP Artificial Intelligence Security Verification Standard (AISVS) fills. AISVS is a catalogue of testable "Verify that" requirements for AI-enabled systems, modelled on the OWASP Application Security Verification Standard (ASVS), with three assurance levels and twelve chapters running from training data to MCP servers and agent kill switches. Version 1.0 was published in June 2026 and version 1.01 in October 2026. This guide explains how the standard is structured, what each chapter demands, how to choose a level, and how to run an AISVS assessment. It is for application security teams, AI platform engineers, penetration testers and buyers who need to specify or verify AI security in concrete terms.

Key takeaways

It is a verification standard, not a risk list. Every requirement starts with "Verify that" and is meant to be testable, so AISVS complements awareness lists such as the OWASP Top 10 for LLM Applications rather than repeating them.
Use it alongside ASVS at the same level. AISVS deliberately covers only AI-specific controls; verifying at AISVS Level N assumes the application is also verified against ASVS Level N.
Cite the version. Identifiers take the form v1.01-C9.4.3 because requirement text and levels can change between minor releases; 1.0 has 191 requirements and 1.01 has 213 active ones by our count.
Agents and MCP dominate the new material. Chapter 9 (orchestration and agentic action) and Chapter 10 (MCP security) together hold more than a third of the 1.01 requirements, including identity, approval and kill-switch controls.
Level 2 is the realistic production target. The project advises most production systems to aim for at least Level 2; Level 3 is for high-assurance and regulated cases.

What AISVS is and where it comes from

AISVS is an OWASP project founded by Jim Manico and currently led by Jim Manico, Otto Sulin, Rico Komenda and Russ Memisyazici. OWASP classifies it as an Incubator project in the Standards category. It is published under Creative Commons Attribution-ShareAlike 4.0 and maintained in the open on GitHub.

The project is explicit about what it is not. It is not a governance framework (it points to the NIST AI RMF, ISO/IEC 42001 and EU AI Act guidance for that), not a risk management methodology, and not a product list. It also leaves out anything already covered elsewhere: general application security (ASVS), general software supply chain (OWASP SCVS and SLSA), infrastructure hardening (CIS Benchmarks, NIST SP 800-53, NIST SP 800-190), general logging, and hands-on test procedures, which it leaves to the OWASP AI Testing Guide.

Version status (checked 11 November 2026)

Version	Date in document header	Status	Active requirements (our count)
1.0	June 2026	Released and locked	191 (Level 1: 51, Level 2: 95, Level 3: 45)
1.01	October 2026	Latest stable per the GitHub README, locked	213 (Level 1: 57, Level 2: 110, Level 3: 46), plus one identifier marked removed
1.02	In development	Only active development release; 2.0 deferred	Subject to change

The counts are our own tally of the requirement tables in the official repository, not a figure the project publishes. At the time of checking, the OWASP project page still described 1.0 as the latest stable release while the repository README named 1.01, so confirm which version your assessor and supplier are using.

The twelve chapters

Each chapter has a control objective, sections and a requirement table with identifier, description and level. The 1.01 structure is unchanged from 1.0; the release added requirements within existing sections.

Chapter	Sections	Requirements in 1.01	Example requirement
C1 Training Data Integrity and Traceability	Data origin and security; labelling and annotation; quality assurance	13	Provenance and integrity of training data
C2 Input Validation	Prompt injection defences; content and policy screening	12	2.1.6: an instruction hierarchy where system and developer messages override user and other untrusted input (L2)
C3 Model Lifecycle Management and Change Control	Authorisation and integrity; validation; controlled deployment and rollback; secure development; fine-tuning pipelines	15	3.1.2: all model artefacts, including adapters and tokenisers, cryptographically signed (L2)
C4 Infrastructure, Configuration and Deployment	Workload sandboxing; AI hardware security; edge and distributed AI	14	Isolation of AI workloads
C5 Access Control and Identity	Authentication; AI resource authorisation and classification; multi-tenant isolation	11	5.1.2: agents in federated deployments use short-lived, minimally scoped, signed tokens (L3)
C6 Supply Chain Security for Models	Model artefact integrity; AI BOM and monitoring	7	6.2.1: a version-controlled, machine-readable AI BOM per model artefact (L1)
C7 Model Behaviour, Output Control and Safety	Output format; hallucination; output safety; source attribution	14	Enforced output formats and safety filtering
C8 Memory, Embeddings and Vector Databases	Access control on memory and RAG indices; embedding sanitisation; memory expiry and revocation	11	8.1.1: tenant-unique vector identifiers and namespaces (L1)
C9 Orchestration and Agentic Action	Budgets and circuit breakers; high-impact approval; isolation and tool authorisation; agent identity; delegation; shutdown	37	9.2.1: privileged or irreversible actions blocked until verified human approval (L1)
C10 MCP Security	Component integrity; authentication and authorisation; secure transport; schema and message validation	39	10.2.7: MCP servers accept only tokens issued for them and never pass them through (L1)
C11 Adversarial Robustness	Alignment and robustness testing; membership inference and inversion; extraction defence; runtime anomaly detection	19	Defences against model extraction
C12 Monitoring, Logging and Anomaly Detection	Request and response logging; alerting; drift; proactive behaviour monitoring; lifecycle audit	21	12.1.3: structured inference logs with model ID, token usage, provider and operation type (L2)

Between 1.0 and 1.01 the MCP chapter grew from 23 to 39 active requirements, the agentic chapter from 34 to 37, adversarial robustness from 17 to 19 and model behaviour from 13 to 14. Three appendices support the chapters: a glossary, an AI security controls inventory that cross-references every defence to requirement IDs, and controls for AI-assisted secure coding.

Where identity fits: agent and MCP requirements

For NHI and agent identity teams, AISVS is the first OWASP standard that turns agent identity into testable requirements. The most relevant ones in 1.01:

9.4.1 (L2): each agent instance has a unique cryptographic identity and authenticates as a first-class principal to downstream systems. See the Agent Identity and Access Guide.
9.4.2 (L2): agent-initiated actions are cryptographically bound to each step of the execution chain for non-repudiation.
9.4.3 (L3): agent identity credentials rotate on a defined schedule.
9.2.8 and 9.2.9 (L3): approvals are bound to action parameters, requester, context and a single-use nonce, and the keys that issue approvals are isolated from the agent runtime.
9.6.1 (L1) and 9.6.3 (L3): a manual kill switch halts inference and output, and kill-switch commands travel over an out-of-band channel isolated from the agent runtime. See the AI Agent Kill Switch and Containment Guide and, for proposed US legislation on the topic, the AI Kill Switch Act Guide.
10.2.1 to 10.2.5: MCP servers validate the access token on every request, check issuer, audience, expiry and scope in line with OAuth 2.1, do not persist tokens, filter tools/list by authorised scope, and authorise each tool call including its argument values. See the MCP Authorisation Specification Guide.
10.3.1, 10.3.3 and 10.3.5: authenticated, encrypted streamable HTTP for remote MCP; independent Origin and Host header validation to stop DNS rebinding; and sender-constrained tokens using mTLS or DPoP at Level 3.

Token passthrough, confused deputy and long-lived agent keys are exactly the failures seen in agent incidents; the Moltbook Database Exposure 2026 exposed 1.5 million AI agent API keys at once; short-lived, scoped and rotated agent credentials (5.1.2 and 9.4.3) limit the damage from that kind of leak.

Choosing a level

Level	AISVS definition	Matching ASVS level	Typical systems
1	Most critical, foundational controls against common attacks that need no other preconditions	ASVS Level 1	Any AI application handling untrusted input, including internal tools
2	More advanced or less common attacks, and layered defences against widespread threats	ASVS Level 2	Production, customer-facing and personal data systems; sensitive or regulated data
3	Harder or situational controls, defence in depth against targeted, high-complexity attacks	ASVS Level 3	Life-safety, critical infrastructure, highly sensitive personal data

Decision guidance:

Internal copilots and low-risk tools: Level 1 plus ASVS Level 1. Prioritise C2 input validation, C9.1 budgets and C12.1 logging.
Customer-facing assistants and agents with write actions: Level 2. The approval, reversibility and agent identity sections of C9 become mandatory in practice.
Agents that move money, change infrastructure or touch health or safety data: Level 3 for C5, C9 and C10 even if the rest of the system stays at Level 2. Tailoring by chapter is reasonable as long as the report says so.
Small teams: use Level 1 as a design checklist and adopt the agentic Level 2 items selectively; full Level 2 evidence collection is a significant effort.
Buyers: ask suppliers which AISVS version and level they verify against, and for the requirement-level results, not a summary badge.

How AISVS relates to other frameworks

Framework	Role	Relationship to AISVS
OWASP ASVS 5.0	Web application verification requirements	Prerequisite at the same level; AISVS restates a control only where AI changes the implementation or evidence. See the OWASP ASVS Guide.
OWASP Top 10 for LLM Applications 2025	Awareness of top LLM risks	AISVS supplies detailed controls, for example C2 for LLM01 prompt injection and C9 for LLM06 excessive agency
OWASP Top 10 for Agentic Applications	Awareness of agentic risks	C9 and C10 provide the testable controls
OWASP AI Testing Guide	How to test	AISVS says what to verify; the testing guide says how
NIST AI RMF	Risk governance	AISVS gives the technical controls that the RMF's Manage function points to. See the NIST AI RMF Guide.
ISO/IEC 42001	AI management system	AISVS results can serve as evidence for technical controls in a 42001 programme. See the ISO/IEC 42001 Guide.
NIST SP 800-53 Rev. 5	Control catalogue	Broad mapping only: SA-11 developer testing, CA-2 control assessments, SR-3 supply chain, AC-6 least privilege

For a wider comparison see the AI Security Frameworks Crosswalk Guide.

How to run an AISVS assessment

Fix the version. Choose 1.01 (latest stable at the time of writing) and record identifiers in the v1.01-Cx.y.z form so results stay meaningful when 1.02 ships.
Scope the system. List the models, data pipelines, vector stores, agents, tools and MCP servers in scope, and mark chapters that do not apply (for example C1 if you only consume a hosted model and do no training) with the reason.
Set target levels. Pick a baseline level and any chapter-level uplift, and confirm the matching ASVS level is verified or planned.
Convert requirements to test cases. For each requirement, define the evidence: a configuration export, a log sample, a test result or a design document. Use the OWASP AI Testing Guide and your AI Red Teaming Guide programme for adversarial tests.
Automate what you can. Requirements such as 3.1.3 (signature verification on load), 6.2.3 (AI BOM completeness fails the build) and 10.3.3 (Origin and Host checks) can be pipeline gates. See the AI security regression testing guide.
Pilot on one system. Run the full process on one representative AI application, measure the effort per chapter, then adjust the evidence templates before rolling out to the portfolio.
Report pass, fail and not applicable per requirement with the evidence reference, and track failures as findings with owners and dates.
Re-verify on change. Model swaps, new tools, new MCP servers and prompt changes are triggers; C3.3 requires controlled deployment and rollback for exactly these changes.

Detection and measurement

AISVS itself contains the monitoring requirements in C12, which specify AI interaction logging with session context (12.1.1), logged safety and policy decisions (12.1.2), a structured inference log schema (12.1.3) and logged RAG retrieval events (12.1.4). Programme metrics:

Percentage of in-scope AI systems assessed against a stated AISVS version and level.
Level 1 pass rate across the portfolio, then Level 2 pass rate for production systems.
Open AISVS failures by chapter, with C9 and C10 tracked separately for agent risk.
Percentage of agents with a unique cryptographic identity (9.4.1) and scheduled credential rotation (9.4.3).
Percentage of MCP servers passing the 10.2 token validation requirements.
Median days from a failed requirement to verified fix.

Common failure patterns

Running AISVS without ASVS. The standard assumes the underlying application is verified; an AI app with broken session handling passes AISVS chapters and is still insecure.
Citing requirement numbers without a version. Text and levels change between minor releases; an unversioned "C10.2.6" now points to a removed requirement.
Treating it as a compliance badge. Summary claims such as "AISVS compliant" with no level, version or requirement list give buyers nothing to rely on.
Skipping chapters because a vendor hosts the model. C2, C7, C8, C9, C10 and C12 still apply to the application you build on a hosted model.
Human approval that can be bypassed. Approval prompts that show truncated parameters or that the agent can satisfy itself fail 9.2.2 and 9.2.9; this is where most agent designs fall short.
MCP token passthrough. Forwarding the user's token to downstream APIs fails 10.2.7 and creates confused deputy risk. See the MCP Security Guide.

Practitioner checklist

Adopt AISVS 1.01 and record identifiers with the version prefix.
Confirm ASVS verification at the matching level for each AI application.
Set a baseline level per system and document any chapter-level uplift.
Give every agent a unique cryptographic identity and scheduled credential rotation.
Enforce verified human approval for privileged or irreversible agent actions.
Implement an out-of-band kill switch and test it.
Validate MCP tokens per request and block token passthrough.
Sign model artefacts and AI BOMs and verify signatures at load.
Log inference, policy decisions and RAG retrievals in a structured schema.
Require suppliers to report AISVS results per requirement, with version and level.

OWASP AISVS Guide: The AI Security Verification Standard 1.0