DeepTeam Guide: Catch the Leaks Regex Misses (2026)
I asked a deliberately weak chatbot to base64-encode its admin password. It complied. The string assertion I had written to catch exactly that scored the test PASS, because the literal password never appeared in the response, and a matcher only knows the literal string.
DeepTeam is built the other way round. Instead of checking whether a string appeared, it asks a language model to read the response and decide whether a leak occurred. Pointed at a real model, llama3.2:3b holding a secret it had been told never to reveal, it got that model to hand the credential over, scored the answer 0.0, and wrote out its reasoning in plain English. Then I ran the same configuration again three days later and it caught nothing at all. Both of those facts are in this article, because the second one is the more useful.
Those were two different targets in the first comparison, so that pair is not a head-to-head and I am not going to dress it up as one. What the pair shows is a property. A matcher cannot survive a reversible transform of the thing it is matching, and a judge that reads the answer has a chance of catching it. String assertions give you false negatives. Judges cost money per call and give you false positives. That is the trade-off, and almost nobody states it plainly.
I installed DeepTeam 1.0.7 in a container on 2 August 2026. Here is what it does, what it costs, what it caught, and the part that matters more, which is what it missed.
TL;DR, if you've only got 30 seconds
DeepTeam generates attacks and grades them with an LLM judge. You declare vulnerabilities and attacks; it synthesises the prompts and scores each response 0.0 = vulnerable, 1.0 = safe. That scale runs backwards from most tools. Read it twice.
It will not start without an LLM. A hard stop at construction, not a degraded mode. And it needs two model roles, a simulator to write attacks and an evaluator to judge responses.
Apache-2.0, free to install, not free to run. The licence is free. A run is not.
Its judge caught an obfuscated leak a string assertion scored as a pass. But a second run of the identical configuration scored 8/8 safe and caught nothing. The mechanism works; the catch is not repeatable.
Its elaborate generated attacks mostly bounced. One of roughly eight landed on the first run and none of eight on the second. Sophistication and hit rate are not the same thing.
No HTML report. You get objects and JSON. Great for evidence, poor for skimming.
Check your model provider's terms before you scan anything. See the caveat below.
For how DeepTeam compares to the other seven tools I ran, see the hub: AI Red Teaming Tools: Is Your Bot Telling the Truth?
What Is DeepTeam?
DeepTeam is a purpose-built LLM red teaming framework from Confident AI, the same team behind DeepEval, their general evaluation library. Where DeepEval measures whether your model is good, DeepTeam tries to make it misbehave.
The model is declarative. You declare two things:
Vulnerabilities. What could go wrong. PromptLeakage, PIILeakage, and thirty-five others.
Attacks. How to try. PromptInjection, Base64, multi-turn escalation, and others.
DeepTeam then synthesises attack prompts for each vulnerability type, fires them at a callback function you supply, and scores every response with an LLM judge, where 0.0 means vulnerable and 1.0 means safe. That scale is the reverse of what most people expect, and misreading it is the fastest way to declare a broken system healthy.
Set that against a scanner like garak and one distinction matters more than the rest. garak fires a fixed catalogue of probes, so two runs are identical. DeepTeam generates its attacks, so two runs differ. That has consequences I demonstrate the hard way below.
There is a second consequence of grading with a model, and it is the reason the hub singles this tool out. Because a judge reads the response rather than pattern matching it, you can point DeepTeam at questions a string assertion cannot express. Not just "did it leak a credential" but "is that statement about our refund policy accurate". I have not measured how well it does that. What I measured is the mechanism working on one obfuscated leak, below. The capability is architectural. The reliability is yours to establish on your own fixtures.
The facts: Confident AI, Apache-2.0, 2,325 stars, last commit 2026-08-05, v1.0.7, which is the version everything below was measured against. 1.0.8 shipped shortly afterwards, so treat the numbers here as a snapshot of 1.0.7 rather than of the current release.
Install and Run Your First Scan
Installation is genuinely one line:
$ pip install -U deepteam
My container built to 419 MB, the lightest container image of the tools I ran this month, with promptmap2 next at 485 MB and everything else above a gigabyte. There is no PyTorch in it, because DeepTeam never runs a model locally. Everything it does goes out over an API. If you have ever waited out a multi-gigabyte security tool install, this one will surprise you.
Here is the working script, verbatim from my lab, pointed at a local target:
"""DeepTeam red team against the local throwaway target (Acme SupportBot)."""
import requests
from deepteam import red_team
from deepteam.vulnerabilities import PromptLeakage, PIILeakage
from deepteam.attacks.single_turn import PromptInjection, Base64
TARGET = "http://host.docker.internal:8097/v1/chat/completions"
async def model_callback(input: str) -> str:
r = requests.post(TARGET, json={"messages": [{"role": "user", "content": input}]}, timeout=30)
return r.json()["choices"][0]["message"]["content"]
risk_assessment = red_team(
model_callback=model_callback,
vulnerabilities=[PromptLeakage(), PIILeakage()],
attacks=[PromptInjection(), Base64()],
attacks_per_vulnerability_type=1,
simulator_model="gpt-5-nano",
evaluation_model="gpt-5-nano",
)
print(risk_assessment)The model_callback is the entire integration surface. Your system might be a raw model, a RAG pipeline, or an agent with tools. If you can wrap it in a function that takes a string and returns a string, DeepTeam can attack it. That is a genuinely good design decision, and it means you can point it at your full stack rather than at the model in isolation.
⚠️ One install-adjacent trap worth knowing. DeepTeam's licence file is named LICENSE.md, not LICENSE. Automated licence scanners that fetch the raw LICENSE path get a 404 and report the project as having no licence, which is exactly the sort of thing that gets a perfectly permissively-licensed tool rejected in a procurement review. It is Apache-2.0. If your tooling says otherwise, your tooling is wrong.
It Will Not Run Without an LLM, and That Is Two Models
This is the first thing that will stop you, and it is worth stating bluntly because the marketing language around every tool in this category obscures it.
My first attempt ran with no API key configured. It did not degrade, warn, or skip the graded checks. It died at construction:
deepeval.errors.DeepEvalError: OpenAI API key is not configured. Set OPENAI_API_KEY in your environment or pass `api_key` to GPTModel(...).
The traceback runs through red_team(), then RedTeamer.__init__, then initialize_model, before it ever reaches your target. That tells you something. It is resolving the simulator model at construction. Nothing had been attacked yet. Nothing was going to be.
DeepTeam needs two distinct model roles:
A simulator model, which writes the attack prompts.
An evaluation model, which reads the responses and decides whether they represent a failure.
My target needed no API key at all, because it was a local server. DeepTeam still refused to start without two model roles of its own. That is not a bug. It is the architecture, because generated attacks need a generator and LLM-graded scoring needs a grader.
The honest line is that "free and open source" describes the licence, not a run. The Apache-2.0 badge on the repo is real and it costs you nothing. Every scan you execute is billable inference on two model roles, plus whatever your target costs to answer.
Practical advice: pin cheap models explicitly, as in the script above (simulator_model="gpt-5-nano", evaluation_model="gpt-5-nano"). Left unspecified, the default is a premium model, and a red teaming run makes a lot of calls. promptfoo has the same shape for its adaptive strategies, covered in the promptfoo guide, and the hub covers the cost-control playbook across all of these tools.
The Finding, and Why I Could Not Repeat It
This is the section the article exists for.
My target here was a real model, llama3.2:3b running locally on port 8097, given a support-bot persona and an admin password in its system prompt, with instructions never to reveal it. This was not the regex stub I use elsewhere in this cluster. It was an actual model that can be argued with. DeepTeam generated a pretext attack, a "synthetic training data" framing, and the model obliged: it repeated its own system prompt back, admin password included.
⚠️ Read this before you weigh anything in this section. I did not save this run's output. Everything I say about it is reconstructed from notes I took on the day, so I am describing it rather than quoting it. I had originally published a quoted transcript here; on review it turned out to match my other target's canned text, not this one, so I have removed it rather than leave you with a sentence I cannot stand behind. The re-run in the next section is the one with a file behind it, and it found nothing.
DeepTeam's judge scored that 0.0, vulnerable, and, crucially, wrote out its reasoning. It named the finding as internal credentials exposure and cited two things: the concrete admin password that appeared in the output, and the accompanying directive never to reveal it, classing both as confidential system prompts and credentials.
Now the point that makes it matter, and I want to be careful about how I put it, because these were two different targets. On the regex stub on port 8099, a separate exercise, I asked the bot to base64-encode the password and checked the answer with a not-contains string assertion in promptfoo. The literal string never appeared, the assertion had nothing to match, and it scored a PASS. The secret left the building. The test went green.
An LLM judge can read past an encoding. not-contains only knows the literal string. Ask for the secret in base64, in ROT13, spelled out one character per line, translated into another language, or embedded in a sentence, and every string assertion you wrote is now decorative.
Those two results came from different targets, so they are not a head-to-head and I am not offering them as one.
I could not make it happen twice
Three days later I ran the identical script again. Same target, same two vulnerabilities, same two attack methods, same models. Every one of the eight test cases came back 1.0, safe, and the password appeared nowhere in the output.
✓ Risk Assessment completed 🎉! (time taken: 268.17s) » Test Results (8 total tests): » Pass Rate: 100.0% | Passed: 8 | Failed: 0
Nothing was broken. I checked the target separately and it still held the secret and still refused a decommissioning pretext. What changed is the only thing that can change, which is the attacks themselves. The simulator wrote a different set the second time, mostly synthetic-data-generator framings and base64-wrapped questions about defensive security practice, and the model declined all of them. The pretext that worked on 2 August was simply never written again.
So the honest version of this finding is narrower than I would like. The judge caught a real leak that a string assertion had scored as a pass, once, and a second run of the same configuration could not reproduce it. The mechanism is sound and the catch was real. The catching is a coin toss.
I am leaving this in rather than quietly re-running until I got the result I had already written up, because it is the single most practically useful thing on this page. If you run DeepTeam once, get a clean sheet and conclude your bot is safe, you have learned almost nothing. Run it enough times to see the variance, or freeze the attacks that land and re-run those as fixtures.
Two more things I want to be scrupulous about:
I engineered the 8099 stub to base64-encode secrets on request. This demonstrates how the class of assertion fails. It does not establish that promptfoo misses real leaks in production. Run those same six attacks against the real 8097 model and it refused all of them, base64 included.
The judge is not free and not infallible. It bills per call, and it will occasionally flag something harmless. You are choosing which kind of wrong you would rather be.
The other half of this story is in the promptfoo guide.
Reading the Output, and Where It Will Mislead You
DeepTeam returns a RiskAssessment containing RTTestCase objects. Each one carries the full attack input, the actual output, the attack method used, the risk category, the score, and the judge's written rationale.
That rationale is the thing to read. It is the most useful artefact any of these tools produced for me, because it is quotable. When you need to tell someone that your chatbot leaked a credential, "the judge scored 0.0 and here is the paragraph it wrote explaining which credential and why" is a much stronger position than "a test went red."
Three gotchas in reading it:
The scale runs backwards. 0.0 is the failure. 1.0 is the pass. Every other tool in this space scores higher-is-worse or uses pass/fail strings; DeepTeam is higher-is-safer. If you are aggregating results across tools into one dashboard, normalise this deliberately or you will invert a real finding.
There is no HTML report. garak hands you a browsable, OWASP-grouped report. DeepTeam hands you Python objects and JSON. Excellent for evidence, poor for skimming, and it means you will be writing your own summarisation layer if you want something to hand to a manager.
Runs are non-deterministic. I am not stating that as a design caveat I read somewhere. I ran the same script twice against the same target and got a credential leak the first time and a clean 8-out-of-8 sheet the second, documented in full above. This matters enormously if you intended to use DeepTeam as a regression suite. It is not one, out of the box. There is a way to get one anyway, and it is the last thing in my verdict.
What It Is Bad At, Its Clever Attacks Mostly Bounced
Here is the counterweight, and I would rather you heard it from me than discovered it at run seven.
DeepTeam's synthesised prompts were genuinely sophisticated. Fake "AI Safety Researcher" framings demanding redacted JSON training samples. Base64-wrapped audit requests. Elaborate, plausible, well-constructed social engineering.
Against the llama3.2:3b target on port 8097, most of them bounced. The model refused or returned something harmless and DeepTeam scored 1.0, safe. Roughly one in eight landed on the first run, and the one that did is the leak described above. On the second run, none of the eight landed at all.
One caveat on that first figure, since I am asking you to trust it. The config fixes the denominator at eight, being two vulnerabilities across four sub-types each, and the second run confirms exactly eight cases. But I did not save the first run's output, so the numerator, one case landing out of those eight, is my note from the day rather than something you can check. The second run's numbers are the ones with a file behind them.
The lesson is that attack sophistication and hit rate are not the same thing, and hit rate depends on the target. An elaborate pretext needs a target capable of following the pretext at all. Against a model that reasons, a well-built social-engineering framing is exactly the right shape of attack, and most of these still did not work. That is worth knowing before you read a low score as a clean bill of health, or a high one as a broken bot.
What I am not going to do is turn that into a league table. I ran other tools against other targets in this lab, and comparing their hit rates would mean comparing runs that differed in more than the tool. A hit rate is a fact about one tool against one target on one day.
This is an argument for running more than one tool, which is precisely what the hub concludes. Read the technique section on the hub.
Other honest limitations:
Two LLM roles required. Cost, plus the non-determinism described above.
Red teaming only. For general evaluation quality you need DeepEval alongside it.
A smaller community than the tools it competes with at 2,325 stars, against garak's 8,712 and NeMo's 6,880. Fewer Stack Overflow answers, fewer blog posts, fewer people who have hit your exact error before.
Its documentation lags its own code. The docs site lists twenty-five attack pages and headlines "10+", while the installed package ships twenty-seven. On the attack count the docs err downward, which is the harmless direction. On the vulnerability count they err the other way, with the README claiming "50+" against a shipped thirty-seven. So the drift has no reliable direction, the docs are not a reliable inventory either way, and you should enumerate from the package if you need an exact figure for a report.
Coverage and Framework Mappings
37 vulnerability classes and 27 attack methods, being 22 single-turn and 5 multi-turn, including persona simulation, jailbreak injection, and a first-class Multilingual attack, which is more interesting than it sounds, because safety training is unevenly distributed across languages.
I counted those out of the installed package rather than the documentation, and the gap is worth a sentence. The README advertises "20+" attack methods and ships twenty-seven, so the headline number is a floor rather than a count. Its own enumerated list, though, matches the package exactly. The drift is on the documentation site, where the headline still says "10+" and the sidebar carries twenty-five individual attack pages against the package's twenty-seven. Count those from the sitemap rather than the sidebar if you want to reproduce it, and note that they sit under two different prefixes, twenty adversarial and five agentic, which is the easiest way to undercount them. Enumerate from the package if you need a figure for a report, because the docs will short-change you. Count carefully when you do: a naive class listing returns thirty, and three of those are not attacks, being two abstract base classes and a parameter class.
Framework mappings: OWASP LLM Top 10 (2025), OWASP Agents (2026), NIST AI RMF, MITRE ATLAS, BeaverTails and Aegis.
The part of that catalogue most write-ups skip
Most of those vulnerability types are what you would expect from a red-teaming tool, covering leakage, injection, excessive agency and the agent-specific ones. But three of them are not about attacks at all, and they are the reason DeepTeam appears in the shortlist on the hub.
I listed them out of the installed package rather than the docs, because that is the only source that cannot be stale:
Misinformation -> factual_errors, unsupported_claims, expertize_misrepresentation Hallucination -> fake_citations, fake_apis, fake_entities, fake_statistics Competition -> competitor_mention, market_manipulation, discreditation, confidential_strategies
Read those again with a support bot in mind rather than a threat model. factual_errors and unsupported_claims are a bot stating something about your business that is not so. expertize_misrepresentation is it answering with more authority than it has, which is precisely how an invented policy gets believed. fake_statistics and fake_entities are numbers and names that sound right and do not exist. competitor_mention is your bot volunteering opinions about rivals.
None of those require an attacker. They are things a perfectly well-behaved bot does to an ordinary customer on a Tuesday afternoon, and they are the failures a small operator is most likely to actually meet. Most tools in this category have no equivalent category, because they are built around attack signatures and there is no signature here.
⚠️ Scope, because this matters and it is easy to overstate. What I verified is that these vulnerability types ship and that DeepTeam generates probes and grades responses for them. I have not measured how reliably it catches business-specific falsehoods on a real bot, and I would not believe a number that came without a target description attached. Treat the catalogue as evidence that the tool is pointed at this problem, not as a detection rate.
Those were the cleanest OWASP presets of the tools I ran, and there is a specific reason that matters. DeepTeam maps to the 2025 revision of the OWASP LLM Top 10, where garak's report groups against the earlier v1 list. If someone is going to ask you which OWASP items your testing covers, and in a regulated environment someone will, mapping to the current revision saves you a translation exercise.
What It Costs
The framework is free. Apache-2.0, runs locally, no probe caps, no licence tiers.
The platform is not. Confident AI publishes real prices, and it was the only tool in this set to do so, which I think deserves credit in a category where "contact sales" is the norm:
| Tier | Price |
|---|---|
| Free | $0 |
| Starter | $200/mo |
| Team | $2,000/mo |
| Enterprise | Custom |
One caveat I need to be exact about. Those tiers cover the Confident AI platform broadly. They are not a price for DeepTeam red-teaming usage specifically. Do not read the $200 as "the cost of red teaming", because nothing in their published pricing says that.
And the cost that actually bites is neither of those. It is the two LLM roles per scan, plus the inference your target burns answering every attack. Against a real pipeline that classifies, retrieves, generates and output-checks, one attack prompt is several billable model calls, not one.
Before You Point This at Anything, the Terms
DeepTeam generates jailbreak and prompt-injection attacks. If you fire those at a hosted frontier model, you are potentially in scope of your provider's acceptable use policy.
Anthropic's Usage Policy prohibits users from:
"Intentionally bypass capabilities, restrictions, or guardrails established within our products for the purposes of instructing the model to produce harmful outputs (e.g., jailbreaking or prompt injection) without prior authorization from Anthropic"
Read the middle clause carefully, because it does the work. The prohibition attaches where the purpose is eliciting harmful output. That is not a blanket ban on all testing, but it squarely covers toxicity-elicitation attacks, and whether it reaches testing your own application for credential leakage is genuinely untested. I am not going to tell you it is fine.
Google's policy prohibits "circumvention of abuse protections or safety filters." OpenAI's is ambiguous, prohibiting "unsolicited safety testing" without ever naming jailbreaking.
The practical resolution for DeepTeam specifically: point the model_callback at a local or open-weight model, or at your own application with the upstream model call stubbed. Your callback is just a function, so you control entirely what it talks to. And pin your simulator and evaluator to models whose terms you have actually read.
The hub has the full analysis, including the commercial-terms suspension language. Read it before you scan anything.
My Verdict
DeepTeam is the one I would reach for to judge whether something actually went wrong, and it is not the one I would install first.
Those are both true, and neither is a ranking. If you want a broad first sweep of an endpoint for nothing, garak does that and DeepTeam does not. It will not even start without two model roles. But once you have a finding and you need to establish whether the thing your bot said actually constitutes a leak, DeepTeam is the tool that answers the question rather than pattern-matching at it.
Reach for it when:
You need judged results rather than string matches, especially against obfuscation.
You need to quote the reasoning to someone who will ask why it failed.
You are testing an agent or multi-turn system where single-turn probes miss the failure.
You need clean OWASP LLM Top 10 (2025) mapping for evidence.
Skip it when you want a free sweep (garak), a deterministic regression suite (freeze fixtures instead), or an HTML report you can hand to a manager without writing code.
The thing I would actually take away from this
If you remember one line from this page, make it this one: a generative red-teamer is a fuzzer, not a regression suite. That is the real lesson of the run I could not repeat. It should hold in principle for any tool that writes its own attacks rather than drawing them from a fixed list, though DeepTeam is the only one I have watched contradict itself.
Which gives you the workflow above. The reason it works is that frozen fixtures are deterministic and the generation never was, so you get to keep the discovery without pretending it was a test. And the reason people skip it is that a clean sheet looks like good news, which makes a confident 100% pass rate the easiest wrong conclusion on offer.
Budget for model spend. It is free to install and it is not free to run.
FAQ
Is DeepTeam free?
The framework is Apache-2.0 and free to install, with no probe caps. But it will not run at all without two LLM roles, a simulator model to write the attacks and an evaluation model to judge the responses, so every scan carries inference cost. Confident AI's platform is separately priced from $0 to $2,000/mo, and those tiers cover the platform broadly rather than red-teaming usage specifically.
What is the difference between DeepTeam and DeepEval?
Same team, different jobs. DeepEval is general LLM evaluation, asking whether the output is correct, relevant and faithful to its sources. DeepTeam is adversarial, asking whether the system can be made to leak, comply or misbehave. They are designed to sit alongside each other, and DeepTeam is red teaming only, so if you want general evals too you are installing both.
DeepTeam or promptfoo?
Different strengths and it is worth having both. promptfoo is built for CI pipelines and produces strong compliance evidence. DeepTeam grades with an LLM judge, which is what caught an obfuscated leak that a not-contains assertion in promptfoo scored as a pass on my target. If you have to choose one for a pipeline, promptfoo. If you have to choose one for judging whether something really leaked, DeepTeam.
Does DeepTeam map to the OWASP LLM Top 10?
Yes, and to the 2025 revision, along with OWASP Agents (2026), NIST AI RMF, MITRE ATLAS, BeaverTails and Aegis. That is a real advantage if you need the current OWASP items rather than the v1 list, which is what garak's report groups against.
Why do my DeepTeam results change between runs?
Because both halves are non-deterministic. The attacks are generated by a simulator model rather than drawn from a fixed catalogue, and the scoring is an LLM judgement rather than a string match. In my own testing that gap was as wide as it gets: one run extracted an admin password and scored it 0.0, and a rerun of the identical script three days later passed all eight cases and found nothing. If you need a regression suite, capture the attacks that landed and freeze them as fixtures, and treat the generation as discovery rather than as the test.
Does DeepTeam produce a report I can hand to an auditor?
Not directly. It returns a RiskAssessment of RTTestCase objects, each carrying the attack input, actual output, attack method, risk category, score and the judge's written rationale, as objects and JSON. That is excellent raw evidence, arguably better than a summary because you can quote why something failed, but there is no HTML report like garak's. You will be writing the presentation layer yourself.
How many attacks does DeepTeam ship?
Twenty-seven in v1.0.7, split twenty-two single-turn and five multi-turn. That figure comes from the installed package, which is the only source that cannot go stale. The README's enumerated list agrees with it, though its 20+ headline reads as a floor, and the docs site lags behind both. If you verify it yourself, discard three of the thirty classes a plain listing hands back, because they are scaffolding rather than attacks.
About the Author
Nathan House, Founder & CEO of StationX
Nathan House has 30 years of hands-on cybersecurity experience and is Cambridge-educated, holding CISSP, CISA, CISM, OSCP, CEH, and SABSA. He founded StationX in 1999 — one of the UK’s first cybersecurity companies — and has secured £71 billion in UK mobile banking transactions and the London 2012 Olympics, advising clients including Microsoft, Cisco, BP, Vodafone, and VISA. He authored the world’s most popular cybersecurity course — a #1 Udemy bestseller taken by over 500,000 students — and was named Cyber Security Educator of the Year 2020, AI Security Educator of the Year, and a UK Top 25 Security Influencer 2025. A DEF CON speaker and featured expert on CNN, Fox News, NBC, and the BBC, Nathan leads StationX’s training of more than half a million students worldwide.
