Choose an AI red teaming tool around the test work your team intends to keep. For developers who want an application-specific configuration and recurring security checks, Promptfoo Community is a useful starting finalist. Compare Microsoft PyRIT when the job requires a programmable attack campaign, conversation state and custom scoring. NVIDIA garak provides a different entry point: a scanner that probes a model or connected endpoint and produces findings for investigation.
This guide is for an engineering or security lead at a small company building a retrieval-augmented generation (RAG) application or a tool-using agent. It assumes access to the application's test endpoint, someone who can maintain an integration, and an approved test environment. A solo developer can use the same open-source routes at smaller scope. A solo business merely subscribing to an AI service should first examine that service's controls and evaluation evidence; it does not automatically need its own scanner.
AI red teaming deliberately tests whether a system can produce unwanted behavior under adversarial conditions. It complements quality evaluation and runtime safeguards. If the principal question is answer accuracy or regression quality, start with the broader LLM evaluation tools guide.
Decide which system the results should describe
A test against a model API describes that configured target. It does not, by itself, describe the permissions, retrieved documents or tool actions of your complete application. Before choosing software, specify whether the target is a base model, a chat endpoint, or the application with its surrounding context and permitted actions.
For example, a hypothetical internal assistant might answer questions from synthetic employee documents and request an approved workflow action. The buying requirements are then connecting the real application interface, preserving conversation state where relevant, and checking an explicit allowed-behavior rule. A generic refusal score cannot substitute for checking the resulting action and authorization boundary.
We selected the tools below for documented target integration, adversarial testing, inspectable results and a defensible operating model. The comparison uses official material checked on 9 November 2026. We did not run scans, measure detection rates or test their interfaces. Product capabilities are documented; the fit recommendations are editorial judgments.
Application configuration or programmable campaign?
Promptfoo: retain a repeatable application test configuration
Promptfoo's red-team quickstart describes providing application details, configuring a target, selecting vulnerability plugins and attack strategies, saving the configuration, running the scan and examining individual results. It supports HTTP endpoints and custom Python or JavaScript connections, including RAG and agent workflows. The local scanner can reach endpoints accessible from its machine or network.
That makes Community a sensible first configuration for a small application team that wants the testing definition alongside its code. The documented prerequisites include Node.js 22.22.0 or later and an accessible target. A developer must map the application's request and response correctly; a business owner cannot assume that pasting a model name tests the complete product.
The important qualification is data flow. Promptfoo's data-handling documentation separates target evaluation, test generation and result grading. Without configured API credentials or a usable supported login, hosted generation can receive application purpose and plugin settings; hosted grading receives the test prompt, target response and criteria. Some plugins require hosted inference. Running the scanner locally is therefore not the same as keeping every operation inside your network.
Choose Promptfoo Community over building a PyRIT campaign when its configuration, supported connections and permitted inference path meet the requirement. Compare PyRIT when you need to compose the campaign's components yourself. If centralized collaboration, SSO or isolated infrastructure is mandatory, price the qualifying Enterprise or Enterprise On-Prem configuration instead of assuming those controls accompany the free CLI.
Microsoft PyRIT: compose the experiment your application needs
PyRIT's current documentation describes a command-line scanner, the CoPyRIT graphical interface and an extensible Python framework. It supports single-turn and adaptive multi-turn testing, custom targets and configurable scoring. It is not limited to scripts, and the current repository is under Microsoft's GitHub organization; the older Azure repository is archived.
For a Python-capable security engineer, the differentiator is control over targets, attacks, scorers and stored conversation evidence. The HTTP target guide shows defining a request and a response-parsing callback. The setup process includes endpoint credentials, initializers and a memory configuration. SQLite and Azure SQL are documented memory choices; an in-memory configuration is also available.
An ordinary campaign connects the approved application target, runs the selected attack strategy, scores responses and reviews the saved conversation and result. Maintaining the target adapter, scoring logic, credentials and evidence store remains engineering work. The latest documentation follows development changes, so match it to the installed version rather than treating a copied notebook as a permanent interface contract.
Choose PyRIT over Promptfoo when custom orchestration and scoring materially change the assessment and you can maintain that code. Choose Promptfoo when a declarative application test configuration is sufficient. PyRIT's MIT license removes a toolkit license charge; it does not supply a hosted enterprise service, pay model-provider invoices or establish that every configured dependency runs locally.
NVIDIA garak: begin with an inspectable scanner
garak is a free, Apache-2.0-licensed LLM vulnerability scanner. Its current repository describes static, dynamic and adaptive probes, with support for model providers and REST-accessible targets. Avoid the simplistic claim that it only runs a fixed list of prompts.
The documented workflow installs a command-line package, selects the target interface and model, chooses probes and examines detector results. Some generators require API credentials. A Python environment and a person who can interpret the target's outputs are practical prerequisites. The reporting documentation distinguishes screen output, a detailed report log, a hit log and debugging output.
Choose garak when the immediate purchase decision is whether an existing endpoint exhibits known unwanted behaviors and the team wants scan artifacts to investigate. Compare PyRIT when the campaign itself needs custom conversational orchestration; compare Promptfoo when maintaining an application-oriented configuration is the priority. REST connectivity establishes a connection method, not automatic coverage of every state transition or tool action in an agent.
A scanner can complement an existing evaluation suite without replacing it. If the team already retains useful regression cases and only needs a focused security sweep, adding that narrower scan may be sufficient. No detection ranking between these tools is claimed here.
Compare one monthly workload, including the model calls
Use this hypothetical purchase scope for all options: two technical maintainers, one staging application endpoint, four campaigns a month, and a planned ceiling of 2,000 target requests per campaign. That is 8,000 target requests, plus a separate 1,600-request retest allowance: 9,600 total. This is a budget envelope, not a promise that different attack strategies generate equivalent tests or stop at identical counts.
| Configuration | Same workload purchase | Documented cost boundary | Operating and data responsibility |
|---|---|---|---|
| Promptfoo Community | Local scanner and custom application integration | $0 software tier; 10,000 probes/month published allowance | Track actual probes; qualify generation/grading path and pay applicable target or chosen-provider costs |
| Microsoft PyRIT | Open-source toolkit with application target, scoring and memory | $0 toolkit license under MIT; external services separate | Maintain campaign code, model endpoints, evidence storage and access |
| NVIDIA garak | Open-source scanner with suitable target generator and probes | $0 software license under Apache 2.0; external services separate | Maintain target configuration, probe selection, compute and findings review |
| Enterprise platform proposal | Same target/workload plus shared reporting and required controls | Promptfoo Enterprise custom-priced; Giskard Hub numeric amount not verified | Itemize users, target/campaign allowances, inference, hosting, support and implementation |
Promptfoo's pricing defines a probe as a request to the target. Its inference guidance says internal generation and grading calls do not count as probes, while probe limits still apply with your own inference. The scenario fits the published Community allowance only if actual counted requests stay within it. Adaptive turns, repeated outputs, retries and additional targets can change the real workload.
For PyRIT and garak, record actual target calls and any attacker or judge-model usage separately. There is no verified paid seat minimum or billing commitment for these open-source configurations. Provider prices, hosting, storage, engineering time and support are additional purchasing decisions. A zero license subtotal cannot establish the lowest operating cost.
Use a common cost sheet: software subscription plus target-model spend plus attack/judge inference plus runner and storage costs plus setup and recurring maintenance. Record each model's input/output usage at its contracted rate. No token conversion or total dollar bill is supplied because target responses, attack paths and model choices are unspecified. Do not compare 9,600 target calls with 9,600 entire multi-turn conversations.
Giskard Hub: bring findings into a shared review workflow
Giskard Hub belongs on an enterprise shortlist when security engineers and business reviewers need a shared testing workspace. Its Open Source versus Hub comparison places continuous red teaming, team access, role controls, scheduled evaluations and SSO in Hub. Those are not entitlements supplied by the free Giskard Python library.
The documented Hub workflow creates a project, configures an agent endpoint, runs vulnerability scans, creates scenarios, annotates checks and evaluates results. Chat and Structured modes use different input/output shapes. Authenticated or nonstandard endpoints can require onboarding assistance. This is a concrete integration task, not evidence of instant setup.
For a large organization, compare Giskard Hub with Promptfoo Enterprise when review and collaboration are material. Prefer evaluating Hub first when joint scenario annotation and business-failure testing are central; evaluate Promptfoo Enterprise first when shared security configurations extend an existing Promptfoo workflow. Require the same target, maintainers and campaign workload in both proposals.
Promptfoo documents managed SaaS and Enterprise On-Prem with a dedicated runner; its isolated deployment is a separate purchase. Giskard documents an on-premise consultation route, but no numeric price was verifiable from its accessible pricing response. Deployment terms, data location, retention, export, support commitments, minimum purchase and any inference charges need configuration-specific proposals. These are unresolved procurement terms, not verified missing capabilities. Neither enterprise purchase is awarded by this guide.
Keep the finding useful after the scan
For the small application team, the first decision remains Promptfoo Community versus PyRIT: maintain a repeatable configuration or maintain a programmable campaign. Add garak when a focused scanner answers a different question. Trial the chosen connection with synthetic fixtures, inspect request/response mapping, and review whether the reported behavior violates the application's actual policy before increasing scope.
Keep a compact finding record containing the target version, relevant context, conversation or input, observed output/action, scoring rationale and human disposition. This is a recommended practice, not an exercise we performed. Retain confirmed cases as regressions alongside legitimate tasks; a system that rejects every useful request has not met the business requirement.
Recurring ownership includes dependency updates, target-adapter maintenance, scorer review, provider budgets, access and evidence retention. Paying for an enterprise workspace becomes worthwhile when documented collaboration, deployment or support requirements would otherwise need to be built and operated internally. Staying with an existing scanner and a maintained regression set can be sufficient for a narrow application.
Judge the business case by the testing and review work the team can sustain. Compare the proposed subscription and operating costs with actual maintenance and report-preparation effort, keeping released staff capacity separate from cash expenses that truly disappear. No scan count, framework mapping or vendor grade guarantees that an AI application is safe.
