80. OWASP AI Testing Guide v1 Explained: A Practical Standard for Testing AI Trustworthiness (With a Copy/Paste Test Plan)

Last Updated: May 31, 2026

Two years ago, AI red teaming was a phrase used mostly by frontier labs and a few paranoid CISOs. In 2026, the OWASP AI Testing Guide has turned it into the industry’s first community-driven standard for trustworthiness testing of AI systems — and the landscape it describes is far more demanding than what most organizations are currently doing. According to Adversa AI’s 2025 security report, 35% of real-world AI security incidents were caused by simple prompts, with some leading to losses exceeding $100,000 per incident. The EU AI Act requires adversarial testing as part of the risk management system for high-risk AI systems, with full compliance required by August 2, 2026. And according to the OWASP AITG’s own framing: the industry is converging on the principle that security is not sufficient — AI trustworthiness is the real objective.

Released in November 2025 as Version 1, the OWASP AI Testing Guide represents a paradigm shift that practitioners working under older frameworks need to understand. Traditional software testing was built for deterministic systems — the same input produces the same output, and a bug either exists or it does not. AI systems fail probabilistically. They can be secure against hackers but still produce toxic content, hallucinate facts, or leak training data. They can pass every security scan in your CI/CD pipeline and then fail catastrophically when a human tries to break them on purpose. The OWASP AITG’s first and most consequential contribution is codifying this difference: AI systems require a testing discipline that evaluates trustworthiness properties — fairness, reliability, transparency, and safety — alongside the security threat model that traditional testing addresses.

This upgrade covers everything you need to operationalize the OWASP AI Testing Guide v1 in 2026. You will find a complete copy-paste testing checklist organized by the guide’s four architectural layers, a 5-step testing process with specific tool recommendations at each step, a framework comparison table that positions the AITG against OWASP LLM Top 10 and NIST AI RMF, and a 2026 tool landscape section that gives you the current state of every major AI testing tool your team should know. For the adversarial testing techniques that feed into this process, our guide to LLM red teaming for beginners covers the offensive methodology in detail. For the ongoing monitoring that follows testing, our guide to AI monitoring and observability covers the post-deployment quality management framework that makes testing a continuous practice rather than a one-time pre-launch event.

1. 🏗️ OWASP AI Testing Guide v1: The Four-Layer Testing Architecture

The OWASP AI Testing Guide v1’s most important structural contribution is its decomposition of AI systems into four testable layers: Application, Model, Infrastructure, and Data. This architecture — aligned with Google’s Secure AI Framework (SAIF) — solves the most common failure in AI security programs: testing the chatbot interface while missing the model-level vulnerabilities, the infrastructure misconfigurations, and the data supply chain risks that represent the majority of real-world AI attack surfaces. Every test in the AITG maps to at least one of these four layers, and a complete testing program requires coverage across all four.

The Application Layer covers the AI system as users and external callers experience it — the API endpoints, the user interface, the integration points with external systems, the prompt handling pipeline, and the output processing chain. This is where prompt injection, jailbreaking, context manipulation, and output-based attacks (XSS, SSRF, RCE through AI-generated code or content) primarily manifest. It is the layer that most security teams test, and the layer that most OWASP LLM Top 10 checklist items address. Testing the application layer is necessary but not sufficient — because the vulnerabilities in the three layers below it are invisible from the application layer alone.

The Model Layer covers the trained model itself — its weights, its behavior boundaries, its susceptibility to adversarial examples, its training data memorization, and its resistance to model extraction attacks. Testing at the model layer requires direct API access to the model or, for open-weight deployments, the ability to query it directly. The Infrastructure Layer covers the deployment environment — cloud configuration, access controls, logging and monitoring setup, API gateway configuration, and the security of the model serving infrastructure. The Data Layer covers the training data pipeline — data provenance, poisoning risk, privacy exposure from memorized training data, and the integrity of retrieval-augmented generation (RAG) systems. Each layer has distinct threats, distinct testing methods, and distinct tooling — and the AITG’s value is providing a unified framework that connects all four.

