Promptfoo Alternatives for LLM Red Teaming

People go looking for a promptfoo alternative for a specific reason: on 9 March 2026 OpenAI announced an agreement to acquire Promptfoo. The maintainers said they would continue to maintain the open-source suite, and the repository is still MIT-licensed today, so nothing in it broke. But a red team harness is the thing that tells you whether a foundation model is safe to ship, and it is a defensible governance position that the harness should not be owned by a foundation-model vendor.

Vendor neutrality is only one of three reasons people leave. The other two are scope and attack depth, and they point at different replacements. Picking on the wrong axis means migrating a config file and ending up with worse coverage than you started with.

Be clear about what promptfoo is good at

Promptfoo began as an LLM evaluation CLI and grew a red team module on top. Its strength is regression testing in CI: define a target, define the behaviours you care about, get a diff-able pass/fail report on every pull request or model swap. Nothing on this page beats it at that specific job, and the licence and the public repository are unchanged.

If your only concern is governance rather than capability, understand what you are trading before you move. The honest framing of the three-way comparison it sits in is in best LLM red team tools.

Reason one: vendor neutrality

If the objection is that your safety evaluation of OpenAI models will run on tooling owned by OpenAI, the substitutes are the two large open-source projects with different corporate parents.

garak, maintained by NVIDIA under Apache 2.0, is the broadest probe library in the open-source ecosystem — a large catalogue of attack modules covering DAN-lineage role-play, encoding and obfuscation, toxicity elicitation, training-data extraction and hallucination probes. Its architecture separates probes (which generate payloads), detectors (which score responses) and buffs (which transform payloads in bulk, for example wrapping an entire probe category in Base64). That composability is why it is the natural home for the encoding and obfuscation families: you add an encoding layer rather than rewriting a probe set.

What garak does not do is adapt. Every probe fires a fixed or template-generated payload. Vulnerabilities that only surface through conversation state are invisible to it.

PyRIT, maintained by Microsoft under MIT, is the orchestrator-shaped answer. Instead of a fixed catalogue it drives an attacker model that generates prompts, reads the target’s response and iterates, with a judge scoring whether the target actually complied. That is the machinery behind crescendo and multi-turn escalation and, more generally, behind the iterative black-box attacks described in automated jailbreak attacks.

PyRIT’s cost is the attacker model. You need a capable one, and if data residency rules forbid sending your prompts to a hosted attacker, you need to stand up a local one that is strong enough to be a useful adversary. Its static probe coverage is also thinner than garak’s.

Neither project is vendor-free in the abstract sense — one is NVIDIA’s and one is Microsoft’s — but neither vendor sells the models most teams are evaluating.

Reason two: scope mismatch

The second group of leavers do not want a narrower security tool. They want one harness that covers hallucination, bias, PII leakage and jailbreak resistance in a single run, because that is what their compliance mapping asks for.

DeepTeam is the closest structural match to promptfoo’s red team module on the application-testing axis: Python-first, Apache 2.0, with a catalogue the project puts at 50-plus vulnerability types (data privacy, responsible AI, security, safety, business and agentic categories) and 20-plus single-turn and multi-turn attack methods. The feature that distinguishes it is framework mapping: you select OWASP Top 10 for LLMs 2025 or the NIST AI RMF and it resolves that framework to the vulnerabilities and attacks that belong to it. If the deliverable is a control-mapped report rather than a CI gate, that resolution step is the thing you are buying.

Giskard comes at the same surface from the ML-engineering side. Its LLM scan auto-generates adversarial test suites over the OWASP LLM Top 10 categories — prompt injection, harmful content, stereotypes, misinformation — and it carries RAG-specific evaluation and test-set generation, which none of the others do well. Read the “one tool for classical ML and LLMs” pitch carefully, though: the tabular scan for performance, bias and robustness issues is a v2 capability that the project describes as no longer actively maintained and not planned for the v3 migration. Choose Giskard for the LLM and RAG scanning, not on the assumption that your existing tabular model risk process comes with it.

