OWASP AISVS Checklist & Self-Assessment
An interactive checklist built on the OWASP AI Security Verification Standard (AISVS) — 29 verification controls across the 6 AISVS domains: model, data, prompt handling, tool & agent access, output handling and monitoring. Pick a rigor level, mark each control Met, Partial, Not met or N/A, and watch your coverage scored live per domain and overall. Everything runs in your browser; your answers are saved locally and you can copy or export the whole assessment as Markdown.
Based on the OWASP AI Security Verification Standard. New to it? Read OWASP AISVS Explained for the background on what the standard covers and how it fits alongside the OWASP LLM Top 10 and ASVS.
Start the AISVS checklist →AISVS is applied proportionately to risk: each level includes every control of the lighter ones and adds more.
Significant gaps across domains. Treat each Not-met item as a finding with an owner and a date.
Model provenance & integrity
0%Provenance, integrity and supply-chain verification of the models you deploy.
For every model in use you can state where it came from (vendor API, open-weight repository, internal training) and which exact version is running in production.
Self-hosted model weights are verified against a known-good checksum or signature before they are loaded, so a tampered or substituted artifact is caught.
Before a model from an external source enters the environment it is screened for supply-chain risk — publisher reputation, licence terms, and known safety or security issues.
Training & retrieval data governance
0%Controls on training, fine-tuning and retrieval data — poisoning, leakage and access.
Training, fine-tuning and retrieval (RAG) data sources are known, documented, and access to them is restricted to who needs it.
Data flowing into training or a retrieval index is validated or sanitised so that attacker-controlled content cannot silently poison the model or its answers.
Personal or sensitive data in training and retrieval corpora is identified and governed — minimised, handled per its consent basis, and subject to a retention rule.
Content pulled from retrieval sources, documents or the web is treated as untrusted when it is not fully controlled — it is data to read, not instructions to obey (links to prompt handling).
Prompt handling & injection defence
0%Defences against prompt injection and untrusted content reaching the model as instructions.
User input, retrieved documents and tool output are treated as content the model reads, never as instructions it must follow — the boundary is enforced in code, not left to the system prompt.
There are concrete defences against prompt injection — separation of system and user content, input handling, and guardrail checks on what reaches the model.
The system prompt and guardrails are protected against extraction and override to the extent feasible, so an attacker cannot simply read or disable them.
Injection that arrives through retrieved or third-party content (not just the direct user message) is part of the threat model and is mitigated.
Tool & agent access (agency)
0%Least privilege and guardrails for models that can call tools or take actions — the "excessive agency" problem.
A model or agent that can call tools or take actions is granted only the tools, scopes and data access it needs — nothing broader for convenience.
Irreversible or high-impact actions (spending, deletion, sending communications, privileged changes) require a human confirmation or approval step rather than firing autonomously.
A tool cannot be driven into an unsafe operation by model output alone — tool parameters are validated and constrained server-side.
Agent actions are limited by allow-lists and rate/scope limits enforced outside the model, rather than relying on the model to stay within bounds.
Output handling
0%Treating model output as untrusted before it reaches other systems or users.
Model output is treated as untrusted before it is rendered, executed, or passed to another system — the same way you would treat any external input.
Output reaching a browser, shell, database, or downstream API is encoded or validated to prevent injection (XSS, SQL injection, command injection) carried in model text.
The application does not execute model-generated code or commands without a sandbox, review or other safety boundary.
Monitoring & abuse detection
0%Logging, detection and abuse controls around AI behaviour.
Prompts, responses and tool calls are logged in enough detail to investigate an incident after the fact.
There is detection for abuse and anomalous behaviour — injection attempts, data-exfiltration patterns, runaway agent loops or spikes in cost/volume.
Logs capture enough to attribute an action to a user or session, without logging unnecessary sensitive data or secrets.
An educational self-assessment based on the OWASP AI Security Verification Standard (AISVS) — not an official OWASP audit, certification or guarantee. The six domains follow the AISVS structure; the verification items are a practical checklist derived from each domain and are not official numbered AISVS requirements. N/A items are excluded from the score; unanswered items count as a gap. Your answers are saved only in this browser.
Loading…
Sample report · illustrative data
Sample result: AISVS self-assessment
Example answers for a customer-facing AI assistant assessed at the Production rigor level, covering six control areas.
Summary
- Rigor level
- Production (Essentials plus Production controls)
- Overall coverage
- 64% in this example
- Maturity read
- Developing
- Scoring
- Met = 1, Partial = 0.5, Not met = 0, N/A excluded
Coverage by area
| Area | Coverage (example) |
|---|---|
| Model provenance and integrity | 75% |
| Training and retrieval data governance | 63% |
| Prompt handling and injection defence | 50% |
| Tool and agent access (agency) | 50% |
| Output handling | 75% |
| Monitoring and abuse detection | 67% |
Example Not met items
- High-impact actions require human approval
- Tool inputs and outputs are validated
- Model artifacts are integrity-checked before deployment
Made-up example data. Your own run uses your inputs. Downloads of the full report need Pro.
TL;DRWhat this tool is
5 points
- An interactive checklist and self-assessment built on the OWASP AI Security Verification Standard (AISVS) — 29 verification controls across the 6 AISVS domains.
- AISVS does for AI and LLM applications what OWASP ASVS did for web apps: it turns "is this AI system secure?" into specific, testable requirements, organised by the parts of an AI system with a unique attack surface — model, data, prompt handling, tool/agent access, output handling and monitoring.
- Pick a rigor level (Essentials / Production / Regulated — AISVS is applied proportionately to risk), then mark each control Met, Partial, Not met or N/A. Coverage is scored live per domain and overall.
- Everything runs in your browser; your answers are saved locally and you can copy or export the whole assessment as Markdown to drop into a review or ticket.
- This is an educational self-assessment, not an official OWASP audit. The domain structure follows AISVS; the controls are a practical checklist derived from each domain.
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. That tells you what can go wrong, but not 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, modelled on the long-established ASVS for web applications.
The six domains
The unique attack surface of an AI application maps to the domains a verification standard organises around — the same six this tool walks you through:
- 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, AISVS 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. That is why this tool lets you pick a rigor level and scopes the controls accordingly.
How to use it: 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 — before the excessive-agency or prompt-injection gap ships. This is a planning and self-assessment aid, not an official OWASP audit or a guarantee.
Frequently asked questions
What is AISVS?
AISVS is the OWASP AI Security Verification Standard — 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 is modelled on OWASP's Application Security Verification Standard (ASVS) for web apps, translated to the components unique to AI systems: models, training and retrieval data, prompt handling, tool and agent access, output handling and monitoring.
What is the difference between AISVS and ASVS?
ASVS (the Application Security Verification Standard) provides verifiable requirements for conventional application security — authentication, session management, access control, input validation. AISVS is modelled on it and adds the AI-specific layer on top. Because most AI applications are also web applications, you verify the conventional attack surface against ASVS and the AI-specific attack surface against AISVS. They are complementary, not competitors.
Is this the official OWASP AISVS?
No. This is an educational self-assessment tool that follows the AISVS domain structure to help you run a review. It is not an official OWASP document, audit or certification, and the verification items are a practical checklist derived from each AISVS domain rather than the standard's own numbered requirements. For the authoritative standard, refer to OWASP. AISVS is a trademark of the OWASP Foundation.
How do I use AISVS?
Use it as a review checklist scoped to the application's risk level: choose a rigor level, then walk each domain — model, data, prompt handling, tool/agent access, output, monitoring — and mark which controls are met, partially met, not met, or not applicable. Record the Not-met items as findings with owners and dates. It is most valuable early, in the design and pre-launch review of an LLM feature, and as the backbone of a repeatable AI security review.
More security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.