The Trustworthiness Properties That Testing Must Cover

Beyond the four-layer architecture, the OWASP AITG defines six trustworthiness properties that a complete AI testing program must evaluate: Security (resistance to adversarial attacks and exploitation), Fairness (consistent, unbiased treatment across demographic groups and use cases), Reliability (consistent, predictable behavior within defined operational parameters), Privacy (protection of personal data processed by the AI system and memorized from training), Transparency (explainability of AI decisions and auditability of AI behavior), and Safety (freedom from harmful outputs and behaviors that could cause real-world harm). The critical insight of the AITG is that an AI system can score well on security testing and still fail on fairness, reliability, or safety — and that failure can cause equal or greater real-world harm than a security breach. A credit-scoring model that is fully secure against adversarial attacks but systematically disadvantages certain demographic groups fails the trustworthiness standard even if it passes every security test.

2. 📊 OWASP AI Testing Guide vs OWASP LLM Top 10 vs NIST AI RMF: Framework Comparison

The AI security and governance framework landscape in 2026 includes three documents that practitioners frequently conflate — because each is authoritative, each is widely cited, and each addresses overlapping but distinct concerns. Understanding how they differ is essential for building a testing program that satisfies regulatory requirements without duplicating effort. The OWASP AI Testing Guide is the testing methodology — it tells you how to test. The OWASP LLM Top 10 is the vulnerability taxonomy — it tells you what to test for. The NIST AI RMF is the governance framework — it tells you how to manage AI risk organizationally. They are complementary, not competing.

The practical workflow that most mature AI security programs follow in 2026 is: use the NIST AI RMF to establish the organizational governance structure that owns AI testing as a program; use the OWASP LLM Top 10 as the vulnerability taxonomy that guides what to test for; and use the OWASP AI Testing Guide as the testing methodology that governs how tests are designed, executed, and documented. Our related guide to the OWASP Top 10 Risks for LLMs and GenAI Apps covers the specific vulnerability categories in the LLM Top 10 with practical mitigation guidance for each.

3. 📋 Complete OWASP AI Testing Checklist: Copy-Paste Ready (2026)

The checklist below covers the primary test categories across the OWASP AI Testing Guide’s four-layer architecture. It is organized as a practical working document — use the Pass/Fail column to track test results during an assessment, and the Why It Matters column to explain findings to stakeholders who are not security specialists. The checklist is designed to be technology-agnostic: each test category applies whether you are testing a custom-fine-tuned LLM, a RAG-based enterprise chatbot, an agentic workflow system, or a predictive ML model deployed in a consequential decision-making context. Adapt the specific test cases to your system’s architecture and deployment context — the categories are universal, the implementation details are not.

Checklist usage instruction: Complete this checklist in two passes. First pass: automated tooling (Garak for model-layer probes, Promptfoo for application-layer OWASP preset). Second pass: manual expert testing targeting the failure categories automated tools flag and the advanced patterns (multi-turn attacks, context manipulation, agentic tool misuse) that automated tools miss. Document evidence for every Pass result — a pass without evidence is an assertion, not a finding.

4. 🔧 How to Run an OWASP AI Test in 5 Steps

The OWASP AI Testing Guide’s methodology follows a structured assessment lifecycle that mirrors the OWASP Application Security Verification Standard’s approach — organized around phases that build on each other sequentially, with documentation requirements at each stage that create an auditable evidence trail. The five-step process below integrates the AITG methodology with the specific tooling available in 2026, giving security teams a practical implementation guide rather than an abstract framework description.

Step 1: Define Scope, Objectives, and Threat Model

