Most AI red teaming proposals read the same. Prompt injection, jailbreaks, data leakage, a nod to the OWASP Top 10 for LLM Applications, a fixed price. You cannot tell two providers apart from the proposal, so stop reading proposals first. Ask each provider for one redacted finding from a past engagement, the whole thing, and compare those.
A finding is the product. Everything else in the engagement exists to produce it. Below is what to look for in that sample, and in the scope that would have to exist for it to be written.
Scope the Layers, Not the Model
The first question a good provider asks you is what the model can reach. A weak one asks which model you use.
Testing whether GPT-class or Claude-class models can be jailbroken is not a useful engagement for most buyers. The model vendor already does that, at a scale no outside firm will match. Your risk lives in what you bolted on. A usable scope lists, at minimum:
- Retrieval sources: every index the application reads from, and who can write to it. A SharePoint library any employee can edit is an indirect prompt injection (AML.T0051.001) channel.
- Tools and their permissions: each function or MCP server the model can call, and whether the call is read-only or changes state (AML.T0053). Exfiltration through a tool call (AML.T0086) only exists if a tool can send data somewhere.
- Output rendering: where the response is displayed. If the client renders Markdown images or links, a response containing
leaks data without anyone clicking (AML.T0077). Johann Rehberger has documented this pattern across many shipping products. - Identity: whose permissions the model runs with. A retrieval layer that queries as a service account instead of as the requesting user turns every injection into a privilege escalation.
The Slack AI issue PromptArmor disclosed in August 2024 used all four at once: a public channel as the injection source, retrieval across channels, a rendered link as the exit, and the victim’s own access. No jailbreak was involved. A scope that said “test the model” would have missed it.
What a Real Finding Looks Like
Here is the shape to hold a sample finding against. This one is illustrative, not from a real engagement:
id: F-03
title: Indirect injection in shared wiki page exfiltrates retrieved HR docs via Markdown image
atlas: [AML.T0051.001, AML.T0077]
owasp_llm: [LLM01:2025, LLM02:2025]
target:
app_build: assistant-web 4.12.0
model: gpt-4.1-mini-2025-04-14
temperature: 0.7
system_prompt_sha256: 9f1c...e2
preconditions: attacker can edit any page in the "Engineering" wiki space
reproduction: redteam/f03_wiki_injection.yaml
trials: 50
successes: 19 # 38%, 95% CI roughly 25-52%
impact: contents of any HR document the victim can access sent to attacker host
fix_tested: CSP img-src restricted to company CDN; 0/50 on retestFive things in that record separate a provider who did the work from one who pasted screenshots.
A pinned target. Model snapshot, temperature, and a hash of the system prompt. Without these, nobody can tell whether a later fix worked or the model alias quietly moved to a new snapshot.
A rate, not an anecdote. LLM output varies run to run, so “we got it to leak once” is a screenshot, not a finding. Fifty trials and a confidence interval tell you how often a real attacker succeeds. We covered the arithmetic in AI red team training for security engineers.
A runnable reproduction. A script or a config file, in a format your team can run. promptfoo configs, PyRIT orchestrators, or plain Python against your API all qualify. A PDF of chat transcripts does not.
Impact in data and actions. “The model produced disallowed content” is a policy finding. “HR documents left the network” is a security finding. Your remediation budget should follow the second kind.
A tested fix. The provider should rerun the test suite after the mitigation and report the new rate.
Read the Ratio of Scanner Output to Manual Work
garak and PyRIT are free. So is promptfoo’s red team mode. They are good tools, and any competent provider will run one of them early. The question is how much of the report they account for.
If most of the findings are generic probe categories (DAN variants, encoding tricks, known jailbreak templates) with pass/fail counts, you are paying for a scanner run. Your own AppSec team can do that. Microsoft’s AI Red Team, in Lessons From Red Teaming 100 Generative AI Products, makes the same point from the provider side: automation widens coverage, the human element is still crucial, and “you don’t have to compute gradients to break an AI system.” One of their case studies is a server-side request forgery in a video-processing service: a plain application bug, found by people who understood the system, that no jailbreak library would have probed for.
Ask what fraction of the hours goes to mapping your architecture before any payload is sent. If the answer is none, the scope section above was never going to happen.
Insist on Keeping the Test Cases
The report ages the day the model changes. The test cases do not, as long as you own it.
Write it into the contract: every reproduction ships as a file in your repo, runnable against staging, with a documented command. For promptfoo that is a single line your CI can run on every model or prompt change:
npx promptfoo@latest eval -c redteam/f03_wiki_injection.yaml --repeat 50 -o results/f03.jsonA provider who resists handing over the test cases is selling you a subscription to their next engagement. That is a business model, not a security control.
When Not to Hire Out
An outside firm earns its fee in two cases. One is independence: a pre-launch assessment that a board, an auditor, or a customer’s security review will read, or a test of something your own engineers built and cannot see past. The other is regulatory. Providers of general-purpose AI models with systemic risk must document adversarial testing under Article 55 of the EU AI Act, and NIST AI 600-1 lists AI red teaming among the actions for measuring generative AI risk.
Outside those cases, the economics favor building the skill internally. If your LLM application ships a new prompt or tool every sprint, a quarterly engagement tests a system that no longer exists. The team that reruns the test suite, triages the new rate, and writes the next test case has to be yours. We argued the organizational side of this in why security teams should own AI red-teaming.
The honest limit: in-house teams are bad at testing their own assumptions. If the same engineers designed the retrieval layer and wrote the injection tests, expect blind spots. Plenty of organizations end up with both: an internal team that owns the test suite, and an outside test once a year to check the internal team.
Where the Skill Comes From
Building red-team frameworks and reporting for AI deployments is one of the core topics in GTK Cyber’s AI Red-Teaming course, because a red team that cannot produce a reproducible finding cannot hold a provider to that standard either. If you are comparing training options rather than service firms, our AI red team training page and the broader AI cybersecurity training pillar lay out what to look for.