OWASP AI Security and Privacy: The Complete 2026 Guide

OWASP's original "AI Security and Privacy Guide" has been rebranded as the OWASP AI Exchange, with the new name intended to reflect the collaborative effort's international nature. It was awarded the status of the OWASP Flagship Project in March 2025, alongside the newly established OWASP Gen AI Security Project. The document now contains over 300 pages created by more than 70 contributors and serves as a comprehensive guide to AI-related threats, controls, and best practices throughout the system life cycle. It also provides input to standards such as the EU AI Act, ISO/IEC 27090, and ISO/IEC 27091.

However, the AI Exchange is just one of several projects under the OWASP AI umbrella that are often confused with one another. This blog post aims to provide clarity on the differences between the OWASP AI Exchange (security and privacy concerns related to all AI systems), the OWASP GenAI Security Project (security concerns related to Generative AI), OWASP Top 10 for Large Language Model Applications (a living document that lists common risks associated with LLMs).

From “AI Security and Privacy Guide” to OWASP AI Exchange

The project is not the flagship one; initially, it was represented only by the first guide, and the description of the development history gives a clear idea of how the current state was achieved. Below, the reasons for renaming and the Flagship status of the project are discussed, which indicates its level of maturity and impact.

Why It Was Rebranded

The project was initially started in 2022 by Rob van der Veer under the name "AI security and privacy guide." After a year, it was renamed to "AI Exchange" to reflect the emphasis on international collaboration in the work. This is important because by naming it a "guide," it would suggest that it is a document created by OWASP and that the responsibility for it lies solely with the foundation. By calling it an "exchange," it shifts the focus to the collaboration that goes into the creation of the resource, and not just the result. It is now an open-source living publication that facilitates international exchange of knowledge on the security and privacy of AI, edited by the community and not just one publisher, with contributions from academia, industry, and standardization bodies.

The new name also better reflects the work that the project does, as it aims to be the single source of information for security and privacy practitioners that work with AI and data-centric systems, as well as a place that facilitates the collaboration between various initiatives that work on similar problems, and not just one specific solution.

Flagship Project Status and What That Means

The AI Exchange became a flagship project of OWASP in March 2025. This is because of its importance to the community, as the project provides critical infrastructure for the security and privacy of AI. The AI Exchange and the OWASP GenAI Security Project are the only flagship projects of OWASP, which means that they have met the standards of innovation, technical quality, and community impact, and have the potential to attract resources to support their ongoing development and growth.

In the case of the AI Exchange, it has already gained much external support and impact, as it provides content that is used in the development of the EU AI Act, ISO/IEC 27090 on AI Security, ISO/IEC 27091 on AI Privacy, and Open CRE. It is licensed under CC0 1.0, which means that it is open source and can be used freely, without any restrictions or requirements. This better reflects the purpose of the project, as it is not just a guide that is used by one organization, but rather a resource that is shared and built upon internationally, hence why it is called an exchange.

What the AI Exchange Actually Covers

The AI Exchange’s scope and influence are two different questions, and the Exchange covers both. Below, we discuss the breadth of AI systems that the Exchange actually addresses, and then turn to where the content actually ends up once it leaves the OWASP ecosystem. What the AI Exchange Actually Covers

All AI, Not Just Generative AI - Analytical, Discriminative, Generative, Heuristic

The AI Exchange is a foundational core of threat models, controls, and related best practices for all AI, not just generative AI. It covers all classes of AI, including analytical, discriminative, generative, and heuristic, and beyond security, it also covers privacy, which is the key differentiator from projects that are focused more narrowly on language models or chatbots. In practice, this means that the Exchange’s taxonomical coverage of threats is relevant to whatever flavor of AI you happen to be using - be it a statistical analytical model, a discriminative classifier, a generative model, or even a heuristic system. The threat models and controls apply to all of these approaches, though of course with important variations depending on the particular flavors of AI.

