AI PENETRATION TESTING

Testing an AI or LLM application is not the same as testing a normal web app. In a conventional app, code and data travel in separate lanes — the program is the instruction, the user only supplies data. A language model erases that line: it reads instructions and data through the same channel, so any untrusted text it processes can turn into an instruction it follows. Add retrieval-augmented generation (RAG), and the model starts pulling in external content — documents, web pages, tickets — that you did not write and cannot fully vet. Give it agency, and it stops merely answering: it calls tools, hits APIs, and takes actions on your systems. Each of these shifts opens a class of weakness that a standard pentest simply does not look for. Our AI penetration test targets exactly that surface, grounded in the OWASP Top 10 for LLM Applications (2025).

If you want a primer on how the core attack works before reading on, our team wrote one here: understanding prompt injection.

What we test

We map every engagement to the OWASP Top 10 for LLM Applications (2025) so findings line up with a framework your developers and auditors already recognise.

• LLM01 — Prompt Injection — Crafted input that overrides the model's intended instructions. We test both direct injection (the attacker types the payload) and indirect injection (the payload hides inside content the model later reads, such as a document or web page).
• LLM02 — Sensitive Information Disclosure — The model leaking data it should not reveal: other users' data, secrets, internal configuration, or fragments of its training data.
• LLM03 — Supply Chain — Risk carried in by third-party models, plugins, datasets, and libraries — a compromised or tampered component upstream of your application.
• LLM04 — Data & Model Poisoning — Malicious or corrupted data introduced during training or fine-tuning that bends the model's behaviour toward an attacker's goal.
• LLM05 — Improper Output Handling — Treating model output as trusted and passing it straight into a browser, shell, database, or downstream API, where it becomes XSS, SQL injection, or command injection.
• LLM06 — Excessive Agency — An agent granted more permission, tool access, or autonomy than its task requires, so a single manipulated instruction can trigger real-world actions.
• LLM07 — System Prompt Leakage — Exposure of the system prompt, revealing hidden instructions, business rules, or secrets a designer assumed no one would ever see.
• LLM08 — Vector & Embedding Weaknesses — Flaws in the RAG layer: weak access control on the vector store, embedding inversion, or poisoned documents that steer retrieval toward attacker-chosen content.
• LLM09 — Misinformation — Confident, plausible, and wrong output — hallucination and over-reliance — that causes harm when a user or downstream system acts on it.
• LLM10 — Unbounded Consumption — No limit on how much a caller can make the model do, enabling denial of service, runaway cost, or model-extraction through high-volume querying.

How we test

Every engagement runs through the same phases, so you always know where the project stands and what arrives next.

1. Scoping — We map the target with you: which model and version, what the RAG sources are, which tools and APIs the agent can reach, and the roles or privilege tiers in play. Untested surface is agreed here, not discovered at the end.
2. Static review — We examine the system prompt, model configuration, and any guardrails or content filters, so dynamic testing is informed rather than blind.
3. Prompt injection & jailbreak testing — We attempt to override intended behaviour through both direct input and indirect payloads planted in content the model ingests, then measure whether guardrails hold under pressure.
4. RAG & embedding testing — We probe the retrieval layer: access control on the vector store, whether poisoned or crafted documents can steer answers, and whether embeddings leak the source text behind them.
5. Agent & tool-abuse testing — For agentic systems we test excessive agency directly: can a manipulated instruction make the agent call a tool, hit an API, or take an action beyond its intended authority?
6. Output-handling & downstream-impact testing — We follow model output into whatever consumes it and check whether unsanitised output becomes XSS, injection, or an unintended action in a connected system.
7. Reporting & retest — Findings are written up with impact and remediation, and once your team has fixed them, we retest to confirm each issue is genuinely closed.

What you get

Every report contains, at minimum:

• Executive summary — a business-level risk picture, suitable for management and auditors.
• Findings by Risk Level — each issue rated Critical, High, Medium, or Low so remediation can be prioritised objectively.
• POC for every finding — the exact prompts, payloads, and steps that reproduce the issue; your engineers should never have to guess how we did it.
• Remediation guidance — practical fixes tied to your architecture, not scanner boilerplate.
• Retest verification — findings are re-checked after your fixes and the report is updated to reflect closed items.

We have delivered zero blank reports in the company's history — every engagement so far has surfaced real, validated findings.

Team credentials

Testing is performed by our in-house team holding industry certifications including OSCP, OSCE, CREST CRT, CREST CPSA, and GIAC GREM — credentials earned through rigorous, hands-on examination. The same team applies that offensive-security background to the newer AI attack surface. See the full list of certifications the team holds.

Standards

Our AI testing is grounded in the frameworks the field has converged on:

• OWASP Top 10 for LLM Applications (2025) — the backbone of what we test, as listed above.
• OWASP Machine Learning Security Top 10 — for risks in the ML layer beneath a generative application.
• MITRE ATLAS — the adversarial-threat knowledge base for AI systems, used to reason about attacker techniques.
• NIST AI RMF — the risk-management framing we align findings to when you need to speak to a governance audience.

A penetration test tells you where an AI system breaks today. Keeping it safe as it evolves is a governance question — building an AI Management System around ISO/IEC 42001 — and that is handled by our consulting team. Testing and governance are complementary: one proves the current state, the other keeps it defensible over time.