What is an AI/LLM penetration test?

An AI/LLM penetration test is a structured security assessment of large language model systems and the infrastructure around them. Unlike traditional pentests that target code and servers, an AI pentest evaluates prompt-handling logic, guardrails, tool calling, retrieval pipelines, memory, model outputs, and the full application stack that exposes the model. Berghem tests using the OWASP LLM Top 10, MITRE ATLAS, and our proprietary Promptware Kill Chain, attempting prompt injection, jailbreaks, data leakage, model theft, unsafe tool invocation, and adversarial inputs. The result is a clear picture of real-world AI risk with reproducible proofs of exploitation.

What is the Promptware Kill Chain?

The Promptware Kill Chain is a 7-stage attack framework based on the research by Schneier et al. (2025) and adapted by Berghem for practical offensive use, modeling how adversaries compromise AI systems — from initial access through prompt injection or malicious plugins, to privilege escalation, reconnaissance, persistence, command and control, lateral movement, and actions on objectives. We validated the framework after documenting 21 real-world promptware incidents in 2025–2026, 15 of which showed four or more kill chain stages and 57% of which maintained active persistence. It gives defenders a shared language to describe AI attacks and Berghem a repeatable methodology for red teaming.

Is OWASP LLM Top 10 covered?

Yes. Every Berghem AI/LLM penetration test explicitly covers the full OWASP LLM Top 10, including prompt injection, insecure output handling, training data poisoning, model denial of service, supply chain vulnerabilities, sensitive information disclosure, insecure plugin design, excessive agency, overreliance, and model theft. We also map findings to MITRE ATLAS, NIST AI RMF, and ISO 42001 where applicable. Clients receive a coverage matrix showing which techniques were exercised, which controls held, and which require remediation — giving leadership and engineering teams an unambiguous view of AI risk against the industry standard.

How long does an AI security assessment take?

A typical AI security assessment takes between two and six weeks, depending on scope and depth. A focused LLM penetration test against a single chatbot or RAG pipeline usually completes in 2–3 weeks. A comprehensive AI red team exercise, covering multiple agents, tools, and data sources using the full Promptware Kill Chain, can take 4–6 weeks. AI governance and assessment engagements — where we also review architecture, data flows, and regulatory posture — are scoped to the organization's size. We always agree timelines and rules of engagement with the client before work begins.

Do you handle compliance with the EU AI Act?

Yes. Berghem helps organizations meet emerging AI regulatory obligations, including the EU AI Act, Brazil's PL 2338 AI bill, ISO/IEC 42001, and NIST AI RMF. Our AI governance practice maps your AI systems against the EU AI Act risk classification — prohibited, high-risk, limited, and minimal — and identifies the technical and organizational controls required for each category. We support risk management, documentation, transparency, human oversight, post-market monitoring, and conformity assessments. For high-risk systems, we align our offensive testing with EU AI Act Article 15 requirements on accuracy, robustness, and cybersecurity.

AI Security Platform

AI era

LLM pentest, adversarial Red Team, ISO 42001 governance and continuous monitoring — designed for the real AI stack, not adapted from web testing.

Schedule an AI diagnostic

21Incidents 2025–26

$234BMarket by 2032

74%Companies with AI in prod

Quality assurance

AI Security

Every security testing provider promises to find vulnerabilities. Few can guarantee that each finding in the report is real, exploitable and correctly prioritized — that is the difference between a report that drives action and a report that drives rework.

A single false positive reaching the client is not operational noise: it is erosion of trust. The client loses hours investigating something that does not exist, questions every other finding by association, and the reputational cost outweighs the value of the entire engagement. Our methodology starts from a non-negotiable premise — no finding reaches the client without mechanical evidence that makes it defensible.

The problem

Why most assessments fail

Most tools treat "finding" as a single category. We treat it as four distinct problems — because each one destroys value in a different way.

False Positive

A finding that does not exist in the environment. It erodes trust directly.

False Negative

A real vulnerability that goes unreported. The worst case: the client is exposed without knowing.

VP-I

Irrelevant True Positive

The vulnerability exists, but is not exploitable in that context. Operationally, it costs the same as an FP.

VP-MP

Mis-Prioritized True Positive

500 real findings without prioritization are worth, in practice, the same as 500 false positives.

Generic assessments only fight the FP. We address all four.

The engineering

The engineering behind the guarantee

The differentiator is not a marketing promise — it is a pipeline with five components that work together.

Client Environment Profile

Before any test, we map what is installed and authorized by policy, which controls are active and with what coverage, how the network is segmented and how identity/MFA are configured. That is what lets us distinguish "RustDesk installed" from "RustDesk authorized by policy, with verified hash". Without that context, the two look identical.

Hard rule: no finding is finalized with a trust profile below 60%.

FP Risk Score (0–100)

Each finding gets a score computed from six independent blocks — authorized inventory, behavior of active controls, formal allowlist, real exploitability in the segment, identity/MFA configuration and historical sector pattern. The score does not decide, it informs.

< 40 · standard flow40–69 · human validation> 70 · blocked until decision

Analyst Decision, traceable

The analyst sees the score, the reasons behind it and four options mapped directly to the taxonomy: confirm, reject as FP (with mandatory justification), reclassify as irrelevant or re-prioritize. A high score requires a justification recorded for audit.

Sector Learning

Every decision feeds a database of patterns by sector and size. The system learns, for example, that a given behavior is legitimate in 80% of mid-sized banks but only 17% of hospitals — and applies that knowledge from day one on a new client. Confidence in the pattern grows with volume and decays over time (18-month half-life), tracking the changing landscape.

Automatic Update with Governance

Decisions enter an asynchronous queue, are aggregated every 6 hours in staging and only reach production after six quality gates: minimum volume, analyst diversity, engagement diversity, individual bias detection, temporal consistency and abrupt-change check. A daily monitor automatically downgrades rules that start to diverge from recent behavior.

For you

What this means for you

Line-by-line defensible report

Each finding ships with the mechanical evidence that justifies its presence.

Less rework for your team

VP-I and VP-MP are filtered out before they become tickets.

A learning curve that becomes an asset

The more engagements in your sector, the more accurate the result — without rebuilding from scratch.

Complete audit trail

Every decision is recorded, ready for compliance.

74%BR companies using AI in production

$234BAI security market by 2032

21Promptware incidents 2025–26

57%Attackers maintain persistence

Promptware Kill Chain

Seven stages
One unified attack framework

Adapted from the research of Schneier et al. (2025), our Promptware Kill Chain maps how real adversaries compromise AI systems — from initial prompt injection to total exfiltration.