Every OWASP AI test begins with scope definition — and AI scope definition is more complex than traditional application security scoping because it must address all four architectural layers. Document the following before a single test is run: the AI system’s components and their interconnections (model, application layer, RAG pipeline, tool integrations, infrastructure); the deployment context and user population; the data classification of all data the system processes or is trained on; the threat actors relevant to your specific deployment (curious users testing boundaries, malicious users seeking to extract data, adversarial data sources attempting to poison RAG inputs, malicious upstream model providers); and the harm categories that are most consequential for your specific deployment context.

The threat model output should map your system’s attack surface to OWASP LLM Top 10 categories and MITRE ATLAS techniques — this mapping becomes the test plan that governs which tests are in scope and which are not. For most enterprise AI deployments in 2026, indirect prompt injection via RAG content and agentic tool misuse are the highest-priority threat categories — the ones where a successful attack has the largest blast radius and the ones that automated scanning tools address least thoroughly. Define those explicitly in your scope document before testing begins.

Step 2: Automated Breadth Scanning

Run automated tools against all in-scope surface areas to establish a baseline of known vulnerability exposure. This step should be time-boxed — it is the triage map, not the finding. The recommended tooling for automated breadth scanning in 2026 follows a clear specialization: use Promptfoo for application-layer scanning (its OWASP LLM Top 10 preset maps findings directly to the framework and its GitHub Actions integration makes it CI/CD native); use Garak for model-layer probe-based scanning (its 120+ probe library covers prompt injection, jailbreaks, encoding bypasses, glitch tokens, training-data extraction, toxicity, and XSS via output — fire it at your model endpoint like Nmap against a network). For RAG-specific testing, use Promptfoo’s RAG and retrieval attack test cases to probe for indirect prompt injection through document retrieval.

The output of Step 2 is a severity-ranked list of failure categories — the exposure map that directs manual effort in Step 3. Time-box automated scanning to a few hours, not a few weeks. Automated tools find the low-hanging fruit quickly. The interesting findings — the multi-turn attack chains, the agentic tool abuse scenarios, the demographic bias patterns that only emerge across many prompts — come from the manual work that follows.

Step 3: Manual Expert Testing on High-Priority Findings

Manual testing by a skilled security professional is irreplaceable in the OWASP AI Testing Guide’s methodology — because automated tools cannot improvise, cannot reason about your system’s specific business logic, and cannot chain attack scenarios dynamically based on what they discover mid-test. Use PyRIT for the manual depth phase: its compositional design (converters, orchestrators, scorers) allows you to build custom multi-turn attack campaigns targeting the specific failure categories your automated scan flagged. PyRIT’s Crescendo technique — a multi-turn escalation approach where the AI is gradually guided toward harmful outputs through seemingly innocent incremental steps — and Tree-of-Attacks-with-Pruning (TAP) technique represent the state of the art in systematic jailbreak testing in 2026.

For agentic systems, manual testing must address the tool-use attack surface that automated scanners do not reach. Test every pathway through which untrusted text reaches the model — RAG documents, tool call outputs, web browsing results, email content in email-integrated agents — for indirect prompt injection. Test whether adversarial inputs can cause the agent to invoke tools in unauthorized ways or chain tool calls to escalate beyond its intended permission scope. For each finding, document: reproduction steps that another tester can follow, the OWASP LLM Top 10 or MITRE ATLAS category the finding maps to, the severity assessment in the context of your deployment, and a transcript or evidence artifact that supports the finding.

Step 4: Bias, Fairness, and Trustworthiness Assessment

Step 4 is where the OWASP AI Testing Guide departs most dramatically from traditional security testing — and where most enterprise security teams have the least existing capability. The trustworthiness properties of fairness, reliability, and transparency require testing methodologies that security engineers are not typically trained for and that security tools are not typically designed to assess. Design a set of demographically paired test prompts — prompts that are identical except for demographic signals (names, locations, professional titles associated with different demographic groups) — and compare the AI system’s outputs systematically for tone, quality, completeness, and recommendation differences. Statistical analysis across at least 100 paired prompts is required to detect the subtle disparities that constitute bias; single-prompt comparisons are not sufficient.

