OWASP AI Testing Guide: 32 Tests Explained

Most AI systems reach production after a functional test and a short jailbreak session, which says little about whether the model, its data, its tools and its hosting can withstand a determined tester. The OWASP AI Testing Guide (AITG) is OWASP's attempt to give AI testing the same structure the Web Security Testing Guide gave web applications: numbered test cases, each with objectives, expected output, remediation and suggested tools. Version 1 was published on 26 November 2025 and the project is listed by OWASP as an Incubator project (checked November 2026). This guide explains how the AITG is organised, what each of its 32 test cases covers, how to scope and run an assessment against it, what evidence to keep, and how it maps to the OWASP Top 10 for LLM Applications, MITRE ATLAS and NIST frameworks. It is written for penetration testers, AI security engineers and the people who commission and accept their reports. For the wider practice of adversarial testing, see the AI Red Teaming Guide; this page stays with the AITG itself.

Key takeaways

Four pillars, 32 test cases: the AITG groups tests into AI Application (AITG-APP-01 to 14), AI Model (AITG-MOD-01 to 07), AI Infrastructure (AITG-INF-01 to 06) and AI Data (AITG-DAT-01 to 05).
Threat model first: the guide starts from threat modelling (PASTA, STRIDE, MITRE ATLAS, LINDDUN, MAESTRO) mapped to Google's Secure AI Framework components, then selects tests from that model.
Security, privacy and responsible AI together: each test is tagged with domains (Security, Privacy, RAI), so one assessment can cover jailbreaks, membership inference and bias rather than three separate exercises.
Black box is expensive and incomplete: non-deterministic output, LLM-based guardrails, multi-agent chains and per-token costs push the guide towards grey-box testing with logs, prompts and console access.
Agents and tools are an identity problem: AITG-APP-06 and AITG-INF-03 test whether an agent can be talked into calling tools outside its workflow, which only holds up if each tool enforces authorisation itself.

What it is and who it applies to

The AITG is a community methodology, not a certification scheme or a regulation. Nobody is required to comply with it, but it gives a common vocabulary for scoping, executing and reporting AI security tests. Its stated aim, in the project README, is to consolidate existing work into a structured methodology for testing AI systems, building on the OWASP Top 10 for LLM Applications, the OWASP AI Exchange, the GenAI Red Teaming Guide and NIST AI 100-2 E2025 on adversarial machine learning.

OWASP output	What it is	How it relates to the AITG
OWASP Top 10 for LLM Applications 2025	Risk list (LLM01 to LLM10)	Most application and infrastructure tests name an LLM Top 10 risk as their threat source
OWASP AI Exchange	Threat and control knowledge base	Threat source for model extraction, evasion, membership inference, inversion and dev-time model theft tests
OWASP GenAI Red Teaming Guide and Manual	Process for planning and running red team engagements	Process layer; the AITG supplies the test case catalogue. See the OWASP GenAI Red Teaming Manual Guide
OWASP Web Security Testing Guide	Web application test methodology	The AITG explicitly leaves classic application flaws in tools (such as SQL injection) to the WSTG
OWASP AIVSS	AI vulnerability scoring	Candidate scoring scheme for AITG findings

Who uses it: internal AI security and AppSec teams building a test plan, external testers who need a defensible scope, and product owners who want acceptance criteria before an AI feature goes live.
What it covers: LLM applications, RAG pipelines, agents and plugins, classic machine learning models, the infrastructure that trains and serves them, and the data used across the lifecycle.
What it does not cover: organisational AI governance, legal conformity, and traditional web or API vulnerabilities in surrounding services, which belong to the Web Application Security Testing Guide and the API Penetration Testing Guide.

Structure and key requirements

The guide has four chapters: introduction and principles; threat modelling for AI systems; the testing framework with the test cases; and appendices (the rationale for SAIF, Distributed Immutable Ephemeral threat identification, a risk lifecycle, threat enumeration to architecture components, and a mapping of AI threats to CVEs and CWEs). Every test follows the same template: Summary, Test Objectives, How to Test, Expected Output, Real Example, Remediation, Suggested Tools and References.

