Why prompt injection testing is now a buying requirement
If an assessor, a customer security review, a launch gate, an insurer or a due diligence team has asked you for evidence that prompt injection was tested, you need a test that shows which guardrails and controls held against it. Prompt injection testing answers that request: it builds attack scenarios against your LLM application and its tools, then records whether the surrounding controls stopped the injected instructions from changing what the system did. It does not judge how well the underlying model writes or reasons. There are two forms to plan for. In *direct prompt injection*, the user types instructions meant to override the system prompt or the application's rules. In *indirect prompt injection*, the instructions arrive inside content the system reads on the user's behalf, such as a retrieved document, a web page, an email, a ticket or the output of a tool call. The indirect form is the harder one to assess because the person sending the malicious text is often not the person who is harmed. The OWASP Top 10 for LLM Applications 2026, published in August 2026, places Prompt Injection first as LLM01, and it is the entry most assessors will expect to see addressed by name.
Prompt injection matters most where it connects to what the system is allowed to do. LLM03 Excessive Agency describes the risk that a model holds more tools, permissions or autonomy than its task needs, so a successful injection has more to act on. In the agentic list, ASI01 Agent Goal Hijack covers an agent's objectives being redirected by injected content, and ASI02 Tool Misuse covers an agent using its legitimate tools in harmful ways once it has been redirected. Confirm early which tools, data sources, credentials and write actions your application exposes, because that inventory determines which scenarios are worth building and which guardrails must be shown to hold. The OWASP GenAI LLM Top 10 2026 is the reference your test plan should map to, and your auditor may ask for that mapping directly.
What prompt injection testing looks for in your system
Prompt injection is less a single bug than a property of systems that mix instructions and untrusted content in one context window. The categories below show where that mixing happens in a deployed application, what it costs the business when it goes wrong, and which OWASP or MITRE ATLAS reference frames the test.
Direct injection through user input
Direct injection happens when a user's own message overrides the instructions the developer set, for example by asking the model to ignore its rules or adopt a different role. In a deployed app this matters most where the model answers customers, handles account questions or sits behind a chat widget. We check whether role boundaries hold under adversarial phrasing, whether refusals are consistent across languages and turns, and whether business rules live only in the prompt or also in code.
Indirect injection through documents and web content
Indirect injection hides instructions inside material the model reads on the user's behalf, such as uploaded files, web pages, shared documents or emails. The user may never see the hostile text. We build test scenarios from the content sources your application ingests, trace how retrieved text enters the context, and check whether the model separates data from instructions. MITRE ATLAS tracks this as LLM Prompt Injection: Indirect (AML.T0051.001).
Injection through tool and API outputs
Tools return data that the model then reads, including search results, database rows, ticket text and responses from third-party APIs. A field that looks harmless in one system can carry instructions into the next step of an agent or workflow. We inventory every tool output that reaches the model, test whether untrusted fields are clearly marked as data, and check whether a returned value can change which tool is called next. This links to the agentic risk ASI02 Tool Misuse.
System prompt exposure
System prompts often contain business logic, internal tool names, routing rules or credentials that were never meant to reach users. Extraction attempts can reveal them even when the developer believed they were private. The 2025 OWASP list ranked this as LLM07 System Prompt Leakage, and the 2026 edition covers the wider problem as Hidden Context Exposure at LLM08. We test what the model will reveal, whether secrets sit in prompts at all, and whether leakage exposes details an attacker can use for later steps.
Jailbreak bypass of safety behavior
A jailbreak persuades the model to produce content or take steps its safety training and deployment policy were meant to block. This differs from injection into business logic, but the two often combine, since a jailbroken model is easier to steer through hostile content. We test the policy categories your use case actually cares about, record which framings succeed, and separate model-level refusals from controls you added around the model. MITRE ATLAS tracks this as LLM Jailbreak (AML.T0054).
Unsafe actions after a successful injection
The real impact of injection depends on what the system can do next. An injected instruction that only changes a chatbot's wording is a low-grade issue, while one that triggers an email, a payment, a record change or a privileged API call is a serious incident. We map each reachable action, check whether it requires separate authorization or user confirmation, and confirm that tool permissions follow least privilege. This connects to OWASP LLM03 Excessive Agency and ASI03 Identity and Privilege Abuse.
What can be in scope for a prompt injection test
Prompt injection risk depends on where untrusted text enters the system, what the model reads, and what it is allowed to do with that text. The agreed scope fixes these boundaries, and it also defines what counts as a guardrail that held, so the scope should be written with the same care as the test plan.
Untrusted text entry points
List every channel where text reaches the model: chat input, web forms, file uploads, email or ticket intake, connectors and any page the model can browse. Each channel is a path for direct or indirect injection. Ask the tester to confirm which entry points are in scope and which are excluded, and record the reason for each exclusion so the gap is visible to the client's auditor.
Data sources the model reads
Document stores, retrieval indexes, knowledge bases, tool outputs and web content all feed instructions into the context window. Scope should name each source, who can write to it, and whether attackers outside the organization can reach it. Content that a low-privilege user can plant in a shared document is often the most useful scenario for testers to build.
Tools, agents and permissions
Document every tool the model can call, the action each performs, and the identity it uses. A prompt injection that changes an answer is a different finding from one that sends an email, writes a record or calls an internal API. Agree which actions are read-only in the test environment and which write actions are simulated or sandboxed.
Test environment and data
Choose between a staging system with production-like data and a separate copy built for the engagement. Production data should not be used for injection payloads that trigger outbound calls or writes. Confirm whether the environment uses the same model version, system prompt, guardrail layers and tool connections as production, since results only transfer if these match.
Test accounts and roles
Agree which accounts the tester will use: an anonymous user, a standard user, an administrator and, where relevant, a user from another tenant. Injection risk often depends on the role behind the session, so testing only one role leaves the most sensitive paths unexamined. Ask for accounts with the same permissions as real users, and confirm how they are created and removed.
Rules of engagement and stop conditions
Define rate limits so tests do not disrupt service or trigger cost spikes, rules for handling any sensitive data the model reveals, and conditions that stop testing immediately, such as unintended writes to live systems. Agree who is notified and how evidence is stored and deleted. These rules protect the client and give the tester a clear basis for reporting a guardrail as held or failed.
What drives the cost and duration of prompt injection testing
This table lists the scope factors that move the effort of a prompt injection engagement and how to shape each one before requesting a quote. DeployOpen does not publish a price list, so read each row as a question to settle in the written scope. The main takeaway is that the number of untrusted input paths and side-effecting tools usually matters more than the size of the model.
| Driver | Why it moves cost | How to scope efficiently |
|---|---|---|
| Untrusted data sources and entry points | Each channel that feeds the model (uploaded documents, web pages, email, tickets, tool outputs) adds scenarios that must be built and checked for indirect injection. | List every channel in the model's context and mark which ones carry content from outside your organization. Test the highest-exposure channels first and agree the rest in a later round. |
| Tools and agents with side effects | Tools that send messages, change records, move money or run code turn an injected instruction into an action, so each one needs its own control checks and evidence. | Separate read-only tools from write or execute tools. Scope deep testing to side-effecting tools and confirm which ones run in a non-production sandbox. |
| User roles and tenants | Each role or tenant boundary changes what a successful injection could reveal or do, so tests must be repeated across permission levels. | Name the roles that matter for the threat model and the tenant isolation claims you make to customers. Test representative roles rather than every combination. |
| Depth of tests per scenario | A scenario that only checks whether a guardrail triggers costs less than one that measures bypass variants, multi-step chains and whether the action completed. | Agree a fixed set of harm scenarios with pass or fail criteria. State whether variant generation is included or limited to the listed scenarios. |
| Environment access and setup | Test accounts, seeded documents, logging access and a non-production copy of the model stack determine how much time goes to setup before testing starts. | Confirm in writing who provisions test accounts, which logs are available to testers and whether the environment mirrors production prompts, tools and guardrails. |
| Retest rounds | Fixing guardrails usually needs verification. Each retest repeats the affected scenarios and adds evidence, so the number of rounds should be fixed in the scope. | Define how many retest rounds are included, which findings are covered and what counts as closed. Ask whether retests are priced separately. |
| Recurring retesting after model or prompt changes | A new model version, system prompt edit, new tool or changed retrieval source can reopen previously passing scenarios, so this work recurs rather than ending with the assessment. | Decide which changes trigger a targeted rerun and which need a full assessment. Consider a retainer for continuous testing if releases are frequent. |
How a prompt injection engagement runs, phase by phase
The sequence turns an open question about whether an AI system can be steered by untrusted content into a documented record of which controls held, which failed, and what was fixed and retested.
Scope the system and model its threats
DeployOpen and the client map the LLM application, its system prompt design, the data sources it reads, the tools it can call and the users who can reach it. The threat model maps prompt injection and related risks to LLM01 Prompt Injection and to the adjacent items in the OWASP Top 10 for LLM Applications 2026, and to the agentic list where the system acts on users' behalf. The step closes with a signed scope document listing in-scope components, test accounts, permitted tool actions and the data that must never be exposed during testing.
Classify the attack surface and entry points
Testers inventory every channel through which text can reach the model: direct user input, uploaded documents, retrieved web pages, email or ticket content, and the outputs of tools and APIs. Each channel is tagged as direct or indirect injection, with its trust level and what a successful instruction could trigger. Mapping these paths against NIST AI 100-2 E2025, the adversarial machine learning taxonomy, gives a shared vocabulary for evasion and manipulation attacks. The step closes with an entry point register the client has reviewed.
Design scenarios from documents, web content and tool outputs
Testers build test cases that place instructions inside the content the system is designed to trust, such as a document in a knowledge base, a web page the assistant summarizes, or a field returned by an internal tool. Each scenario states the intended harm in plain terms, such as an unauthorized data disclosure or an action outside the user's permissions, and a benign control version. Harm scenarios are aligned with the MITRE ATLAS technique for indirect prompt injection (AML.T0051.001). The step closes with a reviewed scenario set, each case with an expected safe behavior.
Run controlled tests with full logging
Tests run in a non-production environment with synthetic data and sandboxed tool endpoints, so no real customer records or live transactions are touched. Testers log every model input, retrieved context, system prompt version, model output and tool call with timestamps and identifiers. Rate of execution and any rate limits are agreed in advance to avoid disrupting the client's service. The step closes with a complete, time-ordered test log that lets each result be reproduced by the client's own engineers.
Analyze which guardrails held and which failed
For each scenario, testers classify the outcome: the instruction was ignored, partly followed, or fully followed. They then identify which control made the difference, such as input filtering, context separation, output validation, tool permission checks or human approval steps, and which control was missing. Findings are tied to the affected OWASP category and to the MITRE ATLAS technique where relevant. The step closes with a guardrail matrix showing each control, the scenarios it was tested against and the observed result, with reproduction notes.
Report findings with prioritized remediation
The report sets out each finding with its scenario, evidence from the logs, affected component, business impact in the client's own terms and a recommended fix. Remediation advice covers design changes such as separating trusted instructions from retrieved content, restricting tool permissions and validating outputs, rather than only adding filter rules. The report also states what was out of scope and which limits of testing apply, so that the client's auditor or customer can read it accurately. The step closes with a delivered report and a findings walkthrough with the client's engineering and security leads.
Retest fixes and record the outcome
After the client applies fixes, testers rerun the original scenarios and a set of related variants to check whether the change holds and does not open a new path. Each finding is marked closed, partly closed or open, with the evidence for that status. Where a fix depends on a model or vendor update, the report notes what must be rechecked after that update. The step closes with a retest addendum that records the status of every finding and the version of the system tested.
Which frameworks and rules expect prompt injection testing
This table compares the frameworks, standards and regulations that name prompt injection or adjacent agent risks, what each one expects, and the evidence an assessor is likely to ask for. Read it as a starting map: the assessor decides which control IDs apply and whether the evidence is sufficient, so confirm the mapping before scoping the test.
| Framework or rule | What it expects | What the evidence looks like |
|---|---|---|
| OWASP LLM01 Prompt Injection (LLM Top 10 2026) | Testing that direct and indirect instructions cannot override the system prompt, alter tool use or expose data across user inputs, documents and web content. | Scenario catalogue, test inputs by source, observed model and guardrail behavior, and a retest record for each finding. |
| OWASP LLM03 Excessive Agency | Evidence that a model cannot trigger actions beyond what its function needs, so a successful injection has limited blast radius. | Tool inventory with permissions, scenarios showing whether injected content could trigger each tool, and confirmation or approval gates in the results. |
| OWASP ASI01 Agent Goal Hijack (agentic applications) | Tests that untrusted content cannot redirect an agent's goal, plan or task away from what the user or operator approved. | Scenarios from documents, emails or web pages mapped to the goal, with logs showing whether the agent stayed on task. |
| OWASP ASI02 Tool Misuse (agentic applications) | Tests that legitimate tools cannot be steered into harmful or unintended calls, including through injected tool outputs. | Per-tool test cases, parameter validation results and records showing which calls were blocked, logged or required approval. |
| MITRE ATLAS AML.T0051.001 LLM Prompt Injection: Indirect | A mapping of indirect injection tests to this technique, updated in ATLAS v2026.09, so findings can be traced to a shared adversary model. | Test cases tagged with the technique ID, source type of each injected payload and the defensive controls tested against it. |
| MITRE ATLAS AML.T0054 LLM Jailbreak | Tests of whether safety behavior can be bypassed by reframing or multi-step prompts, which also informs direct injection scenarios. | Documented attempts with the technique ID, the guardrail tested and whether the bypass held after mitigation. |
| EU AI Act Article 15(5), resilience of high-risk AI systems | Resilience against attempts to exploit vulnerabilities, including model evasion and confidentiality attacks, which covers prompt injection in many deployments. | Documented test plan, results and remediation tied to the system's risk assessment. Confirm with counsel whether the system is high-risk. |
| EU AI Act Article 55(1), adversarial testing for general-purpose AI models with systemic risk | Documented adversarial testing for providers of general-purpose AI models with systemic risk. Most application builders are not providers under this article. | Adversarial testing records with scenarios, methods and results. Confirm applicability with the provider's legal team before scoping. |
| NIST AI 600-1, Generative AI Profile | Voluntary guidance to address generative AI risks across design, development, use and evaluation, including testing of injection pathways. | Risk register entries for injection, test records linked to identified risks and evaluation results reviewed by the owning team. |
| HITRUST agentic AI factor (HAA 2026-005, CSF v11.9.0) | An agentic AI selectable factor in the AI Security Certification, mapped to the OWASP Top 10 for Agentic Applications 2026, so ASI controls are assessed. | Evidence mapped to ASI01 to ASI10 as the assessor requests. Confirm with the HITRUST assessor which factors and controls apply. |
What you receive and whether it satisfies your auditor or customer
A prompt injection engagement produces evidence at several levels, from the scenario-by-scenario findings to a summary that a customer or auditor can read. The cards below describe each item, what it should contain, and what to confirm with the people who will rely on it before the work starts.
Findings report
The main deliverable lists each scenario tested, whether it used a direct or indirect route, and which guardrail held or failed. Each finding should include logged inputs, the tool calls or outputs observed, a severity rating, and context on how likely the issue is to be exploited in your deployment. Ask for the rating method in writing so your risk team can challenge it.
Defensive reproduction description
Each confirmed issue gets a description that lets your engineers see the weakness category and the conditions that produced it, without a working payload library. Expect the trigger class, the affected component, and the observed behavior. Confirm with the assessor how sensitive reproduction detail is stored and who can receive it.
Remediation view mapped to LLM and ASI
Remediation guidance is grouped by the relevant OWASP categories, such as LLM01 Prompt Injection, LLM03 Excessive Agency and ASI01 Agent Goal Hijack, so that engineering, product and governance teams can track fixes against a shared vocabulary. Each item should name the control change, the owner it needs, and the findings it closes. Ask whether the mapping also covers the MITRE ATLAS technique references you use internally.
Retest result
After fixes are deployed, the same scenarios are run again and each finding is marked closed, partially closed or still open, with new evidence attached. A retest confirms the changes you made were tested, but it does not cover scenarios that were never in the original scope. Agree the retest window and any included scenarios in the original statement of work.
Summary letter for customers or auditors
A summary letter describes the work performed, the scope, the period and the high-level results. It does not certify the system, and it is not an audit report or attestation. Before signing, check with your assessor or customer what format they accept, whether they need a named signatory, and whether they expect a specific framework reference.
What your team prepares before testing starts
Before a prompt injection engagement starts, your team names the people who will make decisions during the test: an engineering lead who can explain the application's architecture, an AI product owner who can say which behaviors matter to the business, and a security operations contact who will watch the logs and can stop a test if it affects production. Provide a written description of the model in use, the system prompt and any prompt templates, every retrieval source the application reads from (document stores, web pages, ticket queues, email), and each tool or function the model can call, with the permissions each tool holds. Test accounts should exist for each role the application supports, such as an anonymous user, a standard user and an administrator, so testers can check whether injected instructions cross those boundaries. Ask for these artifacts in writing before kickoff, because the scenarios depend on them.
Prepare sample documents, web pages and tool outputs that look like the content your users actually process, but contain no real personal data, customer records or live credentials. Synthetic records that match your schemas usually serve testers better than masked production data, and they remove a data handling question from the engagement. Confirm that your logging and monitoring capture model inputs, tool calls and outputs for the test accounts, and that the SOC knows the test window and the source addresses testers will use. Then decide whether a change freeze is needed so the prompts, retrieval index and tool configuration stay fixed while results are measured. Finally, confirm with your model provider and your cloud provider what security testing they permit against their hosted services, and whether notice or approval is required, since their published terms govern what is allowed regardless of what you approve internally.
What to check before you hire a prompt injection tester
Prompt injection testing depends on judgment about model behavior, tool access and document pipelines, so the provider's experience matters as much as their method. The six checks below cover what to verify before signing, what the engagement should look like on paper, and what the provider should decline to do.
Hands-on work with LLM and agent systems
Ask for evidence that the team has tested language model applications and agents in practice, not only web applications with a chatbot added to scope. Ask how they map findings to the OWASP Top 10 for LLM Applications 2026, the OWASP Top 10 for Agentic Applications for 2026 and MITRE ATLAS techniques, including the indirect prompt injection technique AML.T0051.001. Ask which tool-calling and retrieval setups they have tested.
Written scope and rules of engagement
The agreement should name the target application, model and version, the data sources and tools in scope, the test accounts, and the environments allowed. It should state which attack categories are excluded, how harmful outputs will be handled, and who is contacted if a test affects a live system. Confirm that the scope is fixed in writing before any testing starts.
A documented, repeatable method
Ask for the written method: how test scenarios are built from documents, web content and tool outputs, how each run is recorded, and how many attempts are made per scenario because model outputs vary between runs. A method that cannot be repeated by another tester, or that depends on one person's intuition, will produce results that are hard to verify or retest.
Findings separated from model behavior
A good report distinguishes a confirmed weakness, such as a tool call that executes an attacker-supplied instruction, from an observation that the model sometimes produces unwanted text. Ask how the provider records evidence, what severity criteria they use, and whether they state the conditions under which each finding reproduces. Treat a list of model quirks with no control failure behind it as a weak deliverable.
Retesting after prompt and model changes
Prompts, system instructions, model versions and retrieval sources change often, and a guardrail that held on one version may not hold on the next. Ask how retesting is scoped, whether fixes are verified against the original scenarios, and what happens when the model provider changes a model under the same name. Agree on the retest trigger and whether it is included in the fixed fee or quoted separately.
What the provider will not do
A prompt injection test produces findings and evidence, not an assurance. The provider should state in writing that it does not issue audit opinions, attestations or certifications, and that independent auditors and certification bodies decide what a test means for a framework. Also confirm that the provider will not exploit live customer data beyond what the agreed rules allow, and that they will not publish findings without your approval.
Prompt injection testing questions buyers ask
What drives the cost of prompt injection testing and can I get a fixed quote?
Yes, most engagements are fixed-scope, so a quote follows from a written scope agreed before work starts. DeployOpen does not publish a price list. The main cost drivers are the number of AI entry points (chat interfaces, document upload paths, web retrieval, email or ticket ingestion), the number and privilege of tools the model can call, how many user roles and data sources are in play, and whether the test runs against a staging system that mirrors production. Ask for the quote to list each entry point and tool in scope, the test categories covered, whether retesting is included, and which deliverables are fixed. Costs are largely one-time for the assessment itself. Ongoing testing after model or prompt changes is usually a separate retainer.
How long does a prompt injection test take?
The duration depends mainly on scope and access rather than on a fixed number of days. The timeline is set by how many entry points and tools must be tested, whether a non-production environment with realistic data flows is available, how quickly your team can answer questions about system prompts, tool schemas and guardrail configuration, and whether the agreed scope needs a retest after findings are fixed. Ask your provider to show the phases in the written scope, including the point at which access is granted and the date by which draft findings are delivered. Confirm the timeline with the provider against your own change calendar before you commit.
What does my team need to provide for the engagement?
Your team needs to provide enough context for testers to reach the same behavior your users and systems reach, without guessing. Typical inputs include a test environment or sandbox that mirrors production configuration, test accounts for each user role, documentation of the system prompt architecture and guardrail layers (input filters, output checks, tool permission rules), an inventory of the tools and APIs the model can call with their permission scopes, a sample of the documents and web sources the system ingests, and a named contact who can answer questions within the working period. Agree in writing who approves any test that could touch live customer data or trigger external actions.
Can our own staff run prompt injection testing in-house?
Your staff can run a useful internal program, and many teams should, but a self-run program has blind spots. Internal testers know the system well, which makes them good at confirming that intended controls work, but they often test the paths they designed and miss creative indirect injection through content the system trusts, such as a retrieved web page, a PDF or a tool output. They also tend to stop once the obvious cases pass. An independent test adds an outside view of attack paths, a documented method your auditor or customer can review, and comparison against the threat categories in the OWASP LLM Top 10 2026. A common pattern is to run regular internal regression checks and commission an external assessment on major releases.
How does prompt injection testing differ from a general LLM application test or AI red teaming?
Prompt injection testing is a focused engagement on LLM01, the top risk in the OWASP LLM Top 10 2026, and on how injected instructions reach the model from documents, web content and tool outputs. A full LLM application test covers that plus sensitive information disclosure, output handling, excessive agency, unbounded consumption and the web and API layers around the model. AI red teaming is objective-based: testers pursue agreed harm scenarios using MITRE ATLAS techniques rather than working through a checklist. Prompt injection testing results show which guardrails held for each scenario, which makes it a strong input to a red team or a broader application test. Confirm with your provider which of these three the written scope covers.
Does one prompt injection test satisfy the EU AI Act?
No single test satisfies the EU AI Act on its own, and a provider cannot certify compliance. Article 15(5) of Regulation (EU) 2024/1689 requires high-risk AI systems to be resilient against attempts to exploit vulnerabilities, including model evasion and confidentiality attacks. Article 55(1) requires providers of general-purpose AI models with systemic risk to perform documented adversarial testing. Prompt injection testing can produce evidence for the resilience requirement, including scenarios tested, results per guardrail and remediation records. Whether that evidence meets your obligations depends on your system's risk classification and your legal and compliance review. Ask your legal team to confirm which articles apply before scoping. DeployOpen prepares evidence for compliance assessments but does not issue audit reports or certifications.
How does retesting work after we change prompts or models?
Retesting should be defined in the written scope, because prompt, model and tool changes can reopen or create injection paths. Ask for a retest of the findings you fixed, a clear statement of how each finding is verified, and a regression set of scenarios you can rerun after changes. Changes that usually warrant a targeted retest include a new model version or model provider, edits to the system prompt or guardrail rules, new data sources or document types, and new tools or expanded tool permissions. For continuous coverage, a retainer can schedule regression runs and targeted tests on each significant change. Confirm the retest window and what counts as a material change in the contract.
How DeployOpen scopes, tests, reports and retests prompt injection
DeployOpen runs prompt injection testing as a fixed-scope engagement, with scope, deliverables and timelines agreed in writing before work starts. Testing covers direct and indirect injection paths, and the handover shows which guardrails held and which did not.
How we scope
- Map every input channel the model reads, including user prompts, uploaded documents, web pages and tool outputs.
- Record which tools, data stores and downstream actions the model can reach, so impact is judged against real permissions.
- Agree in writing which guardrails, filters and system prompt controls are in scope, and which test environment will be used.
How we build
- Build test scenarios from the agreed channels, such as a poisoned document in a retrieval source or instructions hidden in a tool response.
- Run scenarios in a non-production or otherwise agreed environment, with logging enabled so each attempt can be traced to its result.
- Record each scenario's outcome against the agreed guardrails, noting whether the control blocked, detected, or failed to stop the injected instruction.
How we hand over
- Deliver a written report that maps findings to LLM01 Prompt Injection and related entries in the OWASP LLM Top 10 2026, and to ATLAS techniques where relevant.
- Explain each finding with its scenario, the affected component, observed model behavior and the guardrail that did or did not hold.
- Provide prioritized remediation guidance for prompts, input handling, tool permissions and output checks, with evidence suitable for your own assessors.
How we support
- Retest agreed findings after fixes are deployed, so you can confirm which scenarios no longer succeed under the same conditions.
- Ongoing support, upgrades and continuous testing are available as a retainer, useful when models, prompts or tools change often.
- Ask in your quote how retesting is priced and bounded, and whether model or prompt changes after the engagement count as new scope.
