LLMSVS v2.0 — OWASP Large Language Model Security Verification Standard (LLMSVS)

Publication year: 2026

This document is the Markdown edition of the OWASP LLMSVS English release. It carries forward the full verification requirement set from the initial 0.1 release (February 2024) through version 2.0, organized for web rendering, version control, and derivative builds.

Table of contents

• Frontispiece
  • About the standard
  • Copyright and license
  • Project leads
  • Major supporters and sponsors
• Preface
• Utilizing the LLMSVS
  • Security verification layers
  • Assumptions
  • OWASP ASVS cross-references
• Assessment and certification
  • OWASP’s stance on LLMSVS certifications and trust marks
  • Guidance for certifying organizations
• V1. Secure configuration and maintenance
• V2. Model lifecycle
• V3. Real time learning
• V4. Model memory and storage
• V5. Secure LLM integration
• V6. Agents and plugins
• V7. Dependency and component
• V8. Monitoring and anomaly detection
• Appendix A: Glossary

Frontispiece

About the standard

The Large Language Model Security Verification Standard is a list of specific AI and LLM security requirements or tests that can be used by architects, developers, testers, security professionals, tool vendors, and consumers to define, build, test and verify secure LLM driven applications.

Copyright and license

Copyright © 2008–2026 The OWASP Foundation. This document is released under the Creative Commons Attribution-ShareAlike 4.0 International License. For any reuse or distribution, you must make clear to others the license terms of this work.

Project leads

• Vandana Verma Sehgal
• Elliot Ward

Preface

Welcome to version 2.0 of the OWASP Large Language Model Security Verification Standard (LLMSVS), which provides a framework for evaluating the security of applications and systems that integrate Large Language Models (LLMs). This release builds on the initial 0.1 publication and subsequent community feedback.

Changes in this edition (v2.0): publication year and copyright notice are updated; front matter and table of contents are aligned with the frontispiece; editorial corrections apply across the requirement text (for example “completions” instead of “compilations,” standard hyphenation). Technical updates include: an OWASP ASVS cross-references subsection mapping ASVS 4.0.3 citations to ASVS 5.0.0 equivalents; clarified requirement 5.10 on safe error handling and logging versus client exposure; requirement 5.5 extended with optional structured-output guidance; clarified control objectives for V3 (real-time learning scope), V4 (RAG-style retrieval), and V6 (tools and protocol-based connectors); and Appendix A glossary additions (indirect prompt injection, retrieval-augmented generation, tool calling). The numbered verification requirements (V1–V8) and their identifiers match the verification set carried forward from the initial 0.1 release.

The LLMSVS aims to offer clear and practical guidelines that apply universally and assist developers, architects, security professionals, vendors, and researchers in securing LLM-powered systems.

The LLMSVS is the result of a collaborative effort drawing on the expertise of professionals across various sectors. It addresses the unique security challenges presented by LLMs, focusing on functional and non-functional security aspects. This version continues to lay the foundation for an adapting set of guidelines shaped by ongoing feedback and the changing dynamics of LLMs, emerging Artificial Intelligence (AI) technologies, and advances in cybersecurity.

The standard will continue to evolve based on contributions from the community and advancements in the field. We recognize that there is no one-size-fits-all security solution, especially in a field as emergent as AI, and we anticipate the need for regular updates and refinements.

We invite the broader community to participate in developing and enhancing the LLMSVS. We value the diverse perspectives and expertise each participant brings to this project. Your feedback and contributions are crucial to ensuring the standard remains relevant and practical.

We’d like to thank the contributors for their valuable input and look forward to your continued support and involvement in developing the LLMSVS.

Utilizing the LLMSVS

The OWASP LLMSVS serves several key purposes:

• Assisting development teams: guide teams in developing and maintaining secure LLM-powered applications.
• Framework for security teams: assist security teams in setting requirements, guiding security audits, and conducting penetration tests against LLM-powered systems.
• Aligning security benchmarks: establish a common ground for security service providers, vendors, and clients regarding security expectations.

Security verification layers

The LLMSVS categorizes security verification into three distinct levels, each tailored to different levels of security assurance:

