Garak LLM Scanner Review: Research Tool or CI Gate?

Garak (Generative AI Red-teaming and Assessment Kit) is NVIDIA’s open-source LLM vulnerability scanner, released under Apache 2.0 and described in a framework paper by Derczynski, Galinkin, Martin, Majumdar and Inie. It was built for research and comprehensive model evaluation. The question a practitioner actually has is whether it translates into a production security testing workflow, which is exactly the question our AI security tool evaluation framework is built to answer.

The answer is: partially, with configuration work. This review covers what the tool is, how its architecture shapes the way you have to read its output, the CI pattern that keeps it in service, and where it is the wrong choice. Everything below is drawn from garak’s own repository and documentation; where a capability depends on version or configuration, that is called out.

The plugin architecture, and why it matters before you run anything

Garak’s design is the first thing to understand, because once the plugin types click, the rest of the tool follows. Work is organised into swappable component categories:

• Probes generate the interactions that test for a specific vulnerability. These are the attacks: dan (the DAN family of jailbreaks), encoding (base64 and similar smuggling), promptinject, leakreplay (training-data and replay leakage), and many more. Probes are where garak’s breadth lives.
• Detectors decide whether a given model output actually exhibits the failure mode a probe was hunting. A probe produces candidate failures; a detector judges each response.
• Generators are the interface to the model under test, covered below.
• Evaluators turn probe and detector results into assessment and scoring.
• Harnesses structure the overall workflow: which probes run against which generators, in what arrangement.
• Buffs transform or augment prompts (paraphrase, translation-style transformations) to expand coverage from a base probe set.

This is worth dwelling on for a practical reason. When a report fires and you want to know why, you trace it back detector to probe. When you want to change what is tested, you change probes, not detectors. Teams that treat garak as a black box get frustrated with it; teams that internalise the plugin model extend it.

Probe coverage

Garak’s probe library is extensive, and breadth is the main differentiator from every other scanner in the category. As of early 2026 it covers:

• Jailbreak probes: DAN variants, persona jailbreaks, encoding-based attacks
• Prompt injection probes: direct injection, instruction override patterns
• Data leakage probes: training data extraction, PII extraction
• Hallucination probes: factual accuracy and snowballed hallucination chains
• Toxicity probes: harmful content generation
• Model-specific probes: vulnerability patterns tied to particular architectures

Several of these attack classes are simply absent from commercial scanners. That is the reason to reach for garak even if you also pay for something with better reporting.

Model backends

A scanner is only useful against the models you actually run. Per the project, supported generators include Hugging Face (local models and the inference API), OpenAI, AWS Bedrock, Replicate, Cohere, Groq, LiteLLM (which itself fronts many providers), GGUF and llama.cpp for local quantized models, NVIDIA NIM endpoints, and a generic REST generator.

The generic REST generator is the escape hatch that matters most in practice. If your model sits behind an internal API gateway, you can usually point garak at it by describing the request and response shape in configuration, without writing Python. The LiteLLM generator broadens reach the same way.

What a run looks like

A minimal invocation names a model type and name and selects probes:

python -m garak --model_type openai --model_name gpt-4 --probes encoding

Running --probes all runs the entire probe library, which is thousands of test cases. That is the single most important operational fact about the tool: a full run is a research-grade sweep that can take hours to days, gated largely by the target API’s rate limits and latency. You scope it down for anything resembling routine testing.

The reports are genuinely useful

Output is built for triage rather than a pass/fail number. Per the project, a run produces detailed JSONL reports documenting each probing attempt (prompt sent, response, detector verdict), hit logs capturing the vulnerabilities discovered, and progress bars plus summary tables showing failure rates by probe and detector combination.

The hit log is the actionable artifact. It contains the specific inputs your model complied with when it should not have. Those strings are directly useful: they become candidates for fine-tuning data, regression test cases, or targeted guardrail rules. The JSONL format also means you can post-process results into whatever dashboard or ticketing system you already run, rather than being stuck with garak’s console summary.

Why “a hit” needs interpretation

A subtlety that trips up first-time users: a probe firing is not automatically a confirmed, exploitable vulnerability. Because probes and detectors are separate components, a hit means a detector judged a response to exhibit the failure mode the probe targeted, and detectors range from simple keyword matching to model-based classification. Two consequences follow.

First, false positives are possible. A keyword-based detector might flag a response that contains a triggering phrase inside a perfectly safe refusal (“I won’t help build a weapon”). Read the actual response in the JSONL alongside the detector’s verdict before treating a hit as a real failure. The hit log is a list of candidates to investigate, not a list of confirmed breaches.

