Lakera Guard vs Prompt Guard 2 vs Prompt Shields vs ProtectAI DeBERTa: every ranking is self-reported

The only benchmark that scores all four of these on the same inputs is maintained by the vendor that tops it, its methodology notes are over 500 days old, and the figures everyone quotes predate the 2026 model versions. Meanwhile the two numbers that actually decide the deployment — your false-positive rate on your own traffic, and the latency the detector adds to every tool result — appear on no leaderboard at all, and the benchmark built to measure over-blocking is adversarially constructed by its authors' own account. So pick on licence, placement and latency, which are knowable, and measure accuracy yourself, which nobody can do for you.

By Agentic AI Wiki 17 min read

The one benchmark that scores all four of these on the same inputs is maintained by the vendor that tops it — and that is the least of the problem, because the two numbers that decide which detector you can actually run are on nobody's leaderboard: your false-positive rate on your own traffic, and the milliseconds the detector adds to every tool result. Choose on licence, placement and latency, which are knowable today, and treat every published accuracy figure as a claim by an interested party until you have reproduced it on your corpus.

At a glance

Four detectors that get recommended interchangeably, read against what you can verify about each.

DetectorShips asWeights & licenceEvidence it publishes
Lakera GuardHosted APINone releasedThe PINT benchmark it leads
Llama Prompt Guard 2 (22M / 86M)Downloadable classifierLlama community licence — use-restricted, not OSI-approvedModel card
Azure AI Content Safety Prompt ShieldsHosted API, one cloudNone releasedDocumentation, no scores
ProtectAI deberta-v3-base-prompt-injection-v2Downloadable classifierApache-2.0, ungatedModel card, plus third-party reruns

Read the last column first. One of these four publishes a benchmark, and it is the benchmark on which all four are compared. That is not an accusation of bad faith — Lakera built PINT precisely because the public injection datasets were contaminated, and open-sourcing the harness was the right instinct. It is a statement about what kind of evidence the ecosystem has: one shared ruler, held by a competitor.

PINT benchmark scores for four prompt-injection detectors A horizontal bar chart of scores on the PINT benchmark, which is maintained by Lakera. Lakera Guard is highest at about 95.2 percent, Azure Prompt Shields about 89.1 percent, Llama Prompt Guard 2 at 86 million parameters about 78.8 percent, and the original Llama Prompt Guard about 61.8 percent. A note records that the figures date to around May 2025 and that ProtectAI DeBERTa v2 appears in the same results table without a figure that could be confirmed. PINT score (%) — benchmark maintained by the top entry 25 50 75 100 Lakera Guard 95.2 Azure Prompt Shields 89.1 Prompt Guard 2 (86M) 78.8 Prompt Guard (v1) 61.8 Figures circa May 2025. ProtectAI DeBERTa v2 sits in the same results table; no current figure could be confirmed.
The ordering everyone quotes. The benchmark is maintained by the bar at the top, and the figures predate every 2026 model version in this comparison.
Where each prompt-injection detector leans A four by four matrix. Lakera Guard is a hosted API, has no weights you can hold, is self-hostable only under an enterprise arrangement, and publishes the benchmark it leads. Llama Prompt Guard 2 ships as downloadable weights under a use-restricted community licence, is fully self-hostable, and publishes a model card. Azure Prompt Shields is a hosted API bound to one cloud, has no weights, is not self-hostable, and publishes documentation rather than scores. ProtectAI DeBERTa v2 ships Apache-2.0 weights, is fully self-hostable, and publishes a model card with third-party reruns available. The four axes that survive the missing accuracy numbers Deployment shape Weights you hold Runs in your VPC Published evidence Lakera Guard Hosted API None Enterprise only Own benchmark Prompt Guard 2 Local classifier Use-restricted Yes Model card Prompt Shields Hosted, one cloud None No Docs, no scores ProtectAI v2 Local classifier Apache-2.0 Yes Card + reruns Yours outright Conditional Vendor-held
What survives the missing accuracy numbers: four axes you can check yourself in an afternoon.

The shared ruler, and who holds it

What PINT is

The Prompt Injection Test benchmark exists for a good reason. Public injection datasets leak into training sets, so a classifier fine-tuned on them scores well on them and poorly on anything else; PINT's stated purpose is to evaluate detection systems without relying on datasets those systems could have optimised against. Third-party summaries put the dataset at 4,314 inputs, English and non-English, mixing injections from public sources with Lakera's own proprietary collection, and — this part is genuinely good design — benign inputs that include hard negatives, text that looks like an injection and is not.