1. LLMSVS Level 1 — Basic security: This level is aimed at applications with lower security risk and focuses on fundamental security controls for any LLM-powered system.
2. LLMSVS Level 2 — Moderate security: This level is ideal for applications handling sensitive data, offering a balanced approach to security that meets the needs of most applications. These applications may range from personal assistants, APIs processing customer data, or systems processing internal company data.
3. LLMSVS Level 3 — High assurance security: This level provides the most extensive security measures for the most critical applications involving sensitive data or high-value transactions. These applications may range from business critical applications that are essential for business operation, systems which handle financial transactions, or systems which fall under specific industry regulations such as those which process patient or healthcare data.

Each level of the LLMSVS provides a set of specific security requirements, mapping these to essential security features and practices necessary for building and operating robust LLM-powered applications. This approach equips developers, architects, and security professionals with practical and actionable guidelines. Whether building, enhancing, or evaluating the security of these applications, the LLMSVS provides a clear roadmap for all stakeholders involved in the life cycle of LLM-powered systems.

Assumptions

When utilizing the LLMSVS, it’s important to keep in mind the following assumptions:

• The LLMSVS is not a replacement for adhering to secure development best practices, such as secure coding or a Secure Software Development Life Cycle (SSDLC). These practices should be integrally adopted throughout your development efforts, with the LLMSVS serving to augment them specifically for LLM-powered applications.
• The LLMSVS is not intended to substitute for comprehensive risk assessments or in-depth security reviews. Rather, it serves as a guide to address potential security vulnerabilities specific to LLM-powered applications. Employing the LLMSVS should complement, not replace, these crucial security practices to ensure a more thorough evaluation and mitigation of risks.

While the LLMSVS offers a comprehensive framework for enhancing the security of LLM-powered applications, it cannot ensure complete security. It should be viewed as a foundational set of security requirements, with additional protective measures taken as needed to mitigate specific LLM risks and threats.

OWASP ASVS cross-references

Several LLMSVS requirements refer to the OWASP Application Security Verification Standard (ASVS) for controls that apply to the wider application as well as to LLM integration. Original citations in this document use ASVS 4.0.3 section numbering. ASVS 5.0.0 reorganized some material; assessors should satisfy the intent of each LLMSVS requirement using the ASVS edition their organization has adopted. The following mapping is illustrative for ASVS 5.0.0:

Assessment and certification

OWASP’s stance on LLMSVS certifications and trust marks

OWASP, as a vendor-neutral not-for-profit organization, does not currently certify any vendors, verifiers or software.

All such assurance assertions, trust marks, or certifications are not officially vetted, registered, or certified by OWASP, so an organization relying upon such a view needs to be cautious of the trust placed in any third party or trust mark claiming (LLM)SVS certification.

This should not inhibit organizations from offering such assurance services, as long as they do not claim official OWASP certification.

Guidance for certifying organizations

For Large Language Model Security Verification Standard (LLMSVS) compliance, an “open book” review is recommended, granting assessors access to essential resources such as system architects, developers, project documentation, source code, and authenticated interfaces, including access to at least one account for each user role.

It is important to note that the LLMSVS only covers the security requirements pertaining to LLM usage and integration. It does not cover general application security controls (for example web services) which are not specific to an LLM-powered system. Any additional systems and non-LLM properties should be verified against appropriate standards, such as the OWASP ASVS.

Certification reports should clearly define the verification scope, particularly noting any exclusions, and summarize findings with details on both passed and failed tests, including guidance for addressing failures. Industry-standard practice requires detailed documentation of the verification process, including work papers, screenshots, scripts for issue replication, and electronic testing records such as proxy logs. Automated tool results alone are insufficient; documentation must provide conclusive evidence of thorough and rigorous testing of all controls. In case of disputes, sufficient evidence should be present to verify that each verified control has indeed been tested.

V1. Secure configuration and maintenance

Control objective

Ensure that LLMs, hosted by a model provider or self-hosted, are configured and maintained securely to prevent unauthorized access and leakage of sensitive information.

V2. Model lifecycle

Control objective

Ensure that the Machine Learning (ML) lifecycle for models used within LLM-powered systems considers the various security threats from dataset curation, model training, and validation.

