GenAI has moved from experimentation into production systems – from customer-facing chatbots and coding assistants to autonomous agents that call tools on behalf of users. Governance frameworks such as the NIST Artificial Intelligence Risk Management Framework (AI RMF) and ISO/IEC 42001 help organizations structure risk management, but they stop short of defining testable security requirements for the AI lifecycle.

At OWASP Global AppSec in Vienna, the OWASP GenAI Security Project released version 1.0 of the Artificial Intelligence Security Verification Standard (AISVS). The standard applies the proven Application Security Verification Standard (ASVS) pattern: requirements phrased as “Verify that …”, grouped by assurance level, and designed for repeatable assessment. For security teams, developers, and auditors working on GenAI solutions, this is a practical reference worth understanding.

What AISVS is — and isn’t

The OWASP GenAI Security Project describes the Artificial Intelligence Security Verification Standard (AISVS) as a community-driven catalogue of security requirements for AI-enabled systems. It spans the full lifecycle: data collection and model development through deployment, monitoring, and retirement. Every requirement is written to be objectively verifiable through testing, inspection, or audit.

AISVS deliberately does not replace existing standards. General application security remains the domain of ASVS. Software supply chain controls are covered by standards such as the Software Component Verification Standard (SCVS) and SLSA. Organizational AI governance, fairness documentation, and risk-management process design sit with ISO/IEC 42001 or NIST AI RMF. AISVS adds the layer those frameworks leave open: AI-specific controls that an assessor can actually test.

AISVS deliberately focuses on security verification rather than organizational governance. It restates a general control only when artificial intelligence introduces a distinct attack surface, implementation detail, or evidence requirement. Therefore, when an AI application is verified at AISVS Level 2, a verification of the underlying application at ASVS Level 2 should also be considered.

Three verification levels

Like all of OWASP’s verification standards, AISVS defines three ascending assurance levels. Organizations can start at Level 1 and adopt higher levels as threat exposure and business impact grow.

Level	Typical use	Focus
1	Any AI application handling untrusted input or data of any sensitivity	Foundational controls against common attacks without special preconditions
2	Applications with sensitive business or regulated data, or operating in adversarial contexts	Layered defenses, more complex logic, targeted attack prerequisites
3	High-assurance systems: critical infrastructure, life-safety decisions, highly sensitive personal data	Defense in depth, situational controls, protections against targeted high-complexity attacks

This tiered model makes AISVS adaptable. A proof-of-concept internal chatbot and a customer-facing agent with tool access do not need the same verification depth – but both benefit from a shared vocabulary for scoping assessments.

Twelve control families across the AI stack

AISVS organizes requirements into twelve chapters. Each chapter states a control objective, groups related requirements into sections, and assigns every item to a verification level. The chapters reflect how modern AI systems are actually built and attacked. The diagram below groups them by layer in a typical GenAI architecture:

Beyond the twelve chapters, AISVS includes three appendices. Appendix A is a glossary of terms used throughout the standard. Appendix B cross-references defense techniques with requirement identifiers – useful when you need to see, for example, which chapters contribute to mitigating prompt injection. Appendix C extends the verification model to AI-assisted secure coding: organizational controls for using coding assistants, review bots, and similar tools during the software development lifecycle.

Requirements we can test

A defining characteristic of AISVS is testability. Its 191 requirements begin with “Verify that” and describe a single concern that can ordinarily be implemented and verified as one technical mechanism. The examples below are taken from different chapters to illustrate the pattern:

#	Description	Level
2.1.3	Verify that all inputs that could steer model behavior are treated as untrusted and screened by a prompt injection detection ruleset or classifier, with flagged inputs blocked.	1
7.1.1	Verify that the application validates all model outputs against a defined schema and rejects any output that does not match.	1
9.2.1	Verify that the agent runtime blocks execution of privileged, high-impact, or irreversible actions until explicit human approval is received and verified.	1

This phrasing matters in practice. Instead of debating whether an agent is “secure enough”, teams can scope an assessment: which level applies, which requirements are in scope, and what evidence demonstrates compliance. Gaps become actionable findings rather than abstract risk statements.

Defending against a single AI threat often spans multiple chapters. The standard itself notes that prompt injection in an agentic application draws on C2 (input validation), C7 (model behavior), C9 (orchestration), C10 (MCP), C11 (adversarial robustness), and C12 (monitoring). Treating AISVS as a whole – not as isolated checklists per chapter – reflects how attacks actually work.