For reliability testing, measure the consistency of the system’s outputs across repeated identical or near-identical inputs — including testing consistency across different times of day, different context window lengths, and different conversation histories. For transparency testing, evaluate whether the system provides explainable rationales for consequential outputs and whether those rationales accurately reflect the actual factors driving the output. Systems that provide explanations that do not match their actual decision logic — a known failure mode in chain-of-thought prompted models — fail transparency testing even if their security posture is strong.

Step 5: Document, Report, Remediate, and Retest

Each finding from Steps 2, 3, and 4 requires a structured finding report that includes: reproduction steps, severity rating, affected harm category, OWASP AITG layer and trustworthiness property, OWASP LLM Top 10 and/or MITRE ATLAS mapping, suggested mitigation with implementation guidance, and evidence artifacts. The severity rating should always be assessed in the context of your deployment — a moderate hallucination rate that is acceptable for an entertainment chatbot may be unacceptable for a clinical decision support tool. After remediation, every finding must be retested to confirm the fix is effective and has not introduced new failure modes. Re-test after every significant model update, every change to the RAG knowledge base, and every change to the system prompt — all three can alter behavior in ways that invalidate previous test results. Our guide to AI monitoring and observability covers the continuous monitoring framework that makes post-deployment testing a structured practice rather than an ad-hoc response to incidents.

The OWASP AI testing cadence rule for 2026: Pre-deployment testing is the minimum, not the program. Re-test after every model update, every RAG knowledge base change, and every significant system prompt modification. Foundation model behavior changes between versions — a mitigation that blocked an attack yesterday may not work after the underlying model is updated. The EU AI Act’s post-market monitoring requirements for high-risk AI systems reflect this reality: testing is a continuous obligation, not a one-time gate.

5. 🛠️ Tools for OWASP AI Testing in 2026

The AI security tool landscape has matured significantly since the OWASP AI Testing Guide v1 was published in November 2025. The 2026 landscape is characterized by consolidation and integration: open-source tools are increasingly embedded inside platform-vendor offerings, commercial platforms are adding agentic AI testing capabilities that open-source tools do not yet cover, and the line between AI red teaming and continuous AI monitoring is blurring as organizations move from point-in-time assessments to continuous adversarial testing programs. Understanding the specialization of each tool — and where it fits in the five-step testing process above — is more important than choosing a single tool and expecting it to cover everything.

Garak (NVIDIA, Apache 2.0): Garak is the closest thing to an Nmap for LLMs — a probe-based vulnerability scanner that ships with roughly 120 prebuilt probes covering prompt injection, jailbreaks, encoding bypasses, glitch tokens, training-data extraction, toxicity, XSS via output, and malware generation. A single Garak run can fire up to 20,000 prompts against a model endpoint and produce a structured report with pass/fail per probe. Current version: Garak v0.14.0 (the –generate_autodan CLI flag was removed and the JSONL report format changed — review your report parsing scripts before upgrading from v0.13.x). Best for: CI/CD regression scans on every model release; pre-release compliance checks; comparing two model versions side-by-side. Key limitation: Garak tests models, not full applications — it does not understand your RAG pipeline, agent tool graph, or MCP integrations.

PyRIT (Microsoft, MIT License): PyRIT — the Python Risk Identification Toolkit for GenAI — is the compositional attack platform for custom multi-turn campaign development. Its architecture of converters (input transformers), orchestrators (attack campaign managers), and scorers (output evaluators) allows security researchers to build attack pipelines that no probe library covers. PyRIT implements Crescendo and Tree-of-Attacks-with-Pruning (TAP) for automated multi-turn jailbreaking. Note: The Azure/PyRIT repository was archived in March 2026 and active development continues at microsoft/PyRIT. PyRIT v0.11.0 renamed MultiTurnAttackResult to OrchestratorResult — update existing multi-turn scripts before upgrading. Best for: Multi-turn jailbreak campaigns, custom attack pipeline development, deep manual investigation of findings from automated scanning.