This is also the key differentiator between the Exchange and the other major OWASP AI project, the OWASP Gen AI Security Project, which is a collection of documents focused exclusively on Generative AI security, including the LLM Top 10. The two projects are intended to complement each other, with the Exchange representing a horizontal approach applicable to all AI systems while GenAI Security tackles the vertical challenge of addressing generative AI-specific concerns. If you are using an analytical AI system and not a generative one, the Exchange is for you. If you are using a generative AI system, the Exchange is still for you, but you should also consult the Gen AI Security Project for guidance specific to large language models.

Contributing to ISO/IEC Standards and the EU AI Act

The Exchange’s impact extends beyond the OWASP ecosystem. It is used as a reference for standardization work both in the EU AI Act and in the ISO/IEC standards for AI security and privacy, including ISO/IEC 27090 and 27091. The latter two standards, which concern AI security and privacy, respectively, each include 70 pages of content contributed by the Exchange. This work is overseen by Rob van der Veer of the Software Improvement Group, who coordinates the standardization work based on the Exchange.

The Exchange’s reach extends beyond the OWASP community to influence international standardization efforts, which puts the project in a unique position to shape the development of regulations and standards for AI security. By contributing directly to the development of the EU AI Act and to the ISO/IEC standardization work, the Exchange’s content is formally adopted into works that will have a regulatory or contractual impact on organizations worldwide. This is an important distinction, as it elevates the role of the Exchange beyond a reference framework to one that actively influences how organizations can and should operate in practice.

How This Relates to Three Other OWASP AI Projects

The AI Exchange program is part of the OWASP efforts related to securing AI. These efforts are currently split between multiple areas: what the threats are, how to design against them, how to verify that the controls are implemented, and how to test those controls.

The GenAI Security Project (LLM Top 10, Agentic Top 10)

The OWASP GenAI Security Project is a working group that focuses on documenting the unique security challenges introduced by generative AI. Together with this project, the AI Exchange comprises two of the three current OWASP projects related to AI security. The GenAI Security Project concentrates on the unique challenges introduced by Generative and Agentic AI (the LLM Top 10 and Agentic Top 10), while the AI Exchange contains the general concepts applicable to all types of AI systems. In other words, if you are building or reviewing an LLM or Agentic security solution, the resources produced by the GenAI Security project will give you concrete threat models and controls, while the Exchange serves as their foundational layer.

OWASP AISVS - The AI Security Verification Standard

The OWASP AISVS comprises a community-maintained list of requirements related to the development of secure AI applications. It serves as a reference for developers, architects, auditors, and security engineers who seek to design and build trustworthy AI applications. The standard follows the same principles as the OWASP ASVS (Application Security Verification Standard) and is actually based on it. For example, just like ASVS, AISVS lists requirements in the form of statements that should be verifiable and testable and can be prioritized depending on the requirements level (1 - basic, 3 - comprehensive).

The Level 1 requirements represent the minimum needed to build a secure AI application, while Level 3 requirements are typically relevant to applications that process sensitive information or operate in safety-critical domains (such as healthcare or defense). Similarly to how ASVS expands upon the OWASP Top 10, AISVS serves as an expansion of the OWASP AI Exchange, providing a list of requirements that can be used to design and audit AI applications. It only standardizes the requirements related to AI/ML – for all the other requirements, refer to the ASVS standard directly.

OWASP AITG - The AI Testing Guide

OWASP AITG (the AI Testing Guide) provides a practical framework for testing AI applications. It is based on attack surface prioritization and incorporates existing global standards for testing and verifying AI applications. This guide was released in version 1 in November 2025 and organizes AI application testing around the four layers of the Google Secure AI Framework (SAIF): Applications, Models, Infrastructure, and Data. Its key innovation is that it adds the requirements related to trustworthiness beyond standard security testing. In other words, it acknowledges that many AI applications, especially generative AI, can pass standard security assessments while still having issues related to their unique attack surfaces, such as hallucination, data privacy, toxicity, etc. AITG builds upon AISVS by providing concrete steps for testing the controls listed there.

