garak, PyRIT and promptfoo are the three open-source AI red teaming tools most teams evaluate first, and they answer different questions. garak scans a model for known weaknesses with a large library of canned probes. PyRIT is a framework for scripting your own attacks, including multi-turn campaigns. promptfoo tests an application endpoint against configurable attack plugins and runs comfortably in CI. Pick by what you are testing: the model, a bespoke attack, or the shipped application. For AI agents, all three share one blind spot: they see text going in and out, not the tools, credentials and permissions that turn a bad output into a bad action.
What each tool is built for
garak: a scanner for the model
garak, maintained by NVIDIA, works like a network vulnerability scanner pointed at an LLM. You choose a generator (the model or endpoint), a set of probes (prompt injection, jailbreaks, encoding tricks, data leakage, toxicity and more), and detectors score each response. The output is a report of which probe families got through.
Its strength is breadth with little setup. One command gives you a baseline across many known attack classes, which is useful when you compare candidate models or check a new model version before rollout. Its limit is the same breadth: the probes are generic. They do not know your system prompt, your users or the actions your application can take.
PyRIT: a framework for building attacks
PyRIT, from Microsoft's AI Red Team, is a Python library rather than a scanner. Its building blocks are targets (what you attack), converters (transformations such as encodings, translations or rephrasing), scorers (judging whether an attack succeeded) and memory (a stored history of attack conversations). It includes multi-turn orchestration where an attacker model adapts its next message to the target's last reply, the pattern behind gradual-escalation attacks covered in multi-turn jailbreaks and Crescendo attacks.
Its strength is control. A red teamer who understands the application can encode a realistic adversary and re-run it. Its cost is that you are writing code: PyRIT gives you parts, not a finished test plan.
promptfoo: a test runner for the application
promptfoo started as an evaluation tool and added a red team mode. You declare the target (often an HTTP endpoint for your app), the plugins (categories of harm or weakness to probe) and strategies (how payloads are delivered, such as jailbreak wrappers or encodings) in a config file. It generates adversarial test cases, runs them and reports failures. Because it is config-driven and runs from a CLI, it fits into pull-request pipelines next to ordinary evals.
Its strength is that it tests what users actually reach: the application with its prompts, retrieval and output handling in place. Its limit is that generated attacks are only as specific as the context you give it.
Side-by-side comparison
| garak | PyRIT | promptfoo | |
|---|---|---|---|
| Primary target | Model or LLM endpoint | Any target you wire up | Application endpoint or prompt |
| Interface | CLI, plugin probes | Python library | CLI and YAML config |
| Attack style | Large catalogue of single-shot probes | Scripted, adaptive, multi-turn | Generated cases from plugins and strategies |
| Best moment to use | Model selection, version upgrades | Deep manual engagements | Every build, as a regression gate |
| Effort to first result | Low | Medium to high | Low to medium |
| Knows your app context | No | Only what you code in | Only what you configure |
| Sees tool calls and permissions | No | No, unless you build it | No, unless your endpoint exposes them |
None of these is better in general. A mature programme often uses garak when a model changes, promptfoo on every release and PyRIT for scheduled deep-dive exercises.
The gap: agents act, scanners read
All three tools judge success by inspecting text: did the model refuse, leak, or comply? For a chatbot that is the right question. For an agent it is half of it. An injected instruction that makes an agent say something harmful is a content failure. The same injection that makes an agent call send_email with a customer list attached is a data breach, and the transcript may look harmless.
Agent-level red teaming needs three things the scanners do not supply:
- Tool and permission context. Which tools can the agent call, with which scopes, on whose behalf? A successful injection against an agent with read-only tools is a low finding. The same payload against an agent holding payment or deployment tools is critical. See how to threat model an AI agent for a way to enumerate this.
- Action-level success criteria. The scorer should ask "was a forbidden tool called, or a forbidden argument passed?", not only "did the output contain bad text?"
- Indirect input paths. Agents read web pages, documents, tickets and tool results. Payloads planted in those sources are the realistic attack, and most test setups only send payloads through the user prompt.
You can extend PyRIT or promptfoo to cover this, for example by pointing them at a staging agent whose tool calls are captured, then scoring on the captured calls. That is work worth doing. The playbook in red teaming AI agents covers the scenarios to build.
Turning findings into controls
A red team report that sits in a folder changes nothing. Each finding should end in one of three places:
- A policy change. A guardrail that would have blocked or redacted the payload, a tighter tool scope, or an approval step on the risky action.
- A regression test. The successful attack becomes a fixed case in your evaluation set, so a model or prompt change cannot quietly reopen it. See eval datasets and golden sets for agents.
- An accepted risk. Recorded with an owner and a review date, not silently ignored.
Controls that live outside the model matter here. A prompt fix can regress on the next model upgrade; a tool scope or a guardrail on the connection does not depend on the model behaving.
Checklist: choosing and running AI red teaming tools
How Praesidia fits
Praesidia does not replace these tools; it supplies the agent context they lack and the place their findings land. Discover: the agent inventory shows which agents exist and what they connect to, which tells you what to test first. Secure: guardrails with block, redact and warn dispositions and scoped connections turn findings into configuration that persists across model upgrades, and Praesidia's red-team module checks synthetic instructions against your enabled organisation-wide defences. Prove: guardrail evaluations and tool calls that pass through Praesidia are recorded with the agent attributed, so an exercise can be reconstructed from what was actually seen, and evaluation datasets let successful attacks be re-run as a regression suite. For the broader risk map, see the OWASP Agentic AI Top 10 guide.