promptfoo Explained: LLM Evals and Red Teaming from a YAML File, in CI, and After the OpenAI Deal
How promptfoo runs LLM evaluations and red-team tests from promptfooconfig.yaml, how plugins and strategies generate adversarial tests, how to gate pull requests with the GitHub Action, and what OpenAI's 2026 agreement to acquire it means for users.
- MADE BY
- promptfoo (agreed acquisition by OpenAI, announced March 2026; open source, MIT)
- TYPE
- Open source
- CATEGORIES
- AI red teamingModel scanning
- ALSO KNOWN AS
- ModelAudit (promptfoo's model file scanner)
- FACTS CHECKED
- 13 November 2026 against the official documentation
promptfoo treats LLM security testing like unit testing: write prompts, providers and assertions in a YAML file, run them as a matrix, and fail the build when results get worse. It also generates red-team tests. Because it lives naturally in CI, it often comes up as the answer to "how do you stop a prompt change from quietly making the product less safe?"
What it is
promptfoo is an open-source command-line tool and library, licensed under MIT and distributed through npm. On 9 March 2026 promptfoo announced that it had agreed to be acquired by OpenAI and said it would remain open source; its README now says it is "now part of OpenAI". It has two main uses:
- Evaluations: run a set of prompts against one or more models and grade the outputs with assertions.
- Red teaming: generate adversarial test cases from plugins and strategies, run them and grade the responses.
In March 2026 promptfoo also open-sourced ModelAudit, a static scanner for model files.
How it works
Config
purpose, target, plugins
Generate
plugins x strategies
Run
against your target
Grade
assertions, rubric
Report
by category and severity
An evaluation config has prompts (templates with {{variables}}), providers (the models or endpoints), and tests, each with vars and assert entries. Assertion types range from simple string checks (contains, icontains) to javascript functions, cost and latency limits, and llm-rubric, where another model grades the answer.
A red-team config adds a redteam section:
purposedescribes the application, so generated attacks fit it.pluginssay what to test, such as personal data leakage or indirect prompt injection, or a framework preset such asowasp:llm.strategiessay how to deliver each test, such as basic, encoded or multi-turn.numTestssets how many cases to generate per plugin.
How to use it
Day one: an evaluation you can rerun
npm install -g promptfoo
promptfoo init --example getting-started # writes promptfooconfig.yaml
promptfoo eval
promptfoo view # browse results
Add a few security assertions to your existing tests, such as "the answer never includes the internal discount code" or "the assistant refuses to reveal another customer's order", so security checks run alongside quality checks.
Week one: generate a red-team suite
promptfoo redteam init --no-gui # or: npx promptfoo@latest redteam setup
promptfoo redteam run # generate then evaluate
promptfoo redteam report
Write the purpose carefully. A vague purpose produces generic tests; a specific one ("a support assistant that can look up orders by order ID for the signed-in customer only") produces tests about the risks your app actually has. Point the target at a test environment with test data, never production customer data.
Every day: gate pull requests
The promptfoo/promptfoo-action GitHub Action runs evaluations on a pull request and comments with a before-and-after comparison, so reviewers see when a prompt or model change made results worse. For red teaming in CI, npx promptfoo@latest redteam run -o output.json produces machine-readable results, and tagging runs with the commit SHA keeps history traceable. Pin the action to a commit SHA, as with any third-party action.
Where it stops
- Graders are models.
llm-rubricassertions and red-team grading rely on a grading model; check a sample of its decisions by hand. - Generated tests are a sample. Passing them shows resistance to those tests, not to every attack.
- Configuration quality decides results. A wrong target, purpose or plugin selection gives reassuring but irrelevant numbers.
- Ownership change. Some teams will want to watch how vendor neutrality evolves now that promptfoo has agreed to join a model provider; the code remains MIT licensed.
How it comes up in interviews
- "How do you test an LLM feature for security regressions in CI?" Assertions for known-bad outcomes, a generated red-team suite, baselines, and pull request comparisons.
- "What is the weakness of LLM-graded tests?" Grader errors and drift; validate graders with labelled samples.
- "Evals versus red teaming?" Evals check expected behaviour on known cases; red teaming searches for unexpected failures.
Sources
Checked on 13 November 2026: promptfoo GitHub README (promptfoo/promptfoo); promptfoo documentation for getting started, red-team quickstart and configuration, and the GitHub Action integration; promptfoo blog posts "Promptfoo is joining OpenAI" (9 March 2026) and on open-sourcing ModelAudit (3 March 2026); npm registry entry for promptfoo.
Interview questions and lessons on the problems this tool is used for:
Compare with
FAQ
promptfoo announced on 9 March 2026 that it had agreed to be acquired by OpenAI and said it would remain open source. Its README says promptfoo is now part of OpenAI and remains MIT licensed.
An independent explainer for interview preparation. AISecurityInterviews is not affiliated with or endorsed by promptfoo (agreed acquisition by OpenAI, announced March 2026; open source, MIT), and product names are trademarks of their owners. Products change quickly; check the vendor's documentation before you rely on a detail. All security tools