Inside OWASP AISVS 1.0: The 14-Chapter Checklist

OWASP recently released the first stable version of AISVS in late June 2026. This document contains 14 chapters of pass/fail requirements designed to turn AI governance directives into auditable, demonstrable controls. These requirements concern everything from prompt injection to MCP server authentication. Unlike more governance-focused standards, AISVS is not focused on controls that dictate “what” should happen; rather, it emphasizes controls that can be audited to demonstrate that a specific result has occurred. Notably, Jim Manico, who previously led the development of the ASVS, now leads the initiative to develop AISVS. This new standard follows the same principles as the ASVS: if it can’t be checked, it isn’t included.

Training Data, Input Validation, and 73% Prompt Injection Stats

The document’s requirements cover the entire AI lifecycle, including but not limited to training data, input validation, model lifecycle, infrastructure and deployment, access control, supply chain, model behavior and output, memory, vector databases, orchestration and agents, MCP, adversarial, privacy, logging and monitoring, and human factors. Notably, the input validation chapter includes requirements developed based on research indicating that as of 2026, 73% of production AI deployments are vulnerable to prompt injection attacks. Additionally, the standard includes requirements that specify instruction hierarchies, including ensuring model behavior follows system and developer instructions over user input, even when user instructions are embedded in system messages.

The MCP Security Chapter

As agentic systems increasingly rely on the Model Context Protocol (MCP) to enable communication between models and external tools, AISVS provides explicit requirements for securing these interactions. Specifically, chapter C10 is dedicated to addressing security concerns related to the Model Context Protocol. Additionally, the document includes a separate chapter (C12) focused on orchestration and agents. Together, these sections highlight the importance of securing communications between agents and tools while recognizing that these interactions pose different security challenges than traditional prompt injection attacks addressed in earlier chapters. Appendix B to the standard also provides guidance on applying the requirements to specific use cases, including code generation, by cross-referencing them with tools, actions, and additional controls.

Assurance Levels 1-3 and the four use cases (Design, development, assessment, and procurement)

Although AISVS requirements are not organized around use cases, they do include different levels of assurance. Notably, most of the requirements are not strictly mandatory - rather, organizations must determine which of the three levels of assurance (1 - 3) applies to their use case based on their risk management needs. As a result, Level 1 focuses on controls that should be implemented for all AI systems, including those used internally and those that do not process sensitive data. In contrast, Level 2 includes requirements that are mandatory for all systems that handle sensitive information or operate at the production level. Finally, Level 3 focuses on specialized controls that should be implemented for systems that require the highest level of security assurance. It is notable that, for most production systems, Level 2 represents the minimum level of security assurance that should be achieved.

Additionally, although the standard is not structured around the idea of use cases, it is critical to understand how it can be applied in practice. In particular, organizations can use AISVS in some different ways, including as a design specification when planning AI initiatives, as a component of the development lifecycle, an assessment tool for penetration testing and auditing activities, and as a reference when considering the procurement of AI technologies. Notably, when it comes to procurement, the standard provides explicit instructions for assessing the security posture of potential suppliers. This capability is especially valuable for organizations trying to evaluate the security practices of third-party providers, including AI model suppliers, which can serve as an important basis for selecting providers that share their security posture and principles.

Where the AI Exchange is Headed in 2026

The AI Exchange has a set of priority content workstreams that will see major updates ahead of summer 2026, but two areas stand out as major statements of intent for the future of the project: pushing the Exchange into agentic systems, and establishing stronger connections to other security frameworks that enterprises are already using.

The Agentic AI Extension

One area of major focus for the Exchange is agentic applications and security controls - and the workstream that will deliver on that promise doesn't have a name yet. This workstream, led by Chris Cochran, dovetails directly with the OWASP Top 10 for Agentic Applications 2026 being developed by the new OWASP Agentic Security Initiative. The Top 10 represents the consensus-driven risk taxonomy for autonomous AI applications, including multi-agent systems, and reflects the unique threat model introduced by those architectures - an agentic AI, unlike a chatbot, can perceive and react to its environment, make independent decisions, and perform complex tasks, including using other tools with which it has been granted access and permissions.