The 32 test cases

Pillar	Test IDs and names	Main threat sources
AI Application	APP-01 Prompt Injection; APP-02 Indirect Prompt Injection; APP-03 Sensitive Data Leak; APP-04 Input Leakage; APP-05 Unsafe Outputs; APP-06 Agentic Behaviour Limits; APP-07 Prompt Disclosure; APP-08 Embedding Manipulation; APP-09 Model Extraction; APP-10 Content Bias; APP-11 Hallucinations; APP-12 Toxic Output; APP-13 Over-Reliance on AI; APP-14 Explainability and Interpretability	OWASP LLM Top 10 2025, OWASP AI Exchange, Responsible AI
AI Model	MOD-01 Evasion Attacks; MOD-02 Runtime Model Poisoning; MOD-03 Poisoned Training Sets; MOD-04 Membership Inference; MOD-05 Inversion Attacks; MOD-06 Robustness to New Data; MOD-07 Goal Alignment	OWASP AI Exchange, OWASP LLM Top 10 2025, Responsible AI
AI Infrastructure	INF-01 Supply Chain Tampering; INF-02 Resource Exhaustion; INF-03 Plugin Boundary Violations; INF-04 Capability Misuse; INF-05 Fine-tuning Poisoning; INF-06 Dev-Time Model Theft	OWASP LLM Top 10 2025, OWASP AI Exchange, Responsible AI
AI Data	DAT-01 Training Data Exposure; DAT-02 Runtime Exfiltration; DAT-03 Dataset Diversity and Coverage; DAT-04 Harmful Content in Data; DAT-05 Data Minimisation and Consent	OWASP AI Exchange, Responsible AI

Three testing domains

Security (SecAI): prompt and input control, adversarial robustness, infrastructure security for APIs, plugins, RAG and agent workflows, supply chain risk, and continuous testing in CI/CD.
Privacy (PrivacyAI): leakage of training data, private context or user inputs; membership and property inference; model extraction; and minimisation, purpose limitation and consent.
Responsible AI (RespAI): bias and fairness, toxicity, safety alignment, guardrail coverage and human-in-the-loop controls for high-impact decisions.

Testing limitations the guide calls out

No source code to read: model behaviour lives in weights, so absence of a flaw cannot be shown by review.
Temperature above zero: the same input can pass once and fail the next time, so attack vectors need repetition.
Guardrails built on LLMs: the defence is itself probabilistic.
Multi-agent chains: the output of one agent becomes the input of the next, multiplying the paths to verify.
Token cost: large automated campaigns against hosted models cost money and may trip spending thresholds, which the guide notes should be checked before testing.

Identity and NHI requirements

The AITG is not an identity standard, but several of its tests only make sense once you know which identity an AI component acts as. Treat the following as the identity checks that sit inside an AITG engagement.

AITG test	Identity question to answer	Evidence that it holds
APP-06 Agentic Behaviour Limits	Can a prompt make the agent invoke a tool or skip a workflow step it should not?	Tool calls rejected by the tool itself, not only by the agent's instructions
INF-03 Plugin Boundary Violations	Do plugins and MCP servers run with least privilege and isolation?	Separate credentials per plugin, scoped tokens, sandboxing
INF-04 Capability Misuse	Can the system be pushed into actions beyond its intended capability?	Allow-listed actions, approval steps for high-impact operations
APP-03 and APP-07	Do responses or system prompts reveal API keys, connection strings or internal endpoints?	No secrets in prompts; canary tokens never returned
DAT-02 Runtime Exfiltration	Do outputs, logs or caches expose another user's data?	Per-user data scoping at retrieval and tool layers
INF-06 Dev-Time Model Theft	Who and what can read model weights and training artefacts?	Scoped storage roles, workload identity for pipelines, access logs

