OWASP AISVS Explained: AI Security Verification Standard
TL;DR · the short version
The OWASP AI Security Verification Standard (AISVS) aims to do for AI and LLM applications what the ASVS did for web apps: turn 'is it secure?' into specific, testable requirements an auditor or engineer can verify. Where the OWASP Top 10 for LLM Applications names categories of risk (prompt injection, output handling, training-data poisoning), AISVS states the controls that must be present and how to check them, organised by domain (model, data, prompts, tools, output, monitoring) and applied proportionate to the application's risk.
If you have shipped or reviewed an LLM feature, you have hit the core problem: everyone agrees it should be "secure," but there is no shared, testable definition of what that means. The OWASP AI Security Verification Standard (AISVS) exists to fix that — the same way the Application Security Verification Standard (ASVS) did for web applications a decade ago. It turns "is this AI app secure?" into a list of specific requirements an engineer or auditor can actually verify. You can work through its requirements yourself with the interactive AISVS checklist.
Awareness vs. verification: where AISVS fits
OWASP already publishes the Top 10 for LLM Applications — an awareness document that names the big risk categories: prompt injection, insecure output handling, training-data poisoning, excessive agency, and so on. That is essential for knowing what can go wrong, but it does not tell you whether a specific application has the controls to prevent it. A verification standard closes that gap: for each area, it states the controls that must be present and how to check them. AISVS is that verification layer for AI systems.
What AISVS covers
The unique attack surface of an AI application maps to domains a verification standard organises around:
- Model: provenance, integrity and supply-chain verification of the models you deploy.
- Data: controls on training, fine-tuning and retrieval data — poisoning, leakage and access.
- Prompt handling: defences against prompt injection and untrusted-content-in-context.
- Tool and agent access: least privilege and guardrails for models that can call tools or take actions (the "excessive agency" problem).
- Output handling: treating model output as untrusted before it reaches other systems or users.
- Monitoring: logging, detection and abuse controls around AI behaviour.
Like ASVS, it is designed to be applied at a level proportionate to risk — a low-stakes internal tool is held to a lighter bar than a customer-facing agent with tool access.
AISVS, ASVS and the LLM Top 10 together
These are not competitors. Most AI applications are also web applications, so you verify the conventional attack surface against ASVS, the AI-specific surface against AISVS, and use the LLM Top 10 to make sure the team understands the risk categories those controls address. Used together they cover awareness, conventional appsec and AI-specific appsec.
How to put it to work
Treat AISVS as the backbone of a repeatable AI security review: scope it to the feature's risk level, walk each domain, confirm which required controls exist, and log the gaps as findings with owners. It pays off most in design and pre-launch review of LLM features — before the excessive-agency or prompt-injection gap ships.
Run a first pass with the OWASP AISVS checklist tool →, threat-model the feature with the AI Threat Model, and review agent tool access with MCP Guard.
Templates and tools for this standard
AISVS tells you what to verify; ISO/IEC 27090 frames the AI threats behind it. These templates and tools turn both into owned, tested work.
RACI and project plan templates (each with a preview of its sample on the page):
- ISO 27090 RACI Template (Pro): Sixteen roles × 94 AI security activities, checked for one Accountable each.
- ISO 27090 Project Plan Template (Pro): Editable phases, tasks, owners, deliverables and indicative durations.
Related ISO tools:
- ISO 27090 AI Security Test Plan (Pro): Thirty test cases across ten AI threat areas.
- ISO 27090 Traceability Matrix: Trace each AI threat to controls, tests and evidence.
- ISO 27090 Threat-Mapping Lab (Pro): Map AI scenarios to threat class, CIA property and fix.
- ISO 27090 Readiness Checklist (Pro): Score six weighted themes and see your gaps ranked.
- AI Standards Crosswalk (Pro): 42001, 27001, 27090, EU AI Act and NIST AI RMF side by side.
Every ISO tool on PlayCISO, grouped by standard: the AI standards toolkit.
Frequently asked questions
What is AISVS? An OWASP standard that expresses AI/LLM application security as specific, verifiable requirements — a testable checklist, not just an awareness list.
How is it different from the LLM Top 10? The Top 10 names the risks; AISVS states the controls that must be present and how to verify them.
How does it relate to ASVS? It is modelled on ASVS and adds the AI-specific layer; you verify most AI apps against both.
How do teams use it? As a risk-scoped review checklist, walked domain by domain, most valuable in design and pre-launch review.
Frequently asked questions
What is the OWASP AI Security Verification Standard (AISVS)?
AISVS is an OWASP community standard that expresses the security of an AI or LLM application as a set of specific, verifiable requirements — controls that should be present and can be tested — rather than a general description of risk. It follows the model of OWASP's Application Security Verification Standard (ASVS) for traditional web applications, translated to the components that are unique to AI systems: models, training and retrieval data, prompt handling, tool and agent access, output handling and monitoring.
How is AISVS different from the OWASP LLM Top 10?
They are complementary. The OWASP Top 10 for LLM Applications is an awareness document — it names and explains the most important risk categories (prompt injection, insecure output handling, excessive agency, and so on). A verification standard like AISVS goes the next step: for each area it states the concrete controls that must be in place and how to verify them, so it can be used as a checklist for a security review or an audit rather than only for awareness.
How does AISVS relate to ASVS?
AISVS is modelled on ASVS. ASVS provides verifiable requirements for conventional application security (authentication, session management, access control, input validation, and so on) and remains relevant because most AI applications are also web applications. AISVS adds the AI-specific layer on top. In practice you verify an LLM product against ASVS for its conventional attack surface and against AISVS for its AI-specific one.
How should a team use AISVS?
Use it as a review checklist scoped to the application's risk level: walk each domain (model, data, prompt handling, tool/agent access, output, monitoring), confirm which required controls are present, and record the gaps as findings with owners. It is most valuable early — in design and pre-launch review of an LLM feature — and as the backbone of a repeatable AI security review rather than a one-off.