AI & LLM Pentest (AI VAPT)

The difference between an AI and LLM pentest and a regular application pentest is a new class of finding: the model being manipulated into misusing its own authorised access.

The classic application layer is still tested and still produces findings. Authentication, authorisation, tenant separation in the vector store and rate limiting on the API around the model are ordinary flaws, and much of the real risk still sits there.

What is added is the class where text the model was given, not code, persuades it to call a function it should not have called or to return a document the requester was never entitled to read. That is not a code flaw, so it is not found by looking for code flaws. It needs a tester who reasons about what the model is permitted to do.

An AI and LLM pentest is needed by anyone who has put a model in front of customer data, given it tools that change state, or deployed an agent that acts without a human approving each step.

The question that decides severity is what the model can reach. A customer service assistant with read access to order history, a copilot that can raise tickets or move money, and an agent that browses and executes are three different risk levels, and the scope should reflect that.

If the model can only produce text that nobody acts on, the risk is much lower and we will say so at scoping rather than sell you an engagement sized for an agent. Where CBUAE, the UAE IAS or the DESC ISR already require independent testing of the systems in scope, a model in front of regulated data is one of those systems.

An AI and LLM pentest tests both direct and indirect prompt injection, and indirect injection is always in scope where the system ingests external content.

Direct prompt injection

The attacker types the payload. We test instruction override, role confusion, encoding tricks and multi-turn state manipulation, and what is recoverable from the context window, including the system prompt and any keys people assumed were hidden.

Indirect prompt injection

The payload is placed in content the model will read later: a document, a web page, a support ticket, an email. The user asks an innocuous question, the model ingests the poisoned content and follows it. This is the highest-severity path in most deployments and the least tested.

Severity is set by what the injected instruction can make the model do with its tools and data, not by whether the model said something embarrassing.

Prompt injection cannot be eliminated at the model layer today, so an LLM penetration test tells you where the architecture fails to contain it.

The controls that work sit around the model. Scope tool permissions to the requesting user rather than to the service, enforce authorisation in the retrieval index and not in the prompt, and require human approval for actions that matter. Where those controls are missing, the report says so and names the owner.

Guardrails and input filters are tested rather than trusted. A filter that blocks the payloads we tried on day one is a bar, not a boundary, and the report grades it as one. The fix is to make sure a model that has been talked around still cannot reach anything the requester could not reach themselves.

An AI and LLM pentest tests what you built around the model, and the model itself only where you own or fine-tune it.

Hosted commercial model

The model's own safety behaviour is the vendor's responsibility. What you are responsible for is the system prompt, the retrieval layer, the tools it can call and the permissions those run with, so that is what we test.

Model you own or fine-tune

The model is in scope as well. Fine-tuning can undo safety behaviour, training data can be recovered through the model, and a self-hosted model brings its own serving stack with its own ordinary flaws.

Either way it is a test of an architecture, not of a model's opinions.

An AI and LLM pentest treats an agent's tools as its attack surface, and coverage scales with the number of tools multiplied by the ways each can be reached.

For each tool we test parameter injection, unintended invocation and whether the tool's permissions match the requesting user's or the service's. The question that decides severity is agent blast radius: what a redirected agent can actually reach and change.

Autonomy adds its own classes. Action chaining, where one tool's output steers the next call, loop and cost abuse, and whether a human approval step can be talked around are all in scope. If the agent can move money, we test whether it can be made to.

An AI and LLM pentest tests whether the retrieval layer enforces the requester's permissions, or retrieves first and hopes the model declines to answer.

Index-level authorisation and tenant separation in the vector store are checked directly, because a filter applied after retrieval is a filter the model can be talked out of. We also look at what one tenant's documents can do to another tenant's session when both are indexed together.

Data exfiltration through the model is tested end to end: an injected instruction that makes the model summarise a document the user cannot open, encode it, and send it out through a tool call or a rendered link. The finding is the path, not the individual weaknesses along it.

An AI and LLM pentest is grey box by default, and white box materially improves coverage because the interesting question is what the model is permitted to do, not what it will say.

Black box

We start with nothing but the chat window, the way a real attacker does. Realistic, but the budget goes into guessing the tool set and the retrieval layer instead of testing them.

Grey box

A normal user account and a description of what the system is meant to do. The honest default, and enough to reach the tool and retrieval findings that matter.

White box

The system prompt, tool definitions and retrieval configuration in hand. Time goes into the paths a model could be steered down, not into discovering that they exist. The right choice when the question is completeness.

An AI and LLM pentest typically takes two to three weeks including reporting.

Agentic systems with several tools take longer, because coverage scales with the number of tools multiplied by the ways each can be reached. A system that ingests external content adds an indirect injection path through every content type it reads.

Supplying the system prompt, tool definitions and retrieval configuration at the start shortens the engagement more than anything else, because time spent discovering is time not spent testing. Reporting is included in that window, and the retest that follows your fixes is quoted separately at the start.

An AI and LLM pentest uses the OWASP Top 10 for LLM Applications as its taxonomy, with ordinary application testing for everything around the model and MITRE ATT&CK mapping where a technique applies.

The engagement runs the same six phases as every RedTeam Security test: gathering information, threat modelling, vulnerability analysis, exploitation, post exploitation and reporting. Findings are proved, never asserted, and the report contains the steps you can follow to see each one yourself.

The test is not performed by AI. Tooling assists with coverage, and every reported finding was reproduced by a person. An automated pass over a language model produces a list of refusals and near misses, not an assessment.

An AI and LLM pentest should be repeated after any change to the system prompt, the tool set, the retrieval configuration or the underlying model version.

A model upgrade is a change to the security boundary even when no code changed, which is the part teams routinely miss. The same prompt with a new model behind it can follow an injected instruction it previously refused, or call a tool with parameters it previously declined.

The retest of open findings is quoted up front with the original engagement, so running it again after one of those changes is a known cost rather than a new procurement.

The deliverables of an AI and LLM pentest are a report split between the model-specific classes and the application layer, architectural recommendations, and a retest.

Each finding carries reproduction steps, severity and a named owner. The model-specific findings are written against the OWASP Top 10 for LLM Applications, the application findings are ordinary pentest findings, and both are mapped to MITRE ATT&CK where a technique applies. The report then sits alongside the rest of your risk reporting rather than beside it.

Architectural recommendations cover where tool permissions, retrieval authorisation and human approval are missing. Once fixes land we retest and issue an attestation of what was tested and found, not a certificate.