Authorisation belongs in the tool: the AITG's own design note for APP-06 says a tool that retrieves user data should perform authentication and authorisation checks in a non-agentic way and return only the current user's data. If the test can talk the agent into fetching another user's record, the defect is in the tool's authorisation, not the prompt. See the Agent Identity and Access Guide.
Agent credentials are NHIs: record every API key, OAuth client, service principal and workload identity the system under test uses, and test with the same scopes as production. Excessive scopes are a finding in their own right; see the OWASP LLM Top 10 LLM06 Excessive Agency Guide.
Test accounts and keys: the testers' own credentials are high-value NHIs. Issue them short-lived, separate them from production keys, set spending caps, and revoke them at close.

Implementation steps

Agree scope and rules of engagement. Name the application, models, agents, tools, RAG indexes, pipelines and environments in scope; state whether testing is black, grey or white box; set token and cost ceilings; and get written authorisation, including from any third-party model provider whose terms apply. The Red Team Rules of Engagement Template is a starting point.
Collect grey-box material. The guide recommends access to application and agent logs, system prompts and source code, and read access to third-party AI service consoles (model in use, cost thresholds, logs, guardrail settings). Each reduces test volume and cost.
Threat model the architecture. Decompose the system into SAIF-style components (data sources, training pipeline, model store, inference endpoint, orchestration, tools), mark trust boundaries and pick a method: PASTA for business-aligned risk, STRIDE for components, MITRE ATLAS for adversarial ML, LINDDUN for privacy, MAESTRO for multi-agent systems.
Select tests from the model. A customer support chatbot with RAG will weight APP-01 to APP-08 and DAT-02; a fraud model trained in-house will weight MOD-01 to MOD-05 and DAT-01; an agent with tools adds APP-06, INF-03 and INF-04. Record why each excluded test was excluded.
Execute with repetition. Run each probe several times with the production temperature and record pass rates, not single outcomes. Combine manual testing with automated probes; the AITG's suggested tools include open-source scanners and robustness toolkits listed in each test.
Judge against the Expected Output. Each test defines what confirms a vulnerability (for example, a system prompt overridden, an API key exposed, or an unauthorised action performed). Use those criteria rather than subjective judgement.
Report and score. Map each finding to its AITG ID, its LLM Top 10 or AI Exchange threat, and a severity. Give the remediation from the test case plus the system-specific fix.
Retest and automate. Turn confirmed findings into regression probes in CI/CD so that model upgrades, prompt changes and new tools are retested. Restore or revoke test credentials and data once complete.

Rollback and safety: run destructive tests (resource exhaustion, poisoning, fine-tuning) in a non-production copy, keep a known-good model version and index snapshot, and agree a stop condition with the system owner before INF-02 load tests start. The Denial-of-Wallet and AI Agent Cost Runaway Guide covers spending controls worth confirming first.

Choosing the depth

Situation	Recommended approach	Trade-off
Small team, one LLM feature using a hosted model	APP pillar plus DAT-02 and INF-02, grey box	Model pillar mostly sits with the provider; rely on its documentation
Agentic product with tools and MCP servers	APP-01, 02, 06, INF-03, INF-04, DAT-02 at minimum, white box on tools	Tool code review takes time but finds the authorisation flaws
Organisation training or fine-tuning its own models	Full MOD and DAT pillars plus INF-01, 05, 06	Needs ML expertise and compute for membership inference and evasion tests
Regulated or high-impact decision system	All four pillars including RAI tests APP-10 to 14 and MOD-06, 07	Longest engagement; produces evidence useful for AI governance

Evidence and assessment

Test plan: scope, threat model, selected and excluded AITG IDs with reasons, environment details, model versions and temperature settings.
Execution records: each prompt or input, the full response, timestamp, model version, number of attempts and success rate. Store them securely, since they may contain extracted data or harmful text.
Findings: AITG ID, threat source, expected output met, severity, affected component, remediation and retest result.
Tool and identity inventory: the tools, plugins and credentials the AI system used during testing, with their scopes.

Metrics that show the programme is working

