AI and LLM Penetration Testing: The 2026 Buyer's Guide

A chatbot exposed a customer's full order history to another user through a carefully constructed prompt. A retrieval-augmented generation system leaked confidential internal documents because the vector store was not scoped to the requesting user. A production agent with tool access wired to a payment API executed an unauthorised refund when tricked by a prompt embedded in a support ticket. These are not hypothetical examples. They are the kinds of findings AI-focused pen testing teams have been surfacing throughout late 2025 and into 2026, as large language models moved from pilot to production across every industry that can afford them.

Traditional application security testing does not catch these issues. Testing AI systems requires a different methodology, a different skill set, and in many cases a different kind of provider. This guide is for buyers making their first procurement decision in AI and LLM penetration testing.

What Makes AI Testing Different

A conventional web application has a finite set of inputs, predictable state transitions, and deterministic outputs given the same input. None of these assumptions hold for LLM-based systems.

The input surface is effectively infinite. Natural language does not have the same constraints as a structured API, and prompt injection attacks exploit this by embedding instructions in data that the model treats as trusted.

Behaviour is probabilistic. The same input can produce different outputs across runs, which makes reproducing vulnerabilities harder and makes regression testing after a fix non-trivial.

The system boundary is fuzzy. Modern LLM applications include the model itself, retrieval components, tool invocation layers, agent frameworks, vector stores, and often external APIs the model can reach. An attack can traverse all of these, and a pen test scoped only to the application layer will miss most of what matters.

Trust boundaries behave unexpectedly. Data that is merely displayed to users in a traditional application can be executed as instructions when passed through an LLM. This means that input sanitisation, output encoding, and privilege separation all need to be reconsidered.

The OWASP LLM Top 10

The OWASP LLM Top 10, now in its 2025 revision, defines the dominant vulnerability categories in LLM applications. Any competent AI pen test should explicitly cover all ten.

Prompt injection remains the most consequential vulnerability class. Direct prompt injection occurs when an attacker crafts input that overrides the model's system instructions. Indirect prompt injection is more subtle, embedding malicious instructions in content the model consumes later, such as web pages it retrieves or documents it summarises. Mitigations include instruction hierarchy techniques, input filtering, and treating all retrieved content as untrusted.

Insecure output handling covers cases where LLM output is treated as trustworthy by downstream systems. If a model's response is rendered as HTML without escaping, executed as SQL, or passed to a shell, the model becomes an attack vector even without a malicious user.

Training data poisoning targets the integrity of the model itself by injecting malicious examples into training or fine-tuning data. For organisations fine-tuning their own models, or using public datasets, this is a live concern.

Model denial of service involves crafting inputs that consume disproportionate compute, either as a cost attack on pay-per-token APIs or as an availability attack on self-hosted infrastructure. Token amplification and recursive generation patterns are the most common vectors.

Supply chain vulnerabilities apply to both model weights and the broader ML software stack. Pre-trained models from public repositories can contain backdoors. Dependencies in the ML pipeline, including serialisation libraries, have produced high-severity CVEs.

Sensitive information disclosure occurs when models reveal data from their training set, from their current context window, or from connected systems. This is particularly acute in RAG systems where access control on the underlying data store is inconsistent.

Insecure plugin and tool design covers agent frameworks where the LLM can invoke tools on behalf of users. If tool authorisation is checked at definition time rather than invocation time, the model can effectively escalate its privileges.

Excessive agency is the risk that an agent is given more autonomy than it should have. An agent that can book flights is relatively safe. An agent that can book flights and has persistent access to a corporate card becomes a more complex threat model.

Overreliance is a governance issue as much as a technical one. Users and downstream systems that assume LLM output is authoritative, without verification steps, create cascading risks.

Model theft covers both the exfiltration of proprietary weights and the reconstruction of a model's behaviour through query access, sometimes called model extraction.

Key Questions to Ask a Provider

Evaluating an AI pen testing provider requires questions that are different from those you would ask a traditional appsec firm.