Three things in the methodology that change how you read the chart

The repository's methodology notes are specific, and the specifics matter more than the ranking. Azure Prompt Shields is counted as a positive if either its user-prompt shield or its document shield flags an attack, which is a reasonable choice for a product with two endpoints and a looser bar than a single-classifier verdict. Lakera Guard's own runs used only the prompt-attack category, against API version 2.0.106 dated 2 May 2025. The open-weights comparators are scored on label: ProtectAI's DeBERTa counts a positive when it emits INJECTION, Meta's Prompt Guard 1 and 2 when they emit injection or jailbreak.

Then the dates. Those methodology notes are over 500 days old. The changelog records Azure Prompt Shields being added to the results table in April 2024 and the public and internal prompt-injection categories being merged in December 2025 — a change to what the benchmark measures, after most of the figures in circulation were produced. Nothing here is hidden; it is all in the repository. It is simply not what a reader takes away from a bar chart.

The figure that does not match

A 2025 arXiv paper on evasion attacks against injection and jailbreak detectors reports Lakera Guard at 92.5461% on PINT, which it frames as 7.5439% of inputs falsely classified. The commonly quoted vendor figure is about 95.2%. Both are plausible readings of a moving target — different API version, different category selection, different snapshot of a dataset that has since been restructured — and that is the point worth taking away rather than any particular adjudication. When two careful parties report the same detector on the same named benchmark and differ by nearly three points, the benchmark is not a ruler. It is a photograph of a configuration.

Distrust any third-party comparison whose numbers exactly match a vendor's published figures. It has copied the table, not reproduced the run — and the table has a date on it that the comparison usually drops.

The number that decides the deployment is missing

Ask any team that has turned a detector off why they did. Almost nobody says it missed an attack. They say it blocked a customer. False positives are what get a guardrail disabled, and they are also the thing the ecosystem measures worst.

There is a benchmark for it. InjecGuard (arXiv 2410.22770) introduced NotInject: 339 benign samples deliberately packed with injection trigger words like "ignore", on which the paper reports state-of-the-art detectors collapsing toward chance — open-source models including Deepset, Fmops, Prompt Guard and ProtectAI v2 all below 60% over-defense accuracy. The paper's own system reports 87.32% over-defense accuracy, 85.74% benign accuracy and 77.39% malicious accuracy, which is the shape you would expect from a model trained with over-defense in mind.

Now look at what happened to those numbers afterwards. Later write-ups in the same line of work report Llama- and Phi-based defences above 90% on NotInject, with LlamaGuard3 at 99.71% — higher than the paper that introduced the benchmark. A separate vendor post measures 45.4% over-defense on its own system, 154 of the 339 blocked, and then says the thing everyone else leaves out: NotInject is adversarially constructed to bait over-blocking, so a score on it is not a production false-positive rate.

That caveat dissolves the whole exercise, correctly. A set of 339 sentences engineered to contain trigger words is a stress test of a specific failure mechanism, not a sample of your traffic. If your agent reads support tickets, the hard negatives in your corpus are customers quoting error messages and pasting configuration. If it reads code review comments, they are developers writing "ignore the previous approach". Neither distribution is NotInject's, and neither is the other's.

// The measurement that is actually decisive, and which you own:
//   1. 2,000 real inputs from last month's traffic, unlabelled.
//   2. Run each detector. Count flags.
//   3. Read the flagged ones. Every flag on benign text is a
//      support ticket you will receive in production.
//   4. Now add the 50 injections you care about and count misses.
//
// Step 3 before step 4. The miss rate decides whether to deploy;
// the false-positive rate decides whether it stays deployed.

This is the same reasoning the wiki applies to any detector you did not train: a published accuracy number is evidence about the benchmark's distribution, and your deployment decision needs evidence about yours. See evaluating guardrails and detectors for the harness, and decision-model thresholds for what to do with the score once you have it.

Lakera Guard — the hosted API that owns the ruler

What you get

A detection endpoint with latency in the tens of milliseconds, reported in guides as a 5–50 ms range in synchronous deployment, and the most mature product packaging of the four. Lakera has been part of Check Point since the 2025 acquisition, which matters less for the classifier than for the procurement path — it arrives as a security vendor's component rather than a library.

What you are accepting

Every input the detector screens leaves your network. For an agent, that is not a subset of your data; it is your prompts, your retrieved documents and your tool results, which is close to everything sensitive the system touches. Teams under data-residency constraints usually discover this at the architecture review rather than the pricing page — the residency question is the one that decides whether a hosted detector is available to you at all, independent of how well it scores.

