OWASP AISVS 1.01: 213 Testable Requirements That Bring AI Security Back to Engineering

Not another Top 10

The Artificial Intelligence Security Verification Standard is an OWASP community project modeled on ASVS: requirements should be implementable, testable and verifiable. The current stable release is 1.01; 1.02 is the only active development release. The project is licensed under CC BY-SA 4.0.

Its role alongside other documents is explicit. The LLM and Agentic Top 10s build risk awareness; NIST AI RMF and ISO/IEC 42001 address governance and risk management; ASVS covers general application security; AISVS adds verification for AI-specific controls. It is neither a self-contained AI security program nor a certification you obtain by installing a tool. The official guidance says AISVS Level N should be applied together with ASVS Level N.

How the 213 requirements are layered

The 12 chapters in 1.01 contain 213 core requirements: 57 at Level 1, 110 at Level 2 and 46 at Level 3, counted from the requirement tables in the stable Markdown files, excluding appendices and removed entries. The levels indicate assurance depth, not simply vulnerability severity:

The chapters span the lifecycle: C1 training data, C2 input validation, C3 model lifecycle, C4 infrastructure, C5 access control, C6 model supply chain, C7 model behavior, C8 memory/embeddings/vector stores, C9 orchestration and agents, C10 MCP, C11 adversarial robustness and C12 monitoring and logging. Three appendices add a glossary, a controls inventory and AI-assisted secure coding.

Do not start at requirement one and tick boxes mechanically. Select a target level from the system’s risk profile, use AISVS for AI-specific controls alongside the relevant general standards, and document scope decisions. Requirements outside your organization’s control may be marked out of scope, but “we cannot control it” is not the same evidence as “it passed”.

Three families worth reading first

Prompt injection is not just an input-filter problem. C2 covers normalization, encoding smuggling, injection screening and context-length limits; C2.1.4 explicitly requires rejecting oversized input instead of silently truncating it. C2 alone is insufficient. C10.4.1/C10.4.2 require MCP tool-list and tool-call responses to be schema-validated and screened for indirect prompt injection before entering model context. C9.5.3 assigns access-control decisions to application logic or a policy engine, never to the model itself. Detection, context boundaries, deterministic authorization and auditing have to work together.

Agent approval cannot be a meaningless Allow button. C9.2.1 makes verified human approval before privileged or irreversible actions a Level 1 requirement. C9.2.2 requires the approval interface to display canonical, complete parameters without unsafe transformation: commands, diffs, recipients, amounts, resources and scopes cannot be replaced by a reassuring model summary. At Level 3, C9.2.8 cryptographically binds approval to the action parameters, requester identity, execution context and a unique single-use nonce; any changed value or reused nonce must be rejected. C9.1 adds token, cost and recursion budgets plus kill switches. Real approval authorizes a deterministic action object, not a plausible-looking plan.

RAG memory writes are an attack surface too. C8.1.3 requires scope enforcement during retrieval; C8.2.3 prohibits agent or tool output from entering trusted memory without source validation; C8.3.1 requires expired vectors to disappear from retrieval results. C12.1.4 adds logs of queries, retrieved documents and knowledge sources. A knowledge base is therefore not a read-only document pile: it is persistent state with tenant boundaries, write quarantine, lifecycle rules and an audit trail.

The part worth copying

The repository also separates the standard from its Research Wiki. The standard says what to verify; the wiki adds threats, verification approaches, evidence and tooling limitations for each requirement. This is easier to adopt than a single checklist padded with hundreds of pages of background: engineering can start with a requirement matrix, while auditors follow identifiers to evidence.

A practical adoption path fits into five steps:

1. Map the system boundary: models, data sources, vector stores, tools, MCP servers and external calls.
2. Choose matching ASVS and AISVS target levels instead of pursuing all 213 items.
3. Build a matrix of requirement ID / applicability / owner / implementation / evidence / status.
4. Put automatable evidence into CI: negative schema tests, unauthorized tool arguments, exhausted budgets, unapproved dangerous actions, cross-tenant retrieval and log-field completeness.
5. Re-run verification against the same version after material changes to models, system prompts, tool manifests or retrieval pipelines.

Where it falls short

Some requirements also need judgment rather than literal application. C2.1.5’s character-set allow-list, if applied indiscriminately to free-form multilingual text, could reject legitimate input. Separate commands, arguments and identifiers from natural-language fields before defining scope and exceptions. Likewise, controls inside a model vendor’s boundary may be supported only by documentation rather than independent application-side testing. Record assumptions, detector error and residual risk; an immaculate checklist can otherwise become compliance theater.

Finally, 1.01 is a stable snapshot rather than a live rule feed, while 1.02 remains in development. The project provides no official scanner, compliance score or security guarantee. Teams still need to build the tooling and evidence automation themselves.