AISVS 1.0 contains 191 security requirements. Copying all 191 into a spreadsheet proves only that someone can operate a spreadsheet. If you want to know how to use OWASP AISVS, start with evidence: choose an assurance level, scope the AI system, map threat paths to versioned controls, and make failed controls change what can ship.
The standard divides its catalogue into 51 Level 1, 95 Level 2, and 45 Level 3 requirements across 12 chapters. That is enough structure to run a serious review—and enough surface area to create a very impressive checkbox cemetery. This guide turns AISVS into an engineering workflow instead.
What OWASP AISVS 1.0 actually covers
Released on June 24, 2026, OWASP AISVS 1.0 defines testable requirements for AI-enabled systems from data collection and model training through deployment, monitoring, and retirement. Every requirement starts with “Verify that.” That wording matters: the unit of work is not a policy aspiration but a claim an assessor can test.
AISVS is not a governance framework, risk-assessment method, or shopping list of security products. It is the AI-specific technical layer that sits beside established application security. The locked AISVS 1.0 repository also includes a 60-page research wiki covering all 191 controls, with threats, tooling ideas, and references.
That distinction mirrors a problem we found with production-readiness scorecards: a precise score can still answer a narrower question than its audience assumes. AISVS gives teams a shared verification vocabulary. It does not make the verification happen.
How to use OWASP AISVS in six steps
1. Pick the assurance level
Choose the target level from the system’s risk, not the security team’s available calendar. Level 1 covers foundational controls. Level 2 adds the standard controls expected for production systems handling sensitive data or consequential decisions, while Level 3 targets critical and highly regulated environments.
“Most production systems should aim for at least Level 2.”
OWASP AISVS documentation
The chapter distribution explains why. Access Control and Identity has zero Level 1 requirements; its 11 controls begin at Levels 2 and 3. Level 1 is a baseline, not a miniature production program with every important topic represented.
2. Scope the AI system
Draw the system before selecting rows. Inventory the model provider, training or fine-tuning data, retrieval pipeline, vector store, memory, agents, tools, MCP servers, identities, approval gates, and monitoring path. Then mark each AISVS chapter as applicable, out of scope, or controlled by a third party.
“Vendor managed” is not evidence; it is an ownership boundary. Record which vendor document, contract term, configuration export, or test result supports the decision. For agent systems, our six-layer agent security checklist provides a useful architecture inventory before the control mapping begins.
3. Map threat paths, not silos
Do not hand C2 to the input team, C9 to the agent team, and declare victory at the interfaces. AISVS notes that prompt injection in an agentic application can cross C2 input validation, C7 model behavior, C9 orchestration, C10 MCP, C11 adversarial robustness, and C12 monitoring.
Start with a workflow such as “retrieved document causes an agent to invoke a payment tool.” Use the agentic risk catalogue to name the failure, then map every preventive, detective, and recovery control across the path. Threats travel through systems; org charts are not firewalls.
4. Store evidence with versioned IDs
OWASP recommends identifiers such as v1.0-C9.4.3 because unversioned control numbers can move as the standard evolves. The stable 1.0 requirement text is locked, while next-minor work lives separately in 1.01-dev. Pin the version in tests, tickets, reports, and exceptions.
A useful control record should capture eight fields. This is a PulseMark implementation pattern, not an official OWASP schema:
- Requirement: the version-pinned AISVS ID.
- Applicability: required, optional, or out of scope—with a reason.
- Owner: the team responsible for keeping the control true.
- Implementation: the mechanism that enforces the requirement.
- Test: the reproducible verification procedure.
- Evidence: the retained artifact, log, report, or configuration.
- Status: passing, failing, excepted, or not tested.
- Review date: the last check and the next trigger.
control: v1.0-C9.2.1
applicability: required
owner: platform-security
implementation: "Runtime blocks irreversible tool calls pending approval"
test: tests/security/test_agent_approval_gate.py
evidence:
- artifacts/aisvs/c9.2.1/approval-gate-results.json
status: passing
reviewed: 2026-08-03
5. Put deterministic checks in CI
Automate controls with objective outputs: schema validation, tool allow-lists, token scope checks, execution budgets, artifact hashes, payload limits, and required telemetry fields. Store the results as build artifacts and fail the pipeline when a mandatory control fails. A green dashboard without retained evidence is just a mood ring.
Keep humans on work that requires judgment: threat-model review, trust-boundary inspection, reversibility classification, approval semantics, and kill-switch exercises. An LLM reviewing another LLM’s plan can add signal, but it cannot replace a deterministic policy gate or approve its own exception.
6. Turn failures into release decisions
Define the consequence before the assessment starts. A failed required control might block production, restrict the feature to read-only mode, remove a tool, or require a named risk owner to accept a time-limited exception. Give every exception an expiry date, compensating control, and retest trigger.
Retest on model changes, prompt or policy changes, new data sources, tool additions, permission changes, and protocol upgrades—not merely once a year. AI systems can change behavior when the application code stays untouched. The evidence clock should follow the system, not the audit calendar.
A Level 2 starter matrix
C9 Orchestration contains 34 requirements, C10 MCP has 23, and C12 Monitoring has 21. Together, those runtime-oriented chapters account for 78 of 191 controls, or 40.8%. For an agent application, that is a clue about where to begin—not permission to ignore the other chapters.
| System surface | AISVS chapters | Minimum evidence | Release gate |
|---|---|---|---|
| Models and data | C1, C3, C6 | Registry entry, provenance, hashes, acceptance tests | Unknown artifact or failed acceptance test blocks promotion |
| RAG and memory | C2, C8, C12 | Tenant-isolation tests, retrieval logs, injection fixtures | Cross-tenant result or missing lineage blocks release |
| Agents and tools | C5, C7, C9, C12 | Tool policy, approval logs, budget tests, kill-switch drill | Privileged action without verified approval becomes read-only |
| MCP | C5, C9, C10 | Component verification, token tests, schemas, tool snapshot | Unapproved server or changed tool definition cannot run |
C10 becomes much easier to reason about against a real implementation. Our stateless MCP server tutorial shows the transport and authorization surface; AISVS adds the verification questions around source trust, token validation, schemas, consent, and tool-definition changes.
What AISVS does not replace
AISVS intentionally excludes general web security. Verification at AISVS Level 2 assumes the application is also being verified at OWASP ASVS Level 2. Session management, ordinary authorization, file uploads, transport security, and non-AI input handling do not disappear because a model is in the architecture diagram.
It also does not define organizational risk appetite, impact assessments, or governance processes. The NIST AI Risk Management Framework covers that layer. Generic infrastructure hardening, privacy operations, supply-chain controls, and log protection still need their established standards too.
The honest claim is narrow: a scoped system satisfied a named AISVS version and level, with documented exclusions and reproducible evidence on a given date. “Our AI is secure” is not a test result. It is a sentence waiting for an incident report.
Make every “Verify that” earn its evidence
The unresolved question is whether teams can keep this evidence current while models, prompts, permissions, tools, and protocols change faster than conventional audit cycles.
The deeper value of AISVS is not the checklist. It is the common join key connecting architecture, tests, artifacts, tickets, exceptions, procurement language, and release policy. A requirement becomes useful when failing it has an owner and a consequence.
The next minor release is already taking shape in the repository’s 1.01-dev folder. When AISVS 1.01 ships, teams will discover whether they built durable, version-pinned evidence—or merely decorated a spreadsheet with 191 temporary checkmarks.
Get the Daily Pulse
Sharp analysis on what's actually moving in AI. No hype, no filler, no weekly digest.