You are also accepting a vendor-reported accuracy claim as your primary evidence. The detection rate quoted in secondary guides, above 98%, is the vendor's; the PINT figure is on the vendor's own benchmark. That is not disqualifying — it is a normal commercial situation — but it means the reproduction step is on you, and the hosted shape makes reproduction easy, which is the fair trade here.

Llama Prompt Guard 2 — weights you can hold, with an asterisk

What you get

Two classifier sizes, 22M and 86M, released on 29 April 2025 alongside Llama Guard 4 and LlamaFirewall in Meta's PurpleLlama repository, and still the current Prompt Guard release there as of October 2026. Eighteen months without a successor is itself information: this is a stable, cheap, local classifier, not a product on a release cadence. The 22M exists because a detector that runs on every tool result has to be affordable, and a 22M-parameter model is affordable in a way an API call is not.

What you are accepting

The licence, and the fact that reasonable people disagree about it. Sources describe the weights variously as behind Meta's access request, and as open weights under a use-restricted community licence that is not OSI-approved; an October 2026 GitHub issue in a tool-result scanner project lists Prompt Guard 2 as the non-permissive option next to ungated alternatives. If your distribution model involves shipping the detector to customers or embedding it in an open-source product, that distinction is load-bearing and you should read the licence rather than a comparison table — including this one.

You are also accepting the PINT ordering's bottom half. At about 78.8% for the 86M on a benchmark it did not design, Prompt Guard 2 is not competitive with the hosted options on the only shared number available — and the honest reading of that is partly that a 86M-parameter classifier is a different class of object from a vendor's full detection pipeline, and partly that we do not know, because nobody has rerun it on current versions.

Azure Prompt Shields — two endpoints, one cloud

What you get

A managed service inside Azure AI Content Safety with separate shields for user prompts and for documents — which is, structurally, the most agent-aware design of the four, because it acknowledges that the dangerous text usually arrives in retrieved content rather than in what the user typed. If you already run on Azure OpenAI, it is a configuration change rather than an integration.

What you are accepting

A hard cloud boundary: the detector exists where your inference does, and nowhere else. And the thinnest evidence of the four — documentation describes the categories and the API, not the accuracy. Its PINT figure of roughly 89.1% comes with the methodology note that a flag from either shield counts, so the number describes the pair, not a single decision you can tune.

ProtectAI DeBERTa v2 — the permissive baseline, and its 2026 successors

What you get

deberta-v3-base-prompt-injection-v2, fine-tuned from DeBERTa-v3-base and released in April 2024, Apache-2.0 and ungated. It is the thing you reach for when the requirement is "a classifier we can ship, read, fine-tune and pin", and it is still carried as a baseline in benchmark tables published in late 2026 — including the ones where it loses, which is how you know it is being measured rather than marketed.

What you are accepting

A 2024 model against 2026 attacks, and that is the real cost rather than any particular score. It also sits below 60% over-defense accuracy on NotInject in InjecGuard's table, which — with the caveat above about what NotInject is — at least tells you the trigger-word failure mechanism is present.

The part a comparison written six months ago would miss

The permissive-licence corner of this space moved in late 2026. Horizon Labs published a Prompt Injection Guard family (a 308M base and a smaller variant) under Apache-2.0 in September–October 2026, ungated, with a model card stating it was trained only on permissively licensed data — and self-reported figures of 0.887 macro average against 0.540 for Prompt Guard 2 86M and 0.637 for ProtectAI v2. Patronus's Wolf Defender is another Apache-2.0 entrant. Treat those numbers exactly as you should treat every other number in this post: self-reported, on the entrant's own evaluation, and worth reproducing before acting on. But the structural fact is checkable and it favours them — if you need permissively licensed, ungated weights in 2026, the choice is no longer "ProtectAI v2 or accept Meta's licence".

Where the detector sits, which matters more than which one it is

Two places a prompt-injection detector can sit in an agent loop Two lanes. The upper lane is the path most detectors were built for: a user types a prompt, the detector screens it, and the model answers. The lower lane is the path an agent actually runs: the model calls a tool, the tool returns a web page, an email or a retrieved document, and that text re-enters the context as the next model input. A note records that the second lane carries most indirect injection and is screened by configuration rather than by default. Lane 1 — the path the benchmarks measure User prompt typed, one turn Detector screens the prompt Model Lane 2 — the path an agent actually runs Tool call fetch, search, read Tool result page, email, doc Detector, if wired off by default Model the loop: every result becomes the next input Lane 2 carries most indirect injection. The published scores are all from Lane 1, on single typed prompts.
Every published score in this post was measured on the upper lane. Agents get attacked on the lower one.