Promptfoo (OpenAI acquisition pending, MIT License): Promptfoo provides application-layer test coverage with a native OWASP LLM Top 10 preset that maps findings directly to the framework — OWASP itself lists Promptfoo as a recommended security solution. Its YAML configuration, GitHub Actions integration, and LLM-as-judge scoring make it the most CI/CD-native option in the open-source AI testing stack. Note: OpenAI announced the acquisition of Promptfoo in March 2026 (deal not yet closed as of May 2026) — pin your dependency version and monitor the repository for governance changes. Best for: CI/CD pipeline integration; compliance-driven OWASP LLM Top 10 evidence generation; teams without dedicated AI security engineers.

DeepTeam (Confident AI, Apache 2.0): DeepTeam offers the clearest OWASP LLM Top 10 mapping and the simplest onboarding of the major open-source AI testing tools — making it the recommended starting point for teams evaluating AI testing tooling for the first time. Its Python-native interface and built-in severity scoring reduce the time from installation to first findings significantly. Best for: Teams new to AI red teaming; rapid OWASP Top 10 baseline assessments; developers wanting LLM security testing without deep security engineering background.

Mindgard (Commercial): Mindgard was named in the 2026 Gartner Emerging Tech report for AI trust, risk, and security management. It runs continuous automated adversarial campaigns against LLMs, NLP models, and multimodal systems on a schedule, with OWASP, NIST AI RMF, MITRE ATLAS, and EU AI Act reporting built into the dashboard. Best for: Enterprise security organizations that need continuous testing, compliance reporting, and managed services rather than building internal tooling. Key advantage over open-source: the management, reporting, and compliance output layer that turns technical findings into executive and auditor-readable reports.

6. 🏁 Conclusion: AI Testing Is Now a Continuous Practice, Not a Pre-Launch Gate

The OWASP AI Testing Guide v1’s most important message for security and governance teams in 2026 is embedded in its title: trustworthiness testing, not security testing. The systems organizations are deploying today do not fail in the ways that traditional security programs were built to detect. They hallucinate. They perpetuate bias at scale. They can be coaxed into producing harmful outputs through patient, multi-turn conversation. They degrade silently as their underlying models are updated and their RAG knowledge bases drift. They accumulate unauthorized agent actions that no single person approved or tracked. A security program that does not test for these failure modes is a security program that is missing the majority of the real risk.

The practical path forward in 2026 is not more tools — it is a more complete testing methodology applied consistently. Start with the five-step process in this guide. Run Promptfoo’s OWASP preset as your CI/CD baseline to catch regressions on every model update. Add Garak for nightly model-layer scans on production-facing models. Build PyRIT campaigns for the high-priority findings and the agentic attack surfaces that automated tools do not reach. Run the bias and fairness testing in Step 4 before any deployment where the system makes consequential decisions affecting individuals — both because it is the right thing to do and because the Colorado AI Act, the EU AI Act, and an expanding set of sector-specific regulations now require you to. Document every test, every finding, and every remediation. And build the re-test cadence into your release process as a gate, not an afterthought — because AI red teaming in 2026 is no longer a question of whether, but how often, against what, and with which evidence.

📌 Key Takeaways

🔗 Related Articles

• 📖 OWASP Top 10 Risks for LLMs and GenAI Apps (2026) Explained
• 📖 LLM Red Teaming for Beginners: How to Test AI Systems for Safety
• 📖 AI Monitoring and Observability: How to Track Quality and Safety After Deployment
• 📖 Prompt Injection Explained: How AI Assistants Get Tricked and How to Stay Safe
• 📖 AI Risk Assessment: How to Evaluate AI Use Cases Before You Deploy Them