Both are broader and shallower on pure jailbreak depth than garak or PyRIT. That is the trade, and it is the right trade when the audience for the output is a risk committee.

Reason three: attack depth

The third group is not leaving over governance at all. They ran promptfoo’s red team module, got a green report, and do not believe it.

That instinct is usually correct, and it is not a criticism of any one tool. Automated red team suites test the attack classes they ship. If a class is absent from the catalogue, a clean run says nothing about it. Which classes you need is a question the jailbreak taxonomy answers before any tool selection does.

For depth, the honest answer is not a different product but a research harness. HarmBench and JailbreakBench are standardised evaluation frameworks with fixed behaviour sets and published judges, built so that attack methods can be compared to each other rather than to a vendor’s internal baseline. They are heavier to run and they are not CI tools. What they give you is a number that means the same thing as somebody else’s number, which no product-shaped scanner can offer. The reason that matters is set out in how jailbreak benchmarks measure success.

Side by side

Tool	Maintainer	Licence	Primary axis	Adaptive / multi-turn	CI fit
promptfoo	Promptfoo (OpenAI acquisition announced Mar 2026)	MIT	CI regression eval	Limited	Strongest
garak	NVIDIA	Apache 2.0	Static probe breadth	No	Good, CLI exit codes
PyRIT	Microsoft	MIT	Adaptive orchestration	Yes, core capability	Weak, campaign-shaped
DeepTeam	Confident AI	Apache 2.0	Application risk breadth	Partial	Good
Giskard	Giskard	Apache 2.0	ML + LLM risk scanning	Partial	Moderate
HarmBench	Center for AI Safety	MIT	Comparable research ASR	Method-dependent	No
JailbreakBench	Academic consortium	MIT	Comparable research ASR	Method-dependent	No

Licences and maintainers are as published in each project’s own repository, checked in August 2026 and linked in the sources below. Capability columns describe what each tool is architecturally built to do, not a ranking.

Migrating: what does not come with you

Three things break on the way out, and all three are usually discovered late.

Your judge changes, so your numbers change. Promptfoo’s pass/fail verdicts come from its own judge configuration. garak’s detectors, PyRIT’s scorers and HarmBench’s classifier will disagree with it, and with each other, on the same transcripts. A drop or jump in your headline score immediately after migration is far more likely to be the judge than the model. Re-baseline before you read anything into a trend line.

Your behaviour set changes. Test cases generated from one tool’s harm taxonomy do not map cleanly onto another’s. Export the behaviours you actually care about as plain text and re-import them, rather than assuming category names line up.

CI ergonomics are not a given. Promptfoo is unusually good at being a build step. garak has usable exit codes and parseable reports. PyRIT is campaign-shaped and fits a pre-release gate rather than a per-commit one. Budget for the difference instead of trying to force an orchestrator into a pull-request check.

The pragmatic answer

Most teams that go looking for one replacement end up running two tools, because the tools are not substitutes for each other.

A defensible minimum stack looks like: garak on every model version for static breadth, PyRIT before any significant release for adaptive and multi-turn depth, and one benchmark harness run occasionally so your internal numbers can be anchored to a published one. Whether promptfoo stays in that stack as the CI layer is a governance decision, not a technical one — and it is worth deciding it explicitly rather than by default.

Whatever the harness, findings still have to be triaged and disclosed. The norms for that are in responsible disclosure norms for LLM jailbreaks, and the detection side of the same problem is in how to detect jailbreak prompts.

What to do

• Write down which of the three reasons applies to you before shortlisting. Governance, scope and depth point at different tools and the wrong choice costs coverage.
• Re-baseline every score after any tool change. Cross-tool ASR comparisons are meaningless without a common judge and behaviour set.
• Keep a static scanner and an adaptive orchestrator. One tool covering both well does not currently exist in open source.
• Check licence and maintainer against your own procurement constraints rather than against a blog post. All of these are public repositories.
• Browse the technique classes any harness should be exercising against your system in the Jailbreak Index, which links each record to its primary disclosure.