Coverage: percentage of applicable AITG test cases executed per AI system, per release.
Attack success rate: share of attempts that met the Expected Output for APP-01, APP-02 and APP-07, tracked across model and prompt versions.
Time to remediate: median days from finding to verified fix, split by pillar.
Regression rate: findings that reappear after a model upgrade or prompt change.
Automated share: percentage of confirmed findings converted into CI/CD regression probes.

Mapping to other frameworks

AITG area	OWASP LLM Top 10 2025	MITRE ATLAS	NIST
APP-01, APP-02 prompt injection	LLM01 Prompt Injection	AML.T0051 LLM Prompt Injection	SP 800-53 CA-8 Penetration Testing
APP-03, APP-04 data leakage	LLM02 Sensitive Information Disclosure	AML.T0057 LLM Data Leakage	SP 800-53 SA-11 Developer Testing and Evaluation
APP-07 prompt disclosure	LLM07 System Prompt Leakage	AML.T0057 LLM Data Leakage	SP 800-53 SA-11
APP-06, INF-04 agent limits and capability misuse	LLM06 Excessive Agency	AML.T0051 as an entry point	SP 800-53 CA-8.2 Red Team Exercises
APP-08 embedding manipulation	LLM08 Vector and Embedding Weaknesses	Not mapped here	SP 800-53 SA-11
APP-09 model extraction	Not an LLM Top 10 item	AML.T0024 Exfiltration via AI Inference API	CSF 2.0 ID.RA-01
MOD-02, MOD-03, INF-05 poisoning	LLM04 Data and Model Poisoning	Not mapped here	SP 800-53 RA-3 Risk Assessment
INF-01 supply chain tampering	LLM03 Supply Chain	Not mapped here	SP 800-53 SA-11
INF-02 resource exhaustion	LLM10 Unbounded Consumption	Not mapped here	CSF 2.0 ID.IM-02
APP-11 hallucinations	LLM09 Misinformation	Not mapped here	NIST AI RMF Measure function

The AITG principles chapter points to NIST AI RMF, ISO/IEC 42001 and the OWASP Top 10 for LLMs for policy and regulatory alignment. AITG results are useful evidence for the Measure function of the NIST AI RMF Guide and for AI system verification in an ISO/IEC 42001 Guide management system. CSF 2.0 ID.IM-02 covers improvements identified from security tests and exercises.

Common pitfalls

Single-shot verdicts: a jailbreak that fails once is reported as fixed. With temperature above zero, record success rates over repeated attempts.
Testing only the chat box: indirect prompt injection (APP-02) through documents, emails, web pages and tool results is skipped, although that is where agents meet untrusted content. See the Prompt Injection Guide.
Treating prompt rules as access control: findings under APP-06 are "fixed" by adding instructions to the system prompt instead of enforcing authorisation in the tool.
Ignoring the RAI and data pillars: security teams run APP-01 to APP-07 and stop, leaving hallucination, over-reliance and data minimisation untested, although they often drive the business risk.
Uncapped automated testing: large probe sets against a hosted model run up cost or hit provider rate limits mid-engagement because spending thresholds were not checked first.
One-off assessments: a model upgrade or a new tool invalidates last quarter's results; without regression probes, nobody notices.

Practitioner checklist

Read the AITG Testing Limitations and Requirements section before scoping, and request logs, prompts and console access.
Threat model the system against SAIF components and choose PASTA, STRIDE, ATLAS, LINDDUN or MAESTRO to fit.
Select AITG test IDs from the threat model and record reasons for every exclusion.
Inventory every credential, tool and plugin the AI system uses, and test with production scopes.
Verify that tools enforce authorisation independently of the agent's instructions.
Set token budgets, rate limits and a stop condition before automated or load testing.
Repeat probes at production temperature and report success rates.
Map findings to AITG IDs and LLM Top 10 or AI Exchange threats in the report.
Convert confirmed findings into CI/CD regression probes and rerun them on every model or prompt change.
Revoke tester credentials and remove test data at engagement close.

OWASP AI Testing Guide: Applying Its 32 Tests Across Four Pillars