Compare the four on placement and the ranking reshuffles. All four were built, and are all benchmarked, on a single input string: a user prompt, screened once, before the model sees it. That is where PINT's inputs come from and it is where the vendor documentation starts. An agent's exposure is somewhere else entirely — in the tool result, the retrieved chunk, the page the browser loaded, the issue body the coding agent read — and screening that path is a configuration decision each of these four leaves to you, with different costs. A hosted API on every tool result adds a network round trip per step and exports every retrieved document; a 22M local classifier adds single-digit milliseconds and exports nothing; Azure's document shield is the only one of the four whose API shape names the case.

The economics follow the same split. A detector on the user prompt runs once per conversation. A detector on tool results runs once per step, and an agent takes many steps, so the per-call figure that looked negligible in a chat product is multiplied by your step count — the same arithmetic as perception cost per step. This is the axis on which the open-weights options win outright, and it has nothing to do with accuracy.

Then there is what detection cannot do at all, in any position. A 2025 arXiv empirical analysis of evasion attacks against injection and jailbreak detection systems found the published systems bypassable by character- and word-level manipulations; Overflip (arXiv 2609.15013) documents repetition-induced label flips in guardrail models — the same content, repeated, changing the verdict. Both results say the same thing about architecture rather than about any product: a probabilistic classifier is a filter that raises attacker cost, and it is not a boundary. The boundary is what the agent is allowed to do after the text gets through, which is blast radius, egress control and the lethal trifecta — and a team that buys a detector instead of those has bought the wrong thing competently.

When to pick which

SituationPickBecause
Screening every tool result in a multi-step agentPrompt Guard 2 (22M) or ProtectAI v2Per-step cost and no data egress; a network hop per step is the thing you cannot afford
Already on Azure OpenAI, data stays in the tenantPrompt ShieldsConfiguration rather than integration, and the document shield names the agent case
You want a vendor accountable for detection qualityLakera GuardMature packaging and a procurement path; reproduce its figure on your corpus first
You ship the detector to customers or into open sourceProtectAI v2, or a 2026 Apache-2.0 entrantLicence is the constraint, and Meta's is use-restricted
Regulated, residency-bound, air-gappedAny local classifierThe hosted options are unavailable regardless of score
You have no labelled corpus yetNone of them, yetCollect 2,000 real inputs first; the false-positive rate you cannot see is the one that will turn the detector off

Spend the first afternoon on a corpus, not a comparison. Two thousand unlabelled inputs from last month's traffic, four detectors, count the flags on benign text. That single table beats every number in this post, because it is the only one measured on your distribution — and you will almost certainly find that the ranking it produces is not the published one.

FAQ

Which prompt-injection detector is the most accurate?

No published evidence answers that for 2026 model versions. The only benchmark scoring all four on shared inputs is maintained by one of them, its methodology notes are over 500 days old, and the figures in circulation predate the current releases. The ranking you can trust is the one you produce on your own traffic.

Is Llama Prompt Guard 2 open source?

It is open weights, not open source in the OSI sense. The Llama community licence is use-restricted, sources disagree about whether the weights are gated behind an access request, and at least one 2026 project classifies it as the non-permissive option next to Apache-2.0 alternatives. If you intend to redistribute the detector, read the licence text.

Can a detector stop indirect prompt injection?

It raises the cost and it does not close the hole. Published evasion work shows these systems bypassable by character- and word-level manipulation, and the Overflip result shows repeated content flipping a guardrail's label. Treat detection as one layer and put the actual boundary on what the agent can do after the text is in context.

Should I screen tool results as well as user prompts?

Yes, and that is where the cost comparison bites. Most indirect injection arrives in a retrieved document or a fetched page, not in what the user typed — and a detector on that path runs once per agent step rather than once per conversation, which makes a local classifier's single-digit milliseconds qualitatively different from a hosted API's round trip.

What false-positive rate should I expect in production?

Nobody can tell you from a benchmark. NotInject's 339 sentences were adversarially constructed to bait over-blocking, as its own users point out, so a score on it is a stress-test result rather than a traffic estimate. Measure on your own benign inputs; the flags you get there are the support tickets you will receive.

Further reading

On this wiki:

Sources: