Red teaming as an application test
DeepTeam treats an AI system as a target that accepts input and returns output. You wrap that target in a Python callback, then the framework generates adversarial prompts, runs them through the callback, and evaluates the responses. That narrow boundary is excellent. It can sit in front of a simple model call, a retrieval pipeline, a chatbot with policy code, or an agent that can invoke tools. The test sees what the user sees rather than granting itself privileged access to the implementation.
The scope is much wider than a jailbreak prompt list. The README groups more than 50 vulnerabilities across privacy, responsible AI, security, safety, business, and agent behavior. Examples include prompt leakage, broken object authorization, server-side request forgery, hidden instructions in retrieved content, excessive agency, inter-agent message spoofing, and external system abuse. More than 20 attacks transform or extend the initial probes through roleplay, encoding, context manipulation, permission claims, and multi-turn escalation.
This breadth is DeepTeam's main advantage. A team can begin with one bias check and prompt injection, then add risks that match the application's actual permissions. It can also select an established framework such as the OWASP lists, NIST AI RMF, or MITRE ATLAS and let DeepTeam map categories to tests. That mapping is a useful checklist accelerator. It is not proof that a system complies with a standard, because passing generated cases does not establish complete coverage or effective organizational controls.
The callback makes the first run easy
The smallest example is credible: pip install -U deepteam, write an asynchronous callback, choose a vulnerability and attack, and call red_team. No prepared dataset is required because the framework creates baseline attacks during the run. The resulting risk assessment includes an overview, binary scores with explanations, dataframe conversion, and local JSON saving. A CLI and YAML configuration provide another path for repeatable automation.
The phrase runs locally needs interpretation. The orchestration and metric code execute on your machine, but the quick start asks for an OpenAI API key. DeepTeam uses language models to simulate attacks and judge responses, so prompts and outputs go wherever the configured models run. DeepEval supports custom models, which can provide a private path, but the operator has to configure and host that path. This is not an offline security scanner merely because the Python process is local.
Cost and duration also grow with coverage. Each vulnerability type can produce multiple attacks, multi-turn methods make several exchanges, the target callback consumes requests, and model-based evaluation adds more work. DeepTeam now has cost tracking in current development, but teams should still start with a small matrix and measure their own provider use before placing a large framework run in every pull request.
Model judges are useful evidence, not ground truth
DeepTeam's metrics produce binary results and reasoning. That is easy to summarize and compare, especially when a team reruns the same application after changing its prompt, model, retrieval rules, or tools. Generated attacks can also discover phrasings a hand-written test set would miss. Custom vulnerabilities let a company express rules specific to its product rather than depend only on generic safety categories.
The weakness is the same mechanism. An evaluation model can misread context, vary across runs, or share blind spots with the target. A simulator can refuse to generate the hostile material needed for a controlled test. An open report describes recent provider models declining attack generation before the target is even reached. A passing rate therefore measures this run, with these attack and judge models, not the absence of a vulnerability.
Use the framework as a discovery engine. Review failures, remove false positives, retain the clearest attacks, and turn high-value cases into deterministic application tests where possible. For tool-using agents, run against sandboxed accounts and inert resources. A successful shell injection or authorization bypass test should not be able to damage a real environment.
Guardrails broaden the product, with caveats
DeepTeam includes seven guards for toxicity, prompt injection, privacy, illegal content, hallucination, topical scope, and cybersecurity. Input guards run before the target and output guards run before content reaches a user. The connection from finding a failure to testing a guard is convenient, and one package can cover both assessment and a first defensive layer.
Do not confuse a classification guard with application security. Authorization checks, tool permissions, network boundaries, output escaping, database parameterization, and audit logs still belong in ordinary code and infrastructure. A model-based guard can add defense, but it should not be the only barrier protecting a database or shell.
Packaging deserves similar caution. The latest GitHub release is v1.0.4 from November 2025, while the current main branch declares version 1.0.8 and was pushed on August 5, 2026. An open issue reports that six attacks documented in the README exist on main but are missing from the tagged package. Pin the exact installed version and test imports rather than assuming the website, main branch, and package index match.
Health and who should adopt it
The repository's open count is 53, combining issues and pull requests. Recent merged work fixed multilingual attack schemas, JSON serialization, and conversation-memory reset behavior, while open pull requests continue to address event-loop errors and evaluation edge cases. Issues and code were active through August 2026, so the older release tag should not be read as abandonment. It does show a release-discipline gap that affects users.
DeepTeam belongs in the pre-release and regression workflow of a Python AI product, especially one with retrieval or tools. Its Apache 2.0 license, small callback interface, framework mappings, local result export, and large test catalog make a convincing package. Adopt it with three controls: pin versions, account for every model endpoint and its data path, and require human review before a score becomes a security claim.