OWASP AI Security Verification Standard (AISVS), Explained
The OWASP AI Security Verification Standard (AISVS) is a community effort to do for AI and LLM applications what the long-established Application Security Verification Standard (ASVS) did for web apps: turn "is it secure?" into a list of specific, testable requirements an auditor or engineer can verify. Where the OWASP Top 10 for LLM Applications names the categories of risk (prompt injection, insecure output handling, training-data poisoning, and so on), a verification standard states the controls that must be present and how to check them — organised by domain (model, data, prompt handling, tool/agent access, output, monitoring) and, like ASVS, intended to be applied at a level proportionate to the application's risk. This explainer covers what AISVS is for, how it fits alongside the LLM Top 10 and ASVS, and how to put it to work.
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.
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 free AISVS checklist tool →, threat-model the feature with the AI Threat Model, and review agent tool access with MCP Guard.
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.
Ready to practise the decisions these articles describe?
Run a free War Room →