Thirteen percent of organizations reported a breach of their AI models or applications in the past year, and 97% of those had no proper AI access controls in place, per IBM's 2025 Cost of a Data Breach Report. A scope of work is the document that decides whether your AI or LLM penetration test actually exercises the surface behind that number or quietly skips it. Most security teams already know how to scope a web app pentest. Almost none have a reusable artifact for an AI or LLM system, so the request that reaches a vendor is a paragraph of intent instead of a testable scope.
This post fixes that. Below is a copy-paste, fill-in-the-blank AI and LLM penetration test scope of work (SOW) template you can drop into a procurement wiki, adapt, and send to vendors, plus a buyer checklist for the decisions you need to make before you hit send.
What should an AI or LLM penetration testing scope of work include?
An AI or LLM penetration test scope of work should include eight things: the systems and model-access tier in scope, the AI-specific components (RAG pipelines, agents, tools, and plugins) that are in or out, the threat model and standards it maps to, the rules of engagement, a safety and guardrail rollback plan, data-handling clauses, deliverables, and acceptance criteria. Anchor the threat model to the OWASP Top 10 for LLM Applications 2025 and, if your system uses autonomous agents, the OWASP Top 10 for Agentic Applications 2026. The template below turns each of those into a section you fill in.
The reason the scope carries so much weight: AI-specific risk is not a variant of web risk. Shadow AI alone added an average of US$670,000 to breach costs in IBM's 2025 data, and 60% of AI-related security incidents led to compromised data. A scope that names the model interface, the retrieval layer, and the agent's tools is what turns a demo into a test.
The nine components every AI/LLM pentest SOW must define
Before you write anything, decide these nine things. Each becomes a numbered section in the template.
Engagement overview: what the system is, what it does, and where it runs.
Model-access tier: black-box, grey-box, or white-box, and whether the tester gets API access, source, or model weights.
Components in scope: the app, system prompts, RAG pipeline, agent layer, tools and plugins, and the guardrail layer.
Explicitly out of scope: the foundation-model provider's infrastructure, third-party APIs, and anything you are not authorizing.
Threat model and standards: the OWASP lists and any framework mapping you require.
Rules of engagement: permitted techniques, rate limits, test accounts, and escalation contacts.
Safety and guardrail rollback plan: what may be relaxed for testing, who authorizes it, and how it gets restored.
Data-handling clauses: what data the tester may touch, how it is stored, and when it is destroyed.
Deliverables and acceptance criteria: the report format, the retest, and the bar for pass or fail.
The model-access decision: black-box, grey-box, white-box
The single most consequential line in an AI SOW is the access tier, because it determines how deep the test can reach. A black-box test that only sees a chat box will find prompt injection but never a poisoned document in your vector store. Spell out both the knowledge tier and the interface.
Access tier | What the tester gets | Best for |
|---|---|---|
Black-box | API or UI only, no internals | Simulating an external attacker against a public AI feature |
Grey-box | API plus system prompts, architecture, and docs | The efficient default for most AI app tests |
White-box | API plus source code, configs, and model weights or self-hosted access | RAG, agent, and access-control depth; highest coverage |
Also state the interface: a hosted API (name the model and version) behaves differently from a self-hosted, open-weights deployment you control. Both belong in the SOW so the vendor prices and plans the right test.
In scope vs out of scope: RAG, agents, tools, and guardrails
An LLM feature is rarely just a model. It is an application, a retrieval pipeline, sometimes an agent that calls tools, and a guardrail layer sitting in front. Name each one. If your system uses agents, the OWASP Top 10 for Agentic Applications 2026, released in December 2025 with more than 100 contributors, is the reference for tool misuse, excessive autonomy, and agent-to-agent risks.
Component | Typical status | Why |
|---|---|---|
LLM application UI and API | In scope | Where prompt injection and output-handling flaws surface |
System prompts and instructions | In scope | Target for leakage and override |
RAG pipeline and vector store | In scope | Poisoning and data-exfiltration path |
Agent, orchestration, and tools | In scope | Excessive-agency and tool-abuse surface |
Auth and access control around AI features | In scope | Broken authorization is a top real-world finding |
Foundation-model provider infrastructure | Out of scope | You do not own or authorize the provider's hosting |
The copy-paste AI/LLM pentest scope of work template
Copy the block below, fill in every bracketed field, delete the tiers and components that do not apply, and send it to your shortlisted vendors. It is written to be embedded in a procurement wiki and reused across engagements.
1. Engagement overview
Client: [LEGAL ENTITY NAME]
System under test: [AI/LLM SYSTEM OR FEATURE NAME AND VERSION]
Business purpose: [WHAT THE FEATURE DOES AND WHO USES IT]
Environment: [PRODUCTION / STAGING / DEDICATED TEST TENANT]
Test window: [START DATE] to [END DATE]
2. Systems and components in scope
Model-access tier (choose one): [ ] Black-box (API or UI only) | [ ] Grey-box (API plus prompts, docs, architecture) | [ ] White-box (API plus source, configs, and weights or self-hosted access)
Model interface: [ ] Hosted API: [MODEL AND VERSION] | [ ] Self-hosted or open weights: [MODEL]
Components in scope (check all that apply): [ ] LLM application UI and API | [ ] System prompts | [ ] RAG pipeline and vector store | [ ] Agent and orchestration layer | [ ] Tools, functions, and plugins the model can call | [ ] Guardrail and moderation layer | [ ] Auth and access control around AI features
In-scope endpoints or URLs: [LIST]
Data classes reachable by the system: [PII / SECRETS / INTERNAL DOCUMENTS / SYNTHETIC ONLY / NONE]
3. Explicitly out of scope
Foundation-model provider infrastructure and the provider's own hosting
Denial-of-wallet or load testing beyond [AGREED REQUEST RATE]
[OTHER SYSTEMS, THIRD-PARTY APIS, OR INTEGRATIONS NOT AUTHORIZED]
4. Threat model and standards
Map every finding to: OWASP Top 10 for LLM Applications 2025; OWASP Top 10 for Agentic Applications 2026 (if agents are in scope); [NIST AI RMF / MITRE ATLAS, IF REQUIRED]
Priority risks for this engagement: [e.g., LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM06 Excessive Agency, LLM08 Vector and Embedding Weaknesses]
5. Testing methodology and rules of engagement
Techniques permitted: [prompt injection, jailbreaks, system-prompt leakage, improper-output-handling abuse, RAG poisoning, tool and function abuse, authorization testing]
Rate limits and throttling: [REQUESTS PER MINUTE / TOKEN BUDGET]
Test accounts and tenants: [PROVIDED BY CLIENT, WITH ROLES]
Prohibited actions: [no destructive operations, no exfiltration of real customer data, no testing outside the window]
Point of contact and escalation: [NAME, ROLE, CHANNEL, RESPONSE TIME]
6. Safety and guardrail rollback plan
Guardrails that may be relaxed for testing: [WHICH FILTERS OR LIMITS, AND ON WHICH TENANT]
Who authorizes relaxation: [NAME AND ROLE]
Rollback trigger and owner: [CONDITION] triggers [OWNER] to restore the original configuration within [X HOURS]
Monitoring during the test: [LOGGING AND ALERTING IN PLACE, WHO WATCHES IT]
7. Data-handling clauses
Data classification the tester may access: [CLASS]
Handling and storage: [ENCRYPTED AT REST AND IN TRANSIT, RETAINED [X] DAYS, DELETED ON REPORT ACCEPTANCE]
Prompt and response logging: [WHO RETAINS IT, FOR HOW LONG, WHERE]
Confidentiality of prompts, training data, and model artifacts: [NDA REFERENCE]
Sub-processors and model providers disclosed: [LIST]
8. Deliverables
Findings report with each issue mapped to its OWASP LLM or Agentic ID, severity, reproduction steps, proof of concept, and remediation guidance
Executive summary written for [AUDIENCE: BOARD / ENGINEERING / AUDITORS]
Free retest of remediated findings within [X DAYS] of the report
[Optional] evidence pack to support your [SOC 2 / ISO 27001 / INTERNAL AUDIT] program
9. Acceptance criteria
Coverage: every in-scope component was exercised and the evidence is documented
Pass or fail threshold: [e.g., no unresolved Critical or High findings at retest]
Reproducibility: each finding is independently reproducible from the report alone
Sign-off: [CLIENT ROLE] accepts the engagement as complete on [DATE]
10. Commercials and sign-off
Fee and pricing model: [FIXED FEE / DAY RATE], per the vendor's published pricing
Timeline and milestones: [KICKOFF, TESTING, DRAFT REPORT, RETEST]
Authorized signatories: [CLIENT SIGNATORY], [VENDOR SIGNATORY]
Anchor the threat model to the OWASP lists
So the SOW is self-contained, here is the OWASP Top 10 for LLM Applications 2025 that section 4 references: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Supply Chain, LLM04 Data and Model Poisoning, LLM05 Improper Output Handling, LLM06 Excessive Agency, LLM07 System Prompt Leakage, LLM08 Vector and Embedding Weaknesses, LLM09 Misinformation, and LLM10 Unbounded Consumption. Requiring a vendor to map findings to these IDs is the fastest way to compare two reports side by side.
The buyer checklist before you send the SOW
Run this checklist before the SOW leaves your inbox.
Access decided: you have picked a tier and can provision it (accounts, source, or weights) on day one.
Components enumerated: every RAG store, agent, tool, and plugin is named as in or out.
Standards named: the SOW cites the OWASP LLM 2025 list and, for agents, the Agentic 2026 list.
Safety owner assigned: one named person can authorize a guardrail change and owns the rollback.
Data path clear: you know what data the tester can reach and how it will be destroyed. Our AI pentest data-handling due diligence guide covers the clauses in depth.
Acceptance measurable: pass or fail is a threshold, not a vibe, and a free retest is included.
For the questions to put to each vendor once the SOW is out, see questions to ask an AI pentest vendor and the AI pentesting evaluation guide. For scoping fundamentals that carry over from traditional testing, our how to scope a penetration test guide is the companion piece.
How Stingrai approaches an AI/LLM pentest
At Stingrai, an AI or LLM engagement is a hybrid. Our autonomous web application agent, Snipe, covers the application and API layer of the AI feature, hunting the complex classes that generic AI scanners miss: IDOR, business logic flaws, and broken authorization around the AI functionality itself. Senior pentesters own the model, RAG, and agent adversarial testing, along with cloud, IAM, and identity scope that sits behind the feature. That split maps cleanly onto the template: Snipe drives the application-layer sections, humans drive the model and agent sections.
Every finding is mapped to its OWASP LLM or Agentic ID with reproduction steps and remediation, and the evidence supports your SOC 2, ISO 27001, or PCI DSS compliance program. Stingrai is a CREST-accredited penetration testing provider, founded in 2021, with offices in Toronto and London. You can see how the application-layer work is delivered on our web application penetration testing and PTaaS pages, and where adversarial and agent testing fits on our red teaming page. Engagement pricing is on the pricing page.
Frequently asked questions
What should an AI or LLM penetration testing scope of work include?
An AI or LLM penetration test scope of work should include eight things: the systems and model-access tier in scope, the AI-specific components (RAG, agents, tools, and plugins) that are in or out, the threat model and standards it maps to, the rules of engagement, a safety and guardrail rollback plan, data-handling clauses, deliverables, and acceptance criteria. Anchor the threat model to the OWASP Top 10 for LLM Applications 2025 and, for agents, the OWASP Top 10 for Agentic Applications 2026. The template in this post turns each of those into a fill-in-the-blank section.
What is the difference between black-box, grey-box, and white-box AI pentesting?
Black-box means the tester sees only the API or UI, which simulates an external attacker but cannot reach a poisoned vector store or a misconfigured agent. Grey-box adds system prompts, architecture, and documentation and is the efficient default for most AI app tests. White-box adds source code, configuration, and model weights or self-hosted access, which gives the deepest coverage of RAG, agent, and access-control flaws. State both the knowledge tier and the interface (hosted API versus open weights) in the SOW.
Should the SOW cover RAG pipelines and AI agents?
Yes, if your system uses them. An LLM feature is rarely just a model. It usually includes a retrieval pipeline and sometimes an agent that calls tools, and each adds risk. RAG stores are a poisoning and exfiltration path, and agents introduce excessive-agency and tool-abuse risk covered by the OWASP Top 10 for Agentic Applications 2026. Name every RAG store, agent, tool, and plugin as explicitly in scope or out of scope.
What standards should an AI pentest SOW map to?
Map findings to the OWASP Top 10 for LLM Applications 2025, which covers risks from LLM01 Prompt Injection to LLM10 Unbounded Consumption. If agents are in scope, also map to the OWASP Top 10 for Agentic Applications 2026, released by the OWASP GenAI Security Project in December 2025. Add NIST AI RMF or MITRE ATLAS if your program requires them. Requiring a vendor to map to these IDs makes two reports directly comparable.
What is a guardrail rollback plan and why include it?
A guardrail rollback plan documents which safety controls (content filters, rate limits, moderation) may be relaxed for testing, who authorizes the change, and how and when the original configuration is restored. It matters because adversarial testing sometimes needs a guardrail loosened on a test tenant to reach a deeper flaw, and you need a named owner and a defined trigger to put it back. Including it in the SOW prevents a test from leaving a control disabled.
What data-handling clauses belong in an AI/LLM pentest SOW?
Specify the data classification the tester may access, how prompts and responses are stored and encrypted, how long anything is retained, and when it is destroyed (typically on report acceptance). Add confidentiality terms for prompts, training data, and model artifacts, and require disclosure of sub-processors and model providers. This matters because shadow AI and weak data controls drove the largest AI breach costs in IBM's 2025 report.
How is an AI red team statement of work different from a pentest SOW?
An AI red team statement of work is usually broader and goal-driven, testing whether an adversary can achieve an objective (exfiltrate data, hijack an agent, bypass safety) across the whole system, often over a longer window and with fewer constraints. An AI or LLM pentest SOW is scoped to enumerate and prove specific vulnerabilities in named components against a standard like the OWASP lists. The template here works for both: tighten the rules of engagement and acceptance criteria for a pentest, or loosen them and set an objective for a red team.
How long does an AI or LLM penetration test take?
It depends on the access tier and how many components are in scope. A black-box test of a single chat feature is faster than a white-box test of a RAG-backed agent with several tools. The template's scope and access sections are what let a vendor size the engagement accurately, which is why filling them in before you request a quote produces a firmer timeline and price. See the Stingrai pricing page for engagement models.
References
IBM. Cost of a Data Breach Report 2025. July 2025. https://www.ibm.com/reports/data-breach. Ponemon-conducted, IBM-published study of breach costs, including AI-specific findings on AI model and application breaches, shadow AI cost impact, and AI access-control gaps.
IBM. IBM Report: 13% of Organizations Reported Breaches of AI Models or Applications, 97% of Which Reported Lacking Proper AI Access Controls. July 30, 2025. https://newsroom.ibm.com/2025-07-30-ibm-report-13-of-organizations-reported-breaches-of-ai-models-or-applications,-97-of-which-reported-lacking-proper-ai-access-controls. Press release with the headline AI-breach statistics cited above.
OWASP GenAI Security Project. OWASP Top 10 for LLM Applications 2025. 2025. https://genai.owasp.org/llm-top-10/. The canonical risk list for LLM applications, covering LLM01 Prompt Injection through LLM10 Unbounded Consumption.
OWASP GenAI Security Project. OWASP Top 10 for Agentic Applications for 2026. December 9, 2025. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/. Peer-reviewed framework for the most critical security risks in autonomous and agentic AI systems.
