Our model only answers questions. Is there anything to test?

Less, and not nothing. The questions are what it can be made to disclose, whose data is in its retrieval corpus, and what happens to its output afterwards. If the answer is rendered as HTML in someone's browser, a text-only model still has an injection path.

We use a hosted model. Isn't this the provider's problem?

The provider is responsible for the model. You are responsible for what you connected it to, what you put in its context, and what you do with its output, and that is where essentially all of the exploitable risk lives.

Can prompt injection be fixed?

Not at the prompt layer. Instructions and data share one channel and there is no equivalent yet of the parameterised query that solved SQL injection. What can be fixed is the architecture around it: deterministic checks before the model, the model as one signal rather than the gate, an explicitly chosen failure mode, and a blast radius small enough that a successful injection is survivable.

Service

AI Model Penetration Testing

Prompt injection, data exfiltration and misuse testing of LLM-backed features.

Prompt injection is the top entry in OWASP's Top 10 for LLM Applications, and it has held that position across editions for a structural reason: a language model receives instructions and data through the same channel, with nothing marking which is which. That is not a bug in any one product, and it means the useful question is not whether a model can be talked around but what it is wired to once somebody does.

How this works

Map what the model can reach

The first task is the blast radius rather than the prompt. What tools can the model call, what data is in its retrieval corpus, whose documents enter that corpus, what does its output touch afterwards, and does anything downstream execute or trust what it returns. A model that can only produce text is a content problem; one wired to a database, a shell or a payment action is an authorisation problem.

Direct and indirect injection

Direct injection is the user typing an instruction. Indirect is the one that gets missed: instructions planted in content the model ingests later, such as an uploaded document, a scraped page, a support ticket or a calendar invite. Where retrieval is used, poisoning the corpus is tested as a first-class attack rather than an edge case.

Guardrails treated as filters, not boundaries

Where a model or classifier is used to police another model, that arrangement is tested on its own terms. Published research finds character-injection and evasion techniques defeat production guardrails, and that a judge from the same model family inherits the weaknesses of the thing it judges. Multi-turn escalation is tested specifically, because a filter that scores each message alone cannot see an attack that exists only across a conversation.

Output handling downstream

Model output is treated as untrusted input to whatever consumes it. Rendering it as HTML, passing it to a shell or an interpreter, using it to build a query, or feeding it to another agent are each tested, since this is where prompt injection stops being a content issue and becomes remote code execution.

What we look for

System prompt disclosure, and what it reveals about tooling and internal structure
Direct instruction override, role reassignment and delimiter confusion
Indirect injection through retrieved documents, uploads, tickets and scraped content
Multi-turn escalation that no single message would trigger a filter on
Training or retrieval data leaking through the model, including other tenants' content
Tool and function calling invoked with arguments the user should not control
Output passed unsanitised to a renderer, a shell, a query builder or another agent
Failure mode when the model errors, times out or returns something unparseable, and whether that fails open
Cost and quota abuse through prompts that are expensive to serve

What you get

A map of what the feature can reach, which is the finding most teams do not have written down
Reproducible cases for each successful attack, with the exact input and the resulting behaviour
Architectural recommendations rather than prompt patches, since a hardened prompt raises cost and does not change the shape
An assessment of what the guardrail layer actually buys, stated honestly

What this does not include

Model alignment or safety evaluation of a foundation model itself
Bias, fairness or accuracy assessment, which is a different discipline
Training data provenance or licensing review
A guarantee that a prompt-level defence will hold, because none does

Questions people ask

Our model only answers questions. Is there anything to test?: Less, and not nothing. The questions are what it can be made to disclose, whose data is in its retrieval corpus, and what happens to its output afterwards. If the answer is rendered as HTML in someone's browser, a text-only model still has an injection path.
We use a hosted model. Isn't this the provider's problem?: The provider is responsible for the model. You are responsible for what you connected it to, what you put in its context, and what you do with its output, and that is where essentially all of the exploitable risk lives.
Can prompt injection be fixed?: Not at the prompt layer. Instructions and data share one channel and there is no equivalent yet of the parameterised query that solved SQL injection. What can be fixed is the architecture around it: deterministic checks before the model, the model as one signal rather than the gate, an explicitly chosen failure mode, and a blast radius small enough that a successful injection is survivable.

Discuss ai model penetration testing All services