AI & LLM Application Penetration Testing

We start by learning what the assistant is allowed to do and what it is trusted with. Can it read customer records? Call internal APIs? Move money, change settings, send email? The blast radius of a prompt injection depends entirely on the permissions behind the model, so we map those first and build the test plan around the actions that would actually hurt.

Next we characterise the model’s behaviour: how it responds to instruction, where its guardrails sit, whether it exposes a system prompt under pressure, how it handles unexpected input formats. We fingerprint the retrieval layer, look at how context is assembled, and identify every place user-controlled text or third-party content reaches the prompt.

This is where the real work happens. We craft prompt injection chains, test indirect injection through documents, web pages and file uploads the model will later read, and try to escalate from a chat box into a real action. We attempt to exfiltrate other users’ data, extract the system prompt, bypass content filters, and turn function-calling into an attack primitive. Where the model output flows into a browser, a database or a shell, we test whether that output is treated as trusted, because that is often the finding with the highest impact.

Every finding is written up with a clear description, a business-impact rating, a CVSS score where it maps cleanly, the exact reproduction steps, and a fix we would actually implement. You get an executive summary for leadership and a technical report your engineers can work from. After you remediate, we retest for free to confirm the fixes hold.

On its own, getting a chatbot to say something rude is not a security finding. The problem is what sits behind it. When the same model can call an internal API, read a knowledge base or draft an email, an injection stops being a party trick. We routinely take a benign-looking assistant and drive it into behaviour its designers never intended, then show the exact path from user input to unwanted effect.

RAG systems pull in documents, tickets, web pages and files, and the model reads all of it as instruction unless you have designed against that. An attacker who can get text into any of those sources can plant instructions that fire later, for a different user, in a different session. This is one of the most under-tested risks in production AI features, and one we spend real time on.

Poorly scoped retrieval and shared context windows leak. We test whether one customer can retrieve another’s data, whether prior conversation state bleeds between sessions, and whether the vector store enforces the same access controls as the rest of your application. In multi-tenant products this is frequently the finding that keeps a CISO up at night.

If your application renders model output as HTML, you may have stored XSS. If it passes model text into a database query, a template or a system command, you may have injection with an LLM as the delivery vehicle. We check every downstream consumer of model output and treat that text as attacker-controlled, because in practice it is.

Autonomous agents that plan and call tools multiply the impact of a single bad instruction. One poisoned step can trigger a chain of API calls, file writes or purchases. We test how far a compromised instruction propagates and where the human-in-the-loop and permission checks should sit.

The practical checklist for LLM features, covering prompt injection, insecure output handling, sensitive information disclosure, excessive agency and the rest. We test every category that applies to your architecture and note the ones that do not, with reasons.

Where your risk model needs adversarial-ML framing, we map findings to MITRE ATLAS tactics and techniques so your team can reason about the threat the same way it reasons about the rest of the estate.

For organisations working toward the NIST AI Risk Management Framework or preparing for EU AI Act obligations, the testing evidence and report structure support your documentation. We are a European team and we build reports that fit how European regulators and auditors expect risk to be described.

An attacker who can send unbounded or deeply nested prompts can exhaust your token budget, spike latency for real users, or run your inference bill into the ground overnight. We test rate limiting, input-size caps and the controls around expensive operations such as long-context calls and tool loops, and we show you the cheapest request that does the most damage.

Your feature depends on model weights, plugins, embeddings libraries and third-party APIs you did not write. We review where those come from, whether a compromised dependency could poison retrieval or output, and whether a swapped or fine-tuned model could quietly change behaviour without anyone noticing. For teams pulling models from public hubs, this is a real and growing exposure.