Second, the choice of detector changes your numbers. The same probe output scored by a stricter or looser detector yields different success rates. Comparing garak success rates across different configurations, or against someone else’s published figures, is only meaningful if the detector setup matches. Within your own environment, holding the probe and detector configuration constant is what makes run-over-run comparison valid, and that regression signal is the thing you actually want.

The upside of the separation is flexibility: swap a noisy detector for a precise one without rewriting the attack, and reason about false positives at the right layer. The cost is that you have to understand the two-stage model to interpret results honestly. Teams that report raw garak “vulnerability counts” without this nuance tend to either over-alarm or quietly under-report.

The CI-gating pattern that works

Full garak scans are too slow for per-commit CI. The realistic pattern is a scoped, time-boxed subset as a gate, with the broad sweep on a schedule:

1. Curate a probe subset mapped to your actual threat model (the jailbreak and injection families if those are your concerns), small enough to finish in a tolerable window given your endpoint’s latency and rate limits. A curated 50 to 100 probe subset is typically feasible in 10 to 30 minutes.
2. Establish a baseline by running that subset against the current model and recording per-probe success rates. That is your known-good line.
3. Gate on regression, not perfection. Fail the build when a probe’s success rate rises above baseline plus a margin, rather than demanding zero hits. Most production models carry a non-zero baseline on some probes; what you care about is a model or prompt change reintroducing a failure you had closed.
4. Run the full library on a schedule, weekly or per release, out of the critical CI path, feeding newly surfaced hits back into the curated subset.

Trying to force the full sweep into fast CI is the most common way teams give up on garak. The scoped-gate-plus-scheduled-sweep split is what keeps it in service.

Operating it without drowning

The honest operational challenge is volume and runtime, not capability.

Scope probes to your threat model. Do not run all unless you are doing a quarterly research sweep.

Mind the rate limits. Runtime is dominated by API calls, so a scoped run against a slow or rate-limited endpoint can still take a long time. Consider running against a local model via the GGUF or Hugging Face generator for faster iteration during development.

Treat it as a floor, not a ceiling. Garak tests fixed probe variations and known attack patterns. It will tell you whether your model falls to documented attack classes; it will not generate novel, optimized adversarial inputs tailored to your specific model. For high-stakes systems it catches the obvious failures and frees a human red team to focus on the bespoke ones.

Pin and re-run for regression. A curated subset, run on a schedule or before model upgrades, answers the question that matters most between releases: did this update reintroduce a jailbreak we had previously closed?

Comparison to alternatives

PyRIT (Microsoft) is the closest comparison and the one most teams care about. Garak has the broader probe library and is oriented toward comprehensive research scanning; if the question is “what known attack classes does my model fall to, across the widest possible set,” garak wins on breadth. PyRIT has better workflow integration, result persistence, multi-turn representation, and a converter model that expands coverage from seed prompts; if the question is “let me run repeatable, scored, trackable assessments as part of my security process,” PyRIT wins on fit. They are complementary, not competitive.

Commercial scanners (Mindgard, Calypso, others) trade probe breadth for polished reporting and lower operational overhead. The right choice for teams without the engineering bandwidth to operate open-source tooling, or with compliance-ready reporting requirements.

Promptmap is simpler, faster and less comprehensive: a reasonable starting point for a lightweight CI integration before committing to garak’s complexity.

To put garak head to head with PyRIT, Rebuff, or Lakera Guard on the dimensions your team cares about, our interactive tool scorecard lets you weight detection depth, integration, and reporting and see how each reviewed tool ranks for your context.

Verdict

Garak is the right choice if you want the broadest probe library available in open source, you can tolerate a curated rather than full scan in CI, and you have the engineering capacity to interpret JSONL output and tune the probe set. Its plugin architecture is clean once learned, its backend coverage is excellent (including the generic REST escape hatch), and its hit logs are immediately actionable.

It is the wrong primary tool if you need a fast per-commit gate with no tuning, if you lack the bandwidth to configure and maintain a probe subset, or if you need auditable compliance reports out of the box. In those cases, run a scoped garak subset alongside other tooling rather than as the whole story.

One caveat on interpreting garak’s output: a scan result is a statement about your deployment, not about the underlying model. Model-level comparisons come from fixed datasets instead, and LLM security benchmarks compared explains why the two numbers are not interchangeable. For where a scan sits inside a wider assessment, see the AI security review checklist.

For how garak compares against PyRIT and Giskard on coverage and workflow fit, see our companion reviews of PyRIT and Giskard, or the wider landscape in best AI security testing tools 2026. For the operational reference on probe modules, generator configuration, and CI threshold parsing rather than the buying decision, bestllmscanners.com’s garak walkthrough goes deeper on the mechanics.