As the Exchange's agentic workstream develops in the coming months and years, it will almost certainly look to intersect with the Top 10 for Agentic Applications, just as the main Exchange is currently positioned to complement the General AI Security Project's LLM Top 10 - foundational threat modeling on one side, an actively maintained, risk-prioritized threat list on the other.

Harmonization with NIST, MITRE ATLAS, and ETSI

Meanwhile, another significant 2026 workstream is centered around reconciling the Exchange with other major security frameworks, including NIST, MITRE ATLAS, and ETSI. This work is critically important to the future of the Exchange - while the project has always focused on being OWLAP's hub for AI security, many enterprises currently have to contend with a reality in which they must satisfy requirements from multiple frameworks at once - a NIST AI RMF assessment for one stakeholder, a MITRE ATLAS-based red team assessment for another, and an ETSI-compliant technical report for a third. Meanwhile, MITRE ATLAS itself serves as a continuously updated repository of adversarial techniques against AI systems.

Rather than ask practitioners to interpret the similarities and differences between the Exchange and those frameworks, the harmonization workstream will serve to make the Exchange act as a kind of universal translator for those standards. Relatedly, but separately, is another EU AI Act "flow back" workstream led by Rob van der Veer that will see the Exchange better incorporate the AI Act-related research conducted by OWASP as a whole - and again, that includes work done outside of the Exchange itself. Taken together, the various projects indicate a desire to see the Exchange grow as the unifying force for AI security within OWASP, rather than a standalone framework competing with other methods for adoption and attention.

How to Actually Use OWASP AI Projects Together

The four projects described above are not mutually exclusive; they are layers, and any given team is likely to use all of them in concert on a single project, or at different stages of a project's lifecycle, rather than choosing between them. The confusion around which project to use for which purpose probably stems from the fact that they can be used together, and the different stages at which one might apply each. With this in mind, here's a breakdown on how to use the four projects together, in the context of a single system.

Threat model with the AI Exchange

At the design stage, for any system, regardless of its nature (fraud detection classifier, recommendation model, or an LLM). The Exchange is the most generic of all four projects, and therefore should be used as a starting point for threat modeling any system, before moving on to more specific risk taxonomies.

Bring in the Gen AI Security Project, depending on the nature of the system being secured.

If the system is an LLM, the most relevant starting point will be the LLM Top 10, which prioritizes risks specific to language models over the more generic Exchange taxonomy. If the system is not an LLM but is instead agentic (i.e., has autonomy and uses tools), then the most relevant starting point will be the Top 10 for Agentic Applications, which includes risks not present in the Exchange or LLM-specific lists.

Specify requirements with AISVS, based on the threat model or risk list.

Threat modeling and risk listing are useful precursors to design review or penetration testing, but to actually incorporate security and privacy into the development process, one needs requirements, which is where AISVS comes in. AISVS turns security and privacy risks into testable requirements, which can then be used as the basis for a design review, a CI/CD scan, or a pen test.

Use the same requirements for procurement, if applicable.

The same requirements that one would use to review an in-house system can be used to evaluate a third-party system, in the form of a questionnaire. This allows the same security and privacy criteria to be applied to both in-house and third-party systems, which is important for consistency.

Use AITG to verify that the system meets the requirements.

AISVS specifies what should and shouldn't be present in a system; AITG specifies how to actually test for these things, in the form of a testbed that covers the same four-layer model (Application, Model, Infrastructure, Data) as AISVS, but goes beyond security to test for trustworthiness properties like fairness and reliability, which are not captured by traditional security testing.

When used together, as a pipeline from threat modeling to verification, these four projects answer the question posed in this piece's introduction most directly: when in doubt about which OWASP AI Project to use, use them all, in this order.

Final Thoughts on OWASP AI Security and Privacy

OWASP has done an incredible job identifying the security challenges unique to AI - Exchange for threat modeling, GenAI Security Project for prioritized LLM and agentic risk, AISVS for testable requirements, AITG for verification. However, there is an important space it cannot cover - implementation in your CI/CD. This is where Akto steps in

Akto takes the OWASP LLM Top 10 and transforms it into 60+ automated test cases executed before every release as actual code, scanning all AI agents and MCP servers your team has across all environments. All decisions, tool usage, and execution paths during testing are evaluated at runtime using policies aligned with the OWASP Agentic Security Initiative. The same rigorous approach is rooted in Akto’s experience securing complex application environments and has evolved into a purpose-built approach to Agentic AI Security.

Fortune 500 security teams and 1000+ AppSec teams rely on Akto to stay ahead of this curve. If you want to bring OWASP AI standards to your DevOps practice and secure the future of your software development, make sure to check out Akto’s AI Agent Security.

FAQs on OWASP AI Security and Privacy

1. What is OWASP AI Exchange, and how is it different from the Gen AI Security Project?

OWASP AI Exchange covers all areas of AI and includes privacy as well as security, while the Gen AI Security Project is a complementary set of documents focused exclusively on Generative AI, including the LLM Top 10. Together, they represent the broadest understanding of OWASP's approach to security: the AI Exchange touches on all verticals, while the Gen AI project digs deeper into one particular area.

2. What is OWASP AISVS, and when was version 1.0 released?

AISVS stands for Artificial Intelligence Security Verification Standard, a community-driven set of testable requirements for developing secure AI applications that can be used by developers, architects, auditors, and security teams alike, and version 1.0 was released at the end of June 2026.

3. What does the new AISVS's Chapter C10 say about securing Model Context Protocol?

It describes security recommendations specific to model context protocols, plus gives implementation guidance for downstream tools, and one of the chapters in the standard (C10) is dedicated to discussing the security aspects of autonomous orchestration and agentic AI, covering the unique attack surfaces that arise from interactions between agents and their tools beyond prompt injection and similar model-level concerns. This chapter and the accompanying guidance recommend specific testing approaches for such agentic applications based on the principles established in AISVS.

4. How many production AI applications were estimated to be vulnerable to prompt injection in 2026?

According to the research published in 2026, 73% of production AI applications were estimated to be vulnerable to prompt injection, which AISVS addresses by specifying controls necessary to implement an instruction hierarchy that would allow system and developer instructions to override end-user input.

5. What is the OWASP AI Testing Guide (AITG), and how is it different from AISVS?

The AITG defines how to perform a trustworthiness assessment using attack-focused language grounded in practice, while also introducing the concepts necessary to understand the four-layer architecture (Application, Model, Infrastructure, and Data) of modern AI systems. Unlike AISVS, which focuses on defining what security controls are necessary, it actually specifies what testing procedures can be used to assess each of them, and goes beyond conventional security testing by addressing other aspects of trustworthiness, since AI systems are capable of hallucinating responses, leaking training data, and failing in other unexpected ways even when secure.

6. Does the AI Exchange include coverage for areas beyond generative AI, like discriminative or analytical models?

Yes, it covers all classes of AI models that use a variety of techniques, including exchange-based, analytical, discriminative, generative, and heuristic methods, and security concerns applicable to all of them are discussed in the documents, beyond the specifics of large language models and chatbots.

7. How does the AI Exchange relate to the ISO/IEC standardization efforts and the EU AI Act?

By virtue of the official liaison partnership, the contents of the AI Exchange feed directly into the standardization efforts of the EU AI Act (with 70 pages of direct input) and the ISO/IEC 27090 and 27091 documents on AI security and privacy, respectively.

8. Which of these OWASP AI projects would you recommend for vendor procurement, development, or testing?

When procuring third-party AI models and applications, AISVS requirements can be used as selection criteria. When developing one's own applications, AISVS can be used as the primary reference throughout the development lifecycle, and AITG can be used to test the security, privacy, and overall trustworthiness of the finished product.