promptfoo vs Giskard

promptfoo generates adversarial inputs from red team plugins and strategies, and those plugins are mapped to the OWASP LLM Top 10, the NIST AI Risk Management Framework and the EU AI Act. The red teaming documentation presents these frameworks as support for systematic testing before deployment. In practice, you pick the plugins and strategies in a declarative config file, and the CLI produces attack inputs that run against your target. Because promptfoo runs locally, the evals execute on your machine and talk directly to the model, so the prompts and responses stay inside the environment you control. Confirm with promptfoo which plugins cover the categories your auditors ask about, and check the mapping against the framework controls you need to show, since a plugin name does not prove coverage.

giskard-scan works from a plain-language description of the agent rather than a fixed plugin list. You describe what the agent does, and the vulnerability scan generates an adversarial suite covering prompt injection, jailbreaks, harmful content and OWASP LLM Top 10 threat categories. This suits a team that can state its agent's purpose clearly but has no catalog of attacks yet. The trade-off is that the generated suite reflects the description you wrote, so review the generated cases before you treat a clean scan as coverage. Ask Giskard which categories the scan produces for your agent type and how the suite is regenerated when the agent changes.

giskard-checks judges responses with explicit checks, written in Python. Built-in checks include string and regex matching, semantic similarity and LLM-judge checks such as Groundedness and Conformity. The default judge model is openai/gpt-4o-mini, so every LLM-judge check sends content to that model unless you change it. Judge calls are a recurring cost that grows with suite size and run frequency, and you should estimate them against your own provider pricing and test volume before you schedule a scan in CI. Also confirm that the judge model is acceptable under your data handling rules, because the judge sees the prompts and outputs under test.

Self-hosted promptfoo has no built-in authentication or SSO, and its documentation lists RBAC and SSO among the things its self-hosted SQLite deployment does not provide. If your security standard requires named logins, SSO through your identity provider, or role-based access to evaluation results and red team reports, the self-hosted server alone will not meet it. SSO, teams-based access control and custom roles appear in the Enterprise tier, and the On-Premise option runs that Enterprise functionality on your own infrastructure. Before you shortlist promptfoo for a team that needs SSO, ask the vendor in writing which Enterprise edition includes SSO, how it is configured for your identity provider, and whether it runs inside your network.

Giskard extends through Python code rather than a hosted control plane. You wrap the model under test, whether that is an LLM, a black-box agent or a multi-step pipeline, and then write checks in Python using the giskard-checks API, including custom checks where the built-in string, regex, semantic similarity and LLM-judge checks do not match your policy. Identity around the wrapped target is your responsibility: the credentials your wrapper uses to call the agent, the way test scenarios and their results are stored, and who can run a scan are decisions your engineering team makes and documents. The v2 Giskard Hub is not planned for v3, so do not assume a managed multi-user console is part of the v3 path.

Confirm the current access controls of both options before you decide. For promptfoo, check the Community and Enterprise pages and the self-hosting documentation for the exact authentication, SSO and RBAC features in the edition you plan to buy. For Giskard, check the giskard-oss README for any authentication or access features in the release you pin, and test how your wrapper stores API keys for the judge model and the target. Record the answers in your architecture review, because a tool that depends on your own wrapper for identity will need the same review as any other internal service.

For promptfoo, the rollout is mostly configuration and pipeline wiring. The team writes a declarative config that names the target application, the provider credentials and the red team plugins and strategies to run, then adds a job to the CI system that runs the scan on each change. Provider configuration is the first decision: which model endpoints need keys, and whether the target is called directly or through a gateway. A self-hosted server becomes a question only when results must be shared. The open-source app stores data in a local SQLite database that cannot be shared across replicas, has no RBAC and no built-in authentication or SSO, and its documentation says it is not recommended for production. If several reviewers need a shared results view, confirm with the vendor whether the Enterprise tier or your own authentication layer fills that gap before you deploy. The self-hosting documentation lists the deployment options.

For Giskard, the work starts with the runtime. Giskard v3 requires Python 3.12 or newer, so that interpreter must exist in CI images and developer environments before you run pip install giskard with the extras you need, such as [scan] or [openai]. Two packages matter: giskard-checks, which holds the scenario API and built-in checks, and giskard-scan, which runs the vulnerability scan. Selecting checks means deciding which ones are deterministic, such as string, regex and similarity checks, and which depend on an LLM judge. Wrapping the target is the other large task. The agent, black-box endpoint or multi-step pipeline must be exposed as something Giskard can call, and that code belongs to the application team, so schedule it with them. Telemetry is optional and the giskard-oss repository says it never includes prompts or outputs. Still, set DO_NOT_TRACK=1 or GISKARD_TELEMETRY_DISABLED=1 in regulated environments unless your policy team has approved it.

Projects usually run long in four places. The first is agent scope. A vulnerability scan generates suites from a plain-language description of the agent, so a vague description produces a vague test set. Write down the tools, data sources and permitted actions before the first run. The second is judge choice. The default judge in Giskard v3 is openai/gpt-4o-mini, and LLM-judge results can shift when the judge changes, so pin the judge model and record it with every result. The third is false positives. Someone must review each flagged attempt, and that review recurs with every scan and grows with the number of attack categories. The fourth is access control. Confirm what each open-source setup provides for per-user permissions on findings, who may change checks, and where API keys are stored, because gaps here usually surface after the pipeline is already gating releases.