Where AISVS fits in your security program

AISVS complements the broader landscape of AI security guidance rather than competing with it:

• NIST AI RMF and ISO/IEC 42001 answer what to govern and how to structure risk management.
• OWASP Top 10 for LLM Applications and the GenAI Red Teaming Guide describe prevalent threats and offensive testing approaches.
• AISVS translates that threat understanding into verifiable build and run requirements.

For organizations already familiar with ASVS-driven secure development or ASVS-scoped penetration tests, AISVS extends a known workflow. Security requirements can inform architecture decisions during design. Development teams implement controls with clear acceptance criteria. Security testers map findings to requirement identifiers. Auditors review evidence against a published baseline.

Design and build

During solution design, AISVS helps teams define a target assurance level before code is written. Should a customer service chatbot meet Level 1 or Level 2? Does an internal coding agent with repository access warrant Level 2 controls on tool authorization and secret isolation? Scoping these questions early reduces costly rework when agent capabilities expand later.

Requirements around training data integrity (C1), supply chain provenance (C6), and infrastructure isolation (C4) are especially relevant for teams training or fine-tuning models. Teams consuming third-party models through application programming interfaces (APIs) will focus more on input validation, output control, and orchestration chapters.

Operate and monitor

Chapters on monitoring and logging (C12), model lifecycle management (C3), and infrastructure (C4) support operational security. They address questions that surface after go-live: Are inference anomalies logged? Can you roll back a compromised model version? Is vector store content integrity-protected?

When an AI-related security event occurs, a shared requirement catalogue also helps incident responders understand which controls failed and what compensating measures apply. Organizations with a CSIRT capability can reference AISVS chapters when triaging AI-specific incidents such as retrieval pipeline poisoning or unauthorized agent actions.

Test and assure

This is where AISVS delivers the most immediate value for security testing. Requirements map directly to test cases. Chapters on input validation and prompt injection (C2, C7, C11) align with LLM red teaming and adversarial prompt testing. Orchestration, tools, and agents (C9, C10) support structured assessments of permissions, approval workflows, and kill-switch effectiveness. Retrieval security (C8) enables targeted tests for data leakage, context injection, and embedding store access controls.

AISVS does not prescribe attack techniques – the GenAI Red Teaming Guide remains the offensive companion. It does provide the defensive checklist that turns red team findings into tracked remediation items.

A practical scoping example

Imagine an organization deploying a retrieval-augmented generation (RAG) chatbot with three tools: a read-only knowledge base search, a ticket creation API, and an email draft function. A proportionate AISVS scope might look like this:

Target level: 2 (customer-facing, processes business data)

Priority chapters:

• C2: Validate and sanitize user prompts; separate trusted system instructions from untrusted content.
• C7: Filter unsafe outputs; enforce content policies before responses reach users.
• C8: Protect the vector database against unauthorized writes; validate retrieved chunks before they enter model context.
• C9: Require human approval before ticket creation or email sending; enforce per-tool resource limits.
• C12: Log prompt–response pairs, tool invocations, and approval decisions for investigation.

Parallel baseline: ASVS Level 2 for the web application, authentication, and API security.

Out of scope (for this release): C1 training data controls (third-party model, no fine-tuning), C11 adversarial robustness beyond prompt injection (deferred to a later iteration).

This scoping exercise produces a test plan, a development backlog, and a language for reporting – without requiring every chapter at every level from day one because AISVS is a milestone, not an endpoint. The artificial intelligence threat landscape continues to evolve rapidly, and future revisions will extend the twelve control families as new capabilities and integration patterns emerge.

For organizations integrating GenAI into products and internal workflows, AISVS offers something governance documents alone cannot: a shared, testable baseline. It does not guarantee security – no standard can. It does give teams a structured way to design, build, operate, and test AI systems with proportionate assurance, using language that developers, security professionals, and auditors already understand from the ASVS ecosystem.

How we can help

At Redguard, we support organizations across consulting, offensive security testing, and incident response. Whether you are defining a target AISVS level for a new GenAI product, planning a security assessment of an existing agent deployment, or responding to an AI-related security event, we can help you translate the standard into actionable steps for your context. Contact us for an informal discussion about where AISVS fits into your AI security program.