Prompt injection testing vs jailbreak testing: which one a business app needs first
For most business apps, prompt injection testing comes first, because the risk that matters is whether crafted or embedded input can change what the application does, which data it can reach and which actions it can take. Jailbreak testing matters most when the model itself is the product, or when the model's safety rules are the main control between users and harmful output. If your LLM feature sits inside a workflow that reads email, tickets, documents or web pages, and can call internal tools, start with injection testing and treat jailbreak testing as a second step.
The OWASP LLM01 entry treats the two as closely related: it notes that prompt injection and jailbreaking are often used interchangeably, and that jailbreaking is a form of prompt injection in which the attacker aims to make the model ignore its safety protocols altogether. The practical difference is the target. A direct injection test checks whether a user's own input alters behavior, and an indirect injection test checks whether instructions hidden in external content, such as a web page or file the model reads, do the same. Before scoping either, list every data source the model reads, every tool or API it can call, and the identity each call runs under. Those are the components an injection test should try to influence, and they usually decide the severity of a finding.
Combine the two when the model is customer-facing and tool-enabled, because a jailbreak that bypasses content rules can be more useful to an attacker when it is paired with an injection into a privileged workflow. Ask the tester to state what each engagement does not prove: a clean run shows that the cases tried did not succeed, not that the application is safe. Confirm with the testing team which ATLAS technique IDs and OWASP categories their test plan maps to, including LLM Prompt Injection: Indirect (AML.T0051.001) and LLM Jailbreak (AML.T0054) from the MITRE ATLAS v2026.09 data release, so results can be compared across rounds.
How the two tests compare on goals, scope and evidence
This table compares the two tests factor by factor, from the question each answers to the evidence each produces. Read it to decide which test a business application needs first, and to see where the two overlap. The main takeaway is that prompt injection testing measures what your application does with input, while jailbreak testing measures whether the model itself keeps its safety behavior.
| Factor | Prompt injection testing | Jailbreak testing |
|---|---|---|
| Primary goal | Show that crafted or embedded input can change the application's actions, tool calls or outputs | Show that the model can be pushed to ignore its safety protocols |
| Question it answers | Can untrusted content steer this application away from its intended behavior? | Can this model be made to produce content or behavior its safety rules forbid? |
| Attacker input | Direct: the user's own prompt. Indirect: web pages, files, emails or retrieved documents the model reads | Usually the user's prompt, crafted to override or evade safety behavior |
| Application boundary | Includes the prompt template, retrieval, tools, plugins, output handling and data access | Centers on the model and its safety behavior, with the surrounding app as context |
| Typical test targets | Connected tools and actions, retrieval sources, output rendering, and what data the model can reach | Refusal behavior, policy adherence and harmful output categories |
| ATLAS technique reference | AML.T0051.001 (LLM Prompt Injection: Indirect), with direct injection mapped in the same ATLAS technique family | AML.T0054 (LLM Jailbreak) |
| OWASP LLM01 relationship | Core subject of LLM01 Prompt Injection, including indirect injection from external sources | Described in LLM01 as a form of prompt injection aimed at ignoring safety protocols |
| Who usually performs it | Application security testers with access to the app's design, tools and data flows | AI red teamers with model behavior and harm-category expertise |
| Evidence produced | Reproduced attack paths showing the input, the affected action or data, and the control that failed or held | Prompts and outputs showing which safety behavior was bypassed, with harm category and severity notes |
Where OWASP LLM01 draws the line between injection and jailbreak
OWASP LLM01 treats prompt injection and jailbreaking as closely related and often used interchangeably, but the distinction matters for test planning. Jailbreaking is a form of prompt injection, and it is the specific case where the attacker's goal is to make the model ignore its safety protocols altogether. Prompt injection, in the wider sense, is any input that changes what the model or application does. A jailbreak test asks whether the model's own guardrails hold under pressure. An injection test asks whether the application's behavior can be steered by content it was never meant to obey, such as a support ticket, a retrieved document or a field in a database row.
The two forms of injection differ in where the attacker sits. *Direct prompt injection* is the case where a user's prompt input directly alters the model's behavior, so the tester plays the user and tries to override the system instructions, change the role the assistant plays or extract data it should not reveal. *Indirect prompt injection* is the case where the model accepts input from external sources such as web pages, emails or files that contain instructions. Here the attacker never talks to the model. They plant instructions in content the application will later read, which means the tester must map every data source the application ingests and treat each one as an untrusted channel.
This split changes what a tester attacks and what a fix looks like. A direct-injection test focuses on the prompt boundary and on what tools or data the model can reach once its instructions are changed. An indirect-injection test focuses on retrieval, parsing and the trust placed in external content. Fixes also differ: a jailbreak is usually addressed by model choice, safety tuning and output filtering, while an injection often needs least-privilege tool access, separation of untrusted content from instructions and confirmation steps before consequential actions. Confirm with your vendor or model provider which guardrails they document, and test the application's own permissions, since those are what your organization controls.
What each test finds and misses
Prompt injection testing and jailbreak testing answer different questions about the same model, so each one leaves a different gap. Read the cards by asking which outcome would hurt your business: an attacker steering your application's actions, or a model producing content its safety rules should have blocked.
Prompt injection finds instruction override
Prompt injection testing checks whether text typed by a user changes what your application does, for example by overriding the system prompt or the task it was built to perform. Under OWASP LLM01, a direct injection comes from the user's own prompt. Check whether the application keeps its intended role when a tester supplies conflicting instructions, and whether the change persists across turns.
Prompt injection finds indirect injection
Indirect injection is the case most business apps underestimate. The model reads content from retrieved documents, emails, web pages or uploaded files and treats embedded instructions as its own. Plant instructions in each external source your application ingests, then confirm whether the model follows them. Include the sources a user never types into, because those are where attackers place content.
Prompt injection finds triggered actions
The risk rises when the application can call tools, send messages, change records or start workflows. A successful injection may cause an action the user never requested. Test each tool the model can invoke, record what arguments it passes, and check whether the tool enforces the same authorization as a direct user request, since the model should not be the control that decides.
Prompt injection finds data exposure
Injected instructions can ask the model to reveal data it can reach through retrieval, connectors or tool results, such as other customers' records or internal system prompts. Test what data each session can access, then attempt to pull that data through crafted prompts. Confirm that access controls sit outside the model, so a successful injection cannot widen what the application is allowed to return.
Jailbreak testing finds safety bypasses
Jailbreak testing targets the model's safety protocols, the layer OWASP LLM01 describes as the attacker aiming to make the model ignore its safety rules altogether. It measures whether crafted prompts such as role play or obfuscation get the model to produce content it should refuse. Use it when your business depends on the model's own refusal behavior, such as content moderation or customer-facing output.
Jailbreak testing misses system exposure
A jailbreak report can show a refused request still reaching the wrong system. Jailbreak testing does not show whether injected content can act on your systems, misuse a tool, or exploit a business logic flaw such as a discount rule or approval step. Pair it with prompt injection testing and conventional application testing so the question is answered at the level of your architecture, not only the model.
How each test is run for a business app versus a model
A business application that calls a model with tools and data is tested mainly for whether crafted or embedded content can change what the application does. The threat model starts from the application's tools, data stores and downstream actions, then asks which of them an attacker could reach through a user prompt or through content the model reads, such as a web page, email or uploaded file. Attack inputs are usually realistic documents, messages and retrieved records that carry hidden instructions, so the harness must feed content through the same retrieval and parsing paths production uses.
- Threat model: Map each tool, connector and data source the model can call, and the permissions each one carries.
- Test environment: Use a staging copy with test data and sandboxed connectors, never live customer systems.
- Authenticated access: Test as the roles real users hold, and confirm whether the model acts with the user's identity or a shared service identity.
- Tool and data scope: Record which actions a successful injection could trigger, such as sending messages or writing records, and verify those actions are blocked or logged.
- Judging: Reviewers check the resulting state change (a tool call, a data leak, an altered record), not only the model's text.
Ask the tester to show the trace from input to tool call, and to confirm that the test covered indirect injection through every content channel the application reads.
A model or model-centric product is tested when safety behavior is the subject: whether the model can be pushed to ignore its safety protocols and produce content or actions its operator and developer intended to prevent. OWASP describes jailbreaking as the case where the attacker aims to make the model ignore its safety protocols altogether, and it is often treated as a form of prompt injection. The threat model centers on harmful output categories, misuse scenarios and the abuse that could facilitate attacks on other systems, which NIST AI 600-1 action MS-2.7-007 addresses directly.
- Threat model: Define the harm categories and misuse scenarios for the model's intended users and deployment context.
- Attack inputs: Use a mix of curated jailbreak prompts, multi-turn strategies and expert-written variants, plus automated generation for breadth.
- Test environment: Run against the model endpoint or product build that will ship, with the same system prompt, safety layers and filters.
- Authenticated access: Test the access tiers that matter, such as anonymous, standard and privileged users, and any fine-tuned variants.
- Judging: Human reviewers grade outputs for harm and severity, supported by classifiers, and the harness records every prompt and response for reproduction.
Ask the team to show its harm taxonomy, reviewer criteria and how it measured the rate of unsafe responses across repeated runs.
Across both situations, the quality of the result depends on the test harness and on who reviews the output. NIST AI 600-1 frames AI red-teaming as a structured exercise that covers prompt injection and related attacks, and it does not reduce that work to a single scanner run. A harness controls which inputs are sent, how often, under which configuration and with what logging, so that a finding can be reproduced and a fix can be retested. Human review decides whether an output is harmful, whether a tool action was unsafe and whether the finding matters in context.
- Harness design: Version prompts, seeds, model settings and tool mocks so each run can be repeated exactly.
- Coverage: Record which content channels, roles and tools each test case touched, so gaps are visible.
- Reviewer skill: Confirm reviewers know the application domain and the harm categories, not only prompt techniques.
- Retest: Require that every confirmed finding is retested after the fix and that the harness keeps the failing case.
- Evidence: Ask for logs and traces that show the test was run, not only a summary of conclusions.
Confirm with any provider exactly which model versions, safety settings and logging the test will cover before work starts.
What you receive from each engagement
Both prompt injection testing and jailbreak testing produce evidence a security or product owner can act on, but the evidence differs. The cards below describe the components a buyer should expect to see in scope, in test cases, in reproducible inputs, in risk notes, in fixes and in retest planning.
Scope and rules of engagement
Every engagement starts with a written scope that names the application, the model endpoints, the tools the model can call, the data sources it reads, and the accounts used for testing. Rules of engagement cover what may be sent, what may be changed, and who is told when. For prompt injection work, ask whether indirect inputs such as documents, web pages and email are in scope, because those paths are often the ones that reach internal tools. For jailbreak work, ask how safety-policy bypasses will be recorded and whether that output will be stored.
Test cases mapped to LLM01 and ATLAS
Each test case should state which OWASP LLM01 pattern it exercises, such as direct user input or indirect content from an external source, and which MITRE ATLAS technique it corresponds to, such as the indirect prompt injection technique AML.T0051.001 or the jailbreak technique AML.T0054. Mapping lets a team track coverage across releases and explain to auditors or customers what was tested. Ask the provider to show the mapping for each case, not a generic list of categories.
Reproducible attack inputs
A useful deliverable includes the exact inputs, retrieval content, tool responses and conversation state that produced each result, along with the model version, system prompt version and configuration in use at the time. Reproducibility matters because model outputs vary between runs, so a single successful example proves little without the conditions around it. Ask whether the inputs are delivered in a form your team can rerun in a staging environment, and how sensitive content is handled.
Severity and business impact notes
Each finding should be rated for impact on your business, not only for how convincing the output looks. A jailbreak that produces off-policy text in a sandboxed chatbot carries different weight from an injection that causes the agent to send customer data to an external address. Ask how the provider weighs data exposure, unauthorized actions, financial effects and reputational harm, and whether the rating is explained in terms your risk committee can use.
Remediation for prompts, tools and outputs
Remediation guidance should address the three places where injection risk is usually reduced: how prompts separate trusted instructions from untrusted content, which tool permissions the model holds and whether they follow least privilege, and how model output is validated before it reaches a downstream system or user. Jailbreak findings usually point to safety tuning, policy layers and monitoring rather than to the application code. Expect the fixes to be specific to your architecture, and confirm which ones your team or a vendor will implement.
Retest plan
A retest plan sets out which findings will be checked again, how the same inputs will be replayed after changes, and which new test cases should join the regression set. Prompt injection fixes often change behavior in other places, so a single fix confirmed once is not enough. Ask whether retesting is included in the fixed scope or sold separately, and whether the regression cases will be handed over so your team can run them in CI.
When compliance and risk frameworks point to each test
Start by treating the framework mappings as planning inputs. NIST AI 600-1 action MS-2.7-007 calls for AI red-teaming that assesses resilience against generative AI attacks such as prompt injection, along with abuse that facilitates attacks on other systems. That makes prompt injection the clearest framework anchor for an application that reads external content. The OWASP Top 10 for LLM Applications 2026 keeps LLM01 Prompt Injection as its own entry and lists LLM10 Improper Output Handling separately, so a test plan should cover both the input path that alters behavior and the output path that passes unvalidated model text into downstream systems. Jailbreak testing is covered within LLM01 as a form of prompt injection, so it belongs in the same plan rather than in a separate compliance line.
The sources do not say that any regulator mandates jailbreak testing or prompt injection testing by name. Confirm the applicable requirements with your regulator, your internal or external auditor, and the security clauses in customer contracts. Ask each of them whether they expect evidence of indirect injection tests through retrieved documents, email or web content, and whether they expect tests of the model's safety behavior itself. Record the answers, because they will decide how much weight the team gives each test type in its scope document.
Treat any mapping between these frameworks and your test plan as a planning aid, not a certification. A mapping shows which risk a test is meant to address, but it does not produce an audit report, attestation or certificate, and it does not establish that a control is effective. Use the ATLAS technique IDs, such as AML.T0051.001 for indirect prompt injection and AML.T0054 for LLM jailbreak, to label test cases and findings consistently, and confirm with your assessor how they want that evidence presented.
What drives cost and effort for each test
Cost and effort for a prompt injection or jailbreak test follow the size of the attack surface, not the test label. The cards below show who is paid for what, which costs are one-time and which recur, and what to put in a written scope before requesting a quote.
Entry points for external content
Every place the application accepts text it did not write, such as web pages it summarizes, uploaded files, emails, tickets and retrieved documents, is a path for indirect prompt injection. Each entry point needs its own test cases, payloads and evidence, so the count drives tester time directly. Ask the provider to list each source in the written scope and to state which ones are in and out.
Tool and data integrations
When a model can call tools, query databases or send messages, a successful injection can cause actions, not just wrong text. Each integration adds scenarios that check what the model may do, which credentials it uses and whether outputs reach downstream systems. Confirm which tools are live in the test environment and whether test accounts can safely trigger writes.
Authentication and test environment setup
Testers need representative user roles, test tenants, seeded data and a non-production copy of the retrieval index and tool endpoints. Setup is usually one-time work, but it recurs whenever prompts, roles or connectors change. Ask who builds and maintains the environment, who pays for any cloud resources, and whether the client or the provider owns the test data.
Model and provider variety
Each model, hosted endpoint or fallback route can respond differently to the same payload, so testing more providers multiplies the runs needed for a fair result. Ask whether the scope covers one production model, every configured model, or a sample, and whether re-testing is needed after a provider changes a model version.
Manual versus automated attack generation
Automated tools can generate and replay large payload sets quickly, but a tester still has to judge whether a response is a real change in behavior. Manual crafting of context-specific injections costs more senior time and produces fewer but deeper findings. Ask the provider what share of the work is automated, how results are reviewed, and what the report will prove.
Retest cycles after fixes
Prompt changes, guardrail updates and new tools can reopen a closed finding, so retesting is a recurring cost tied to release frequency. Ask whether the quote includes one retest of each fix, how many rounds are covered, and whether a retainer for continuous testing is a better fit for a fast release cadence.
Questions buyers ask before choosing prompt injection or jailbreak testing
Which test should we buy first for a business application?
For most business applications that read external content, call tools or expose data to users, prompt injection testing should come first. The question to answer is whether an attacker-supplied input can change what your application does, which affects data, actions and other users. Jailbreak testing matters most when the model's own refusals are the control you rely on, such as a public chatbot with no tools and no sensitive data. The OWASP LLM01 entry treats jailbreaking as a form of prompt injection, so a good engagement usually covers both, weighted toward injection. Confirm the weighting with the provider in the written scope.
Do we still need jailbreak testing if our model provider has safety training?
Yes, provider safety training is one layer, not a control you can verify from your side. Model behavior changes with versions, system prompts and retrieval content, so a refusal that held last quarter may not hold after an update. Ask the provider which safety measures apply to your deployment, which model version you run and how they handle changes. Then test your own configuration, since your system prompt, filters and tool permissions shape what a jailbreak can reach.
What does the testing work need from our team?
The work needs access and a named owner more than it needs your code. Expect to provide:
- Test accounts with the same roles your real users have, including any that can reach tools or data
- Documentation of every tool, plugin or data source the application can call, with the permissions each one holds
- The system prompt or its design rules, where your security policy allows sharing them
- A named owner who can answer scope questions, approve test actions and decide on fixes
Without tool documentation, testers cannot tell which injected instructions have real consequences.
Can our own engineers run these tests, and what skills does that take?
Your team can run basic checks, but a meaningful test needs skills across prompt construction, application security and the specific tools the model can reach. Internal staff can use open test suites to catch known patterns in regression runs, which is useful between formal tests. Judging whether an injected instruction caused a harmful action, and tracing indirect injection through documents and web content, is harder to do well in-house. Decide which tests run continuously and which need an experienced tester before a release.
What sets the duration of a prompt injection or jailbreak test?
Duration depends on the scope you agree in writing, not on a fixed package. The main drivers are the number of entry points (chat, uploads, email, web retrieval), the number of tools and data sources the model can reach, how many user roles you test, and whether the team must also review the system prompt and guardrail configuration. Each added tool with write permissions adds test paths. Ask for the planned test cases by entry point and the assumptions behind the timeline before you sign, and confirm the timing with the vendor for your environment.
How do we combine these tests with our existing penetration test?
Keep the penetration test for the web, API and infrastructure layers, and add prompt injection and jailbreak work for the model behavior layer. The two overlap where the model's output reaches a browser, a database query or an API call, since improper output handling is a shared concern. NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk, so write one rules of engagement that covers both and map each finding to the layer that owns the fix.
What should we ask for in a quote?
Ask for a written scope that lists each entry point, tool and role in the test, the attack categories covered (direct injection, indirect injection through documents or web content, and jailbreak attempts), and the test accounts and environments used. Request the deliverables, the reporting format, how findings are rated and how retests are handled. Also ask what is one-time work (scoping, test design, the report) and what recurs (regression runs, retainer support), and what changes the price if scope grows. DeployOpen does not publish a price list, so a quote follows from the written scope.
How do retests after a fix work?
A retest checks that the fix closes the specific injection path or jailbreak that was reported, and that the change did not open a new one. Prompt-based fixes are fragile, so the stronger fixes usually sit outside the prompt: limiting tool permissions, requiring confirmation for sensitive actions, filtering or validating outputs, and separating untrusted content from instructions. Agree in advance how many retest rounds the scope includes, who verifies closure, and whether regression tests run after each model or prompt change.
How to combine the two tests in release testing
Run the two tests in a fixed order so that each one builds on the other. Start by mapping the application's inputs and tools: every place user text, uploaded files, retrieved web pages, database rows, email bodies and tool outputs can reach the model, plus every action the model can trigger, such as sending a message, writing a record or calling an API with a service identity. This map is the test plan. Without it, prompt injection testing tends to cover only the chat box, and the indirect paths that carry instructions into the model through documents and retrieved content are never exercised. Ask the product team to confirm which tools run with which permissions, because the impact of a successful injection depends on those permissions more than on the wording of the attack.
Next, run prompt injection tests on every input path, including the indirect sources, and treat the results as a remediation list. OWASP LLM01 describes direct injection as user input altering behavior and indirect injection as external content such as websites or files carrying instructions. For each path, record whether the injected instruction changed a tool call, a data access or an output that a downstream system trusts. Fix the control that failed, such as reducing tool permissions, separating untrusted content from instructions, validating model output before it reaches another system, or requiring confirmation for sensitive actions. Then run jailbreak tests against the model behaviors the business depends on, such as refusal of a restricted request or adherence to a required policy, because a jailbreak can succeed without any injected content. NIST AI 600-1 action MS-2.7-007 covers red-teaming for both generative attacks such as prompt injection and abuse that facilitates attacks on other systems.
Feed both result sets into a regression set that runs on every release, and store each case with its input path, expected behavior and the control it checks. Treat a fixed finding as unproven until the same case passes again after the change. This is the same principle that PCI SSC and CIS Control 18 apply to penetration testing: validate the controls after the test so that detection and prevention cover the techniques the testers used. Do not claim that a passing set proves the application is secure. The set shows only that known cases still behave as expected. Confirm with your testing provider how new cases from incidents and external research are added, and who owns the set after the engagement ends.
Steps to scope a prompt injection or jailbreak engagement
This sequence turns a vague request to "test our AI assistant" into a written scope that defines which business functions, data, input channels and model behaviors are tested, how success is measured and when testing repeats. Each step produces a document or decision that the next one depends on.
Map the business function and reachable data
The client's application owner and DeployOpen's testers list what the application is for, which users it serves, and every system, record set, tool or API the model can read or change on the user's behalf. The output is a short inventory of functions and data stores, with a note on which actions run without a human approving them. The step is done when the application owner signs off the inventory, because every later decision depends on what an injected instruction could reach.
Enumerate every input channel
Testers list each place content enters the model's context: the chat box, uploaded files, retrieved documents, web pages the app fetches, email or ticket bodies, database fields, tool outputs and results returned from other agents or services. Direct injection comes from the user prompt, while indirect injection arrives through external content that the model may treat as instructions, so the external channels usually need the most attention. The step closes with a channel register that marks each channel as user-controlled, third-party-controlled or internally generated.
Decide whether model safety behavior is in scope
The client and DeployOpen agree whether testing covers only the application's behavior, such as whether injected text can change a transaction or leak a record, or also whether the underlying model can be pushed past its safety rules. OWASP treats jailbreaking as a form of prompt injection, so the decision is about the goal being tested, not the category of attack. The output is a written statement of in-scope and out-of-scope goals. If the model provider's own safety behavior is included, confirm with the provider what testing it permits.
Agree rules of engagement and test accounts
The parties write rules of engagement covering permitted techniques, test windows, production versus staging use, data handling for any sensitive output the tests reveal, escalation contacts, and stop conditions. Testers receive dedicated test accounts with the same permissions as real roles, and the client confirms that any tool calls or outbound requests triggered by test prompts are safe to execute. NIST SP 800-115 provides a rules of engagement template in Appendix B that teams can adapt. This step is complete when both parties have signed the document, since fixed-scope work starts only after scope, deliverables and timelines are agreed in writing.
Set success criteria and retest conditions
The parties define what counts as a finding, such as an injected instruction that changes a tool call, exposes data across a tenant boundary, or causes the model to ignore a stated policy, and how severity is rated. They also set the retest triggers, such as a model version change, a new tool or data source, or a changed system prompt. The output is a success criteria table and a retest plan. Ask the provider to confirm which test results are reproducible across runs, since model output can vary.
How DeployOpen scopes, delivers and supports LLM application security testing
DeployOpen plans and runs security testing for LLM applications inside your own cloud accounts, data centers or air-gapped networks. We scope the work in writing before testing starts, then document, hand over and, if you choose, keep testing as the application and its model changes.
How we scope
- Written scope names which LLM features, data sources and tools are in and out of bounds for prompt injection tests.
- We agree whether direct user input, retrieved documents and web content are all tested for indirect injection.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any test begins.
- Jailbreak coverage is scoped separately if you need model safety behavior assessed as well as application behavior.
How we build
- We set up a test environment that mirrors the production prompt template, tool access and data connections, where practical.
- Test cases map to OWASP LLM01 scenarios and to ATLAS technique IDs so results can be traced to a shared catalog.
- Injected content is tested against the actions the application can take, such as sending data, calling APIs or writing records.
- Testers record the exact inputs, model version and configuration used so each finding can be reproduced.
How we hand over
- The report separates injections that change application behavior from jailbreaks that only alter model output.
- Each finding includes reproduction steps, affected components and the controls we recommend, written for engineers and risk owners.
- You receive the test cases and scripts so your team can rerun them after changes to prompts, models or tools.
- We document the test evidence and control status, but independent auditors and certification bodies issue any assessment outcome.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer for applications that change frequently.
- Retesting after fixes is agreed in the original written scope, so you know what is covered and what it costs before work starts.
- Regression sets can be rerun on each model or prompt change, with results reviewed against the agreed scope.
- Ask us to confirm the retainer terms, response expectations and handover format in your written quote.
