Skip to content
Service 13

AI Penetration Testing

Hands-on testing of LLMs, agents, and RAG — prompt injection, data exposure, and the tools a model should never have been allowed to call.

A new attack surface, not a new scanner

Putting a model into a workflow does not just add a feature. It adds a surface traditional application testing was not built to cover: instructions hidden in user input, documents, or retrieved pages; agents that can call tools; and data the model can see that no UI ever showed a user.

We test that surface the way an attacker would. The question is not whether the model can be talked into a rude reply. It is whether it can be talked into ignoring its policy, leaking data, or taking an action you would not allow a stranger to take.

This is a different engagement from web application penetration testing. Web work answers what HTTP will give up. AI work answers what the model will do once it is in the loop.

What we test

Prompt injection. Direct instructions in a chat, and indirect ones buried in a ticket, an email, a PDF, or a page your RAG pipeline will retrieve. If the model has tools, this is a path to action, not just a path to text.

Data exposure. What the model can read, summarize, or quote that it should never have been able to reach — another tenant, another role, a system prompt, or a document outside the ask.

Tool and agent abuse. The functions the model is allowed to call, and whether a crafted input can make it call the wrong one, with the wrong arguments, as the wrong identity.

Supply chain around the model. Plugins, vendor APIs, and embedded assistants that expand the blast radius when they fail. We do not pretend every integration is in scope; we scope to the ones you actually run.

The threats we keep seeing — poisoning, adversarial input, extraction, ungoverned shadow tools — are the ones we wrote down in AI Changed the Rules. This engagement is that list, run against your system.

What this is not

It is not a policy workshop. Governance still matters, and it is not a substitute for proving whether the running system holds.

It is not a phishing simulation that happens to use better grammar. AI-written pretexts belong on a social engineering engagement.

It is not a promise that we will “secure your model.” We show you what an attacker can make it do, then tell you which control actually stops that.

What you receive

A report ranked by what the model actually did: the input, the path, the data or action it reached, and the change that closes it. We retest once you have remediated, the same as any other penetration test.

Common questions

AI Penetration Testing — what clients ask

Is this just a web application test of our chatbot?
A web test still answers what an attacker can do to the application around the model. This engagement answers what they can do through the model — injecting instructions into a prompt, a document, or a retrieved page, then watching whether the agent leaks data or calls a tool it should not. If the interesting surface is HTTP, start with a web or API test. If it is the model, start here.
Do you need our weights, our prompts, or just an endpoint?
An endpoint, the tools and data the model can reach, and a written description of what it is allowed to do is enough to start. System prompts and architecture notes make the test faster and more complete. Model weights are rarely required, and we will not ask for training data we do not need.
Will you jailbreak production?
We test against an agreed environment — usually a staging instance with production-like tools and data classification, not a live customer-facing model with no backstop. Jailbreaks that only produce a rude sentence are not the finding. A jailbreak that reads another tenant’s records or fires a privileged tool is. Rules of engagement are in writing before anything is sent.

Strengthen your defenses.

Tell us what you need tested. We’ll come back with scope, timeline, and a fixed price.

Request a quote