Do you have a dedicated AI red team, or are you retrofitting existing pen testers with AI training? Organisations that have invested in dedicated AI capability, with researchers who have published on adversarial machine learning or contributed to OWASP LLM Top 10 discussions, are markedly ahead of firms that added AI testing as a side service in 2024.

What is your MLSecOps experience? Testing production AI systems often requires understanding of the deployment pipeline, monitoring, and update cadence. Providers who have worked in MLSecOps contexts ask different questions during scoping and catch issues that pure security testers miss.

How do you test indirect prompt injection across the RAG pipeline? This is a proxy question for depth. Shallow providers focus on direct prompt injection against the chat interface. Deep providers consider the full content ingestion pipeline, including documents, search results, and any other data sources the model consumes.

Do you test tool and plugin authorisation explicitly? Many AI pen tests skip this, particularly when the provider comes from a pure appsec background. For any system using agents or tool-calling, this is critical.

How do you handle the non-determinism in reporting? Providers should have a clear approach to demonstrating that a finding is reliably exploitable, not just a one-time anomaly. This typically involves either statistical testing or adversarial techniques that increase success probability.

Do you test model cost and availability attacks? Model DoS is often underweighted in scope. For any pay-per-token deployment, this is both a security and a financial risk.

Pricing Expectations

AI and LLM penetration testing sits at the high end of the pen testing market. A focused engagement targeting a single LLM-based feature typically costs 25,000 to 45,000 US dollars. A full assessment covering multiple features, agent frameworks, and RAG pipelines in a production AI product typically costs 50,000 to 80,000 US dollars. Engagements for foundation model providers, AI platform companies, or organisations building mission-critical AI systems frequently exceed 100,000 US dollars.

These prices reflect both the scarcity of genuinely qualified testers and the time-intensive nature of the work. AI pen testing involves substantial manual testing, iterative prompt engineering, and analysis of non-deterministic behaviour that is slower than traditional appsec testing.

Timelines are typically three to six weeks, longer than a conventional web pen test of comparable scope. Expect the provider to ask for documentation of your system architecture, training data provenance, and deployment pipeline before scoping is finalised.

Providers With AI and LLM Capability

Our directory lists providers that explicitly offer AI and LLM penetration testing as a service category. At the top end of the UK market, SECFORCE has built a dedicated AI pen testing practice covering the OWASP LLM Top 10 and adversarial machine learning. NCC Group has a research-backed AI assurance practice. Cure53 in Berlin has audited major LLM products and is particularly strong on prompt injection research. Trail of Bits in the US is well known for rigorous work on ML supply chain security and has published widely on model serialisation vulnerabilities.

Beyond the large specialists, a growing number of boutique firms focus exclusively on AI security. Evaluate these carefully. The field is young enough that the gap between genuine expertise and AI-adjacent marketing is still wide.

Standards and Regulatory Framing

The regulatory landscape around AI security is consolidating quickly.

The EU AI Act, in its final form, imposes obligations on high-risk AI systems that include risk management, data governance, technical documentation, transparency, human oversight, accuracy, and cybersecurity. Penetration testing is a practical mechanism for demonstrating the cybersecurity requirement, particularly for high-risk systems.

NIST's AI Risk Management Framework, AI RMF 1.0 and its 2024 Generative AI Profile, provides a voluntary framework that US and international organisations are increasingly using as a reference. The Measure function of the framework specifically covers security testing of AI systems.

ISO/IEC 42001:2023 is the international standard for AI management systems, and organisations pursuing certification typically need evidence of AI-specific security testing as part of their information security controls.

Industry-specific requirements are also emerging. DORA's operational resilience testing expectations extend to AI components in financial services systems. Healthcare AI regulators in multiple jurisdictions are beginning to require security testing for clinical decision support tools.

For buyers, the practical implication is that AI pen testing is moving from optional to expected for any organisation deploying AI in production, particularly in regulated sectors. The market is tight, the provider landscape is uneven, and the cost of getting it wrong, both in direct incidents and in regulatory exposure, is meaningful.