V3. Real time learning

Control objective

Establish controls to reduce the risks associated with real time learning within LLM systems, where the models are continuously fine-tuned based on user interactions in real time. This chapter addresses ongoing or near-real-time updates to model behavior or weights driven by live user data; it is distinct from conversational or long-term memory (see V4) and from batch or periodic training governed under V2, unless that training is applied continuously in production from user interactions at short intervals.

V4. Model memory and storage

Control objective

Ensure that mechanisms providing “memory” or additional knowledge not included during the training phase handle that information safely. This includes typical retrieval-augmented generation (RAG) patterns in which retrieved documents or embeddings are supplied as context to the model.

V5. Secure LLM integration

Control objective

Establish controls that enable safe interactions and operations between application components and LLMs.

V6. Agents and plugins

Control objective

The autonomous nature of agent-based systems—including use of tools, plugins, and protocol-based remote connectors (for example Model Context Protocol servers)—presents new risks and can increase the impact of attacks such as prompt injection. These controls aim to reduce the risk associated with autonomous LLM components to an acceptable level.

V7. Dependency and component

Control objective

Ensure that third-party components and dependencies are safely handled to reduce supply chain risk.

V8. Monitoring and anomaly detection

Control objective

Continuously monitor the use of LLM-powered applications to detect anomalous behavior or outputs that could indicate security incidents or system misuse.

Appendix A: Glossary

• Large Language Model (LLM) — A type of artificial intelligence model designed to understand, generate, and interact with human language, based on vast amounts of text data. LLMs can perform a variety of language tasks like translation, summarization, and question answering.
• Prompt Injection — A technique where an attacker intentionally crafts inputs (or “prompts”) to manipulate or exploit the behavior of an LLM. This can involve inserting misleading, biased, or malicious information in a prompt to influence the model’s output.
• Indirect Prompt Injection — An attack where untrusted content reaches the model without being supplied directly as the end user’s current message—for example via retrieved documents, tool outputs, email bodies, web pages, or stored data that is later included in context—causing the model to follow attacker-chosen instructions or to leak or misuse data.
• LLM Agent — A software entity or bot that utilizes a Large Language Model to perform tasks, answer queries, or interact in conversations, often designed to automate certain functions or provide user assistance.
• Tool Calling (Function Calling) — A pattern where the model emits structured requests to invoke application-defined or third-party capabilities (tools, APIs, or functions), which execute outside the model and whose results may be fed back into the conversation. Security depends on validation, authorization, and least privilege for each tool.
• Model Poisoning — A malicious attempt to influence or corrupt a machine learning model’s training data, causing it to learn incorrect, biased, or harmful behaviors.
• Natural Language Processing (NLP) — The field of computer science and artificial intelligence focused on enabling computers to understand, interpret, and generate human language.
• Transformer Architecture — A neural network architecture used in many modern LLMs. It is known for its ability to handle sequential data and its effectiveness in tasks involving natural language.
• Tokenization — The process of converting text into smaller units (tokens), such as words, characters, or subwords, which can be used as input for language models.
• Fine-Tuning — The process of taking a pre-trained model and further training it on a specific dataset to specialize it for particular tasks or domains.
• Retrieval-Augmented Generation (RAG) — An architecture where relevant documents or passages are retrieved (often from a vector store or search index) and provided as context to an LLM to improve factual grounding. RAG introduces supply-chain, access-control, and prompt-injection risks in the retrieval path and in how retrieved text is combined with user input.
• Data Privacy — Concerns related to the handling, processing, and storage of sensitive or personal information by language models, especially when dealing with user inputs.
• Bias in AI — The phenomenon where AI models, including LLMs, exhibit biased behavior, often as a result of biased training data or algorithms.
• Adversarial Attack — A strategy where attackers create inputs to deceive AI models into making errors. This is particularly concerning in security-sensitive applications of LLMs.
• Principle of Least Privilege — A security concept that involves granting users or systems the minimal level of access or permissions necessary to perform their tasks. This principle helps minimize potential damage from accidents or malicious attacks by limiting access rights for users to the bare minimum necessary to complete their duties.