Garak vs PyRIT: Probe Scanner or Red Team Campaign Framework

A model is heading toward production, and someone has asked the security team a simple question: is it safe to ship? The two open source names that come up first are Garak, from NVIDIA, and PyRIT, from Microsoft. Both generate adversarial input against a generative AI system, both score what comes back, and both run entirely on infrastructure you control. So they land on the same shortlist, and a reader skimming two READMEs could reasonably conclude they are interchangeable.

They are not. Garak is a scanner: you point it at a model endpoint, it fires a catalog of prebuilt probes, and detectors mark the hits. PyRIT is a framework: you write Python that assembles targets, converters, orchestrators and scorers into a campaign aimed at objectives you define, often over many conversational turns. One gives you a broad reading with little setup. The other gives you depth in exactly the places you choose to dig, provided someone does the digging. Everything below follows from that difference.

The short answer #

Pick Garak if you need a repeatable baseline on a model or guardrail configuration and the person running it is a security or ML engineer with an afternoon, not a dedicated red teamer. Pick PyRIT if you have a red team or AI safety function that needs to test specific harms against a specific application, including attacks that unfold across a conversation. Running both is reasonable in a mature program: Garak as the regression check whenever the model, system prompt or filter changes, PyRIT as the deeper campaign before a significant release. If you have to choose one and nobody owns AI red teaming, start with Garak.

How they differ #

Detection approach #

Garak works like a fuzzer. Each probe is a family of adversarial prompts with a purpose: jailbreaks, instructions hidden in retrieved text, encoding tricks, training data regurgitation, toxic output, invented package names. Each probe pairs with detectors that range from string and regex matching to classifier models. Most of what it sends is a prepared payload, and the breadth of the catalog is the point.

PyRIT starts from an objective instead of a payload list. Converters rewrite a seed prompt through encodings, translation, character substitution or a fictional frame. Multi turn orchestrators then drive a conversation, using an attacker model that adapts to refusals, escalates gradually, or branches on partial success and prunes dead ends. Scorers, frequently a model judging against a rubric, decide whether the objective was met.

This axis favors Garak for coverage across many known failure classes, and PyRIT for finding whether a determined adversary can reach one particular outcome.

Who operates it #

Garak is a command line tool. A security engineer or an ML engineer can install it, name a generator such as an OpenAI compatible endpoint, a Hugging Face model, an Ollama instance or a REST target, pick probe families and read the results the same day. Extending it means writing a probe or detector class, which is contained work.

PyRIT expects a Python developer who understands its abstractions and has at least one model approved for use as attacker and judge. You wire the target yourself, write or choose the objectives, and interpret results from its memory store rather than a report. It belongs to a red team or AI safety group, and without a named owner it tends to get run once from the samples and then forgotten.

This axis favors Garak for teams without dedicated AI red team capacity, and PyRIT for teams that have it and want to build on it.

What it actually tests #

Garak tests the model or the endpoint you point it at. That is useful when choosing a base model, comparing guardrail settings, or catching a regression after a prompt change. It does not naturally exercise your retrieval path, your tool calls or your session state, and that is where deployed exposure usually sits.

PyRIT's target abstraction can wrap an application with its own API in front of the model, so a campaign can go after the thing users actually touch. Success can be defined in your terms: extract a specific record type, trigger a specific tool call, get past a specific policy. Generic probes cannot express those objectives.

This axis favors PyRIT whenever the risk lives in the application rather than the model.

How results feed a release decision #

A Garak run produces hit rates by probe and a log of the exact prompts and completions that succeeded. That shape suits a gate: compare against the last accepted baseline, investigate any probe family that moved meaningfully, and attach the reproducing prompts to the ticket for the model owner. Because output is nondeterministic, small movements between runs are noise, and a threshold set too tight will fail builds for no reason.

A PyRIT campaign produces a queryable record of every exchange, the converters applied and the score assigned. That shape suits a written assessment: here is the objective, here is the conversation that reached it, here is what the judge concluded and what a human confirmed. It informs a go or no go discussion with product owners rather than an automated gate, because multi turn campaigns are slow and the scoring needs review.

This axis favors Garak for continuous regression evidence and PyRIT for the pre release sign off conversation.

Where each one falls short #

Garak's weakness shows up once the novelty of the first report wears off. Detectors are heuristics, so string matching over reports and classifiers bring their own bias, and someone has to triage the hit log by hand every time. The probe corpus is public, which means a model or filter can be tuned to pass it, and a clean run then reads as stronger evidence than it is. Teams that report a Garak score upward as "the model is safe" are making a claim the tool does not support, since it never touched the retrieval and tool layers where the real incidents happen.

PyRIT's weakness is the engineering tax. It is a framework, not a product: you write Python, maintain your own target wiring, and read raw results without a reporting interface. Its interfaces move, so automation built on it needs upkeep. Model based scoring adds false positives and a second source of nondeterminism on top of the target's. Attack quality depends on the attacker model you supply and how sharply you state objectives, so two teams running the same code can reach different conclusions, and a vague objective yields a campaign that proves nothing.

Pick Garak if / Pick PyRIT if #

Pick Garak if:

• You are choosing between candidate base models and want the same probe suite run against each.
• You need a check that reruns whenever the system prompt, guardrail configuration or model changes.
• Your AI security work is owned by a general security or ML engineer rather than a red team.
• You want reproducing prompts you can hand directly to a model owner.
• You need every prompt to stay on infrastructure you control and want a working setup the same day.

Pick PyRIT if:

• You have a red team or AI safety group with time allocated to building campaigns.
• The harms you care about are specific to your application, such as leaking a particular data class or triggering a particular tool.
• You need to test whether gradual, multi turn pressure gets past refusals that single prompts do not.
• The system under test is an application with its own API, not a bare model endpoint.
• The output is a written assessment that informs a release decision with product and risk owners.

Frequently asked questions #

Can Garak replace a human red team? No. It gives broad, repeatable coverage of known failure classes, and that frees a red team to spend its time on the attacks a catalog cannot express. Treat it as the floor, not the ceiling.

Is PyRIT usable without an AI red team? Technically yes, practically rarely. The framework assumes someone who will define objectives, maintain target wiring and review judged results. Without that owner it tends to stall after the first sample run.

Should either tool be a hard CI gate? Garak can be, with care: gate on meaningful movement against an accepted baseline, not on any single hit, because runs vary. PyRIT campaigns are too slow and too dependent on model judges to gate a build, so keep them in the pre release assessment.

Do both tools need a model beyond the one being tested? PyRIT generally does, for the attacker role and often for scoring. Garak can run with lightweight string detectors alone, though some of its detectors are classifier models, so check which detectors your chosen probes use.

Full profiles: Garak and PyRIT.