You fixed a jailbreak in March. In August someone tweaks the system prompt to make the assistant friendlier, and the same attack works again. Nothing in your test suite fails, because nothing in your test suite knows what a jailbreak looks like.
That is the gap AI red teaming tools exist to fill. The category has gotten crowded fast, and most of the comparison content out there is a vendor ranking. This is the other half of the problem: what a developer should actually look for, and what the answers tell you about how the tool will behave in your pipeline.
Your existing tests do not cover this
Unit tests assert on deterministic outputs. LLM applications do not have those. The failure modes live at the behavioral layer, in how the model, its system prompt, its retrieval pipeline, and its tools respond under pressure from an adversary who is writing plain English instead of code.
The reference list for those failure modes is the OWASP Top 10 for LLM Applications, whose 2026 edition landed in August 2026. Prompt injection, sensitive information disclosure, data and model poisoning, improper output handling, excessive agency. None of these are things pytest catches for you, and none of them stay fixed, because every model upgrade, prompt edit, and new tool connection reopens the surface.
So the first requirement is boring and non-negotiable. Adversarial testing has to be repeatable and automated. A consultant-led audit once a quarter tells you about a system that no longer exists.
Four questions worth asking
Strip away the positioning and evaluating these tools comes down to four things.
Does it test the application or just the model? Testing a base model tells you very little about your app. The interesting vulnerabilities live in the composition: your system prompt, your RAG index, your tool definitions. Look for blackbox testing against a live endpoint, so the target is the thing you actually deployed.
Does it handle multi-turn? Single-prompt jailbreak libraries are the easy part and largely a solved problem. Real attacks escalate across a conversation, where each individual message is harmless and only the trajectory is malicious. Crescendo-style escalation and context hijacking bypass any defense that scores messages in isolation. A tool that only fires one-shot payloads will report a clean run against an application that is trivially breakable.
Does it separate security failures from quality failures? If hardening your prompt against injection also makes the assistant refuse legitimate customer questions, you did not ship an improvement. Adversarial tests and functional tests belong in the same run so you can watch both numbers.
What happens to a finding? More on this below, because it is the question most evaluations skip.
If it is not in CI, it will not happen
Anything that requires a human to log into a dashboard and click "run campaign" gets done before launch and then never again. The tools worth your time are the ones you can declare in code, version in git, and fail a build on.
Here is roughly what that looks like with NeuralTrust's TrustTest, which is code-first and adapted here from its documentation:
from trusttest.catalog.red_team import run_red_teaming
from trusttest.targets.http import HttpTarget, PayloadConfig
target = HttpTarget(
url="https://your-api.com/chat",
headers={"Content-Type": "application/json"},
payload_config=PayloadConfig(format={"message": "{{ test }}"}),
concatenate_field="response",
)
run_red_teaming(target, language="English")
The shape is what matters more than the specific library. You point it at an endpoint, you describe the request and response format, and the attack catalog runs against it. No model internals, no training data, no access to weights. That is what makes it something you can drop into a GitHub Action and gate a merge on.
Two practical notes. Run it against a staging target with realistic retrieval data, because an empty RAG index will happily pass tests that production would fail. And check whether attack generation calls out to a third-party model API on your key, because that turns every CI run into a variable bill.
Agents changed the threat model
If you are shipping agents rather than chatbots, most of the above still applies and the surface gets considerably worse. The attacker is no longer trying to make your app say something embarrassing. They are trying to make it do something, through tool calls, memory writes, and MCP connections.
The specific patterns to test for are indirect prompt injection through tool output and retrieved documents, tool hijacking, permission escalation across integrations, and autonomous drift over long-running sessions. AgentSecurity maintains a useful public catalog of these threat categories and mitigations if you want a vocabulary for your own threat model before you start shopping.
The test to apply to any vendor demo: ask them to show an attack that arrives through a tool result rather than through the user turn. Plenty of tools have no answer for that.
The loop nobody closes
Here is the part that decides whether a red teaming program is worth anything. A finding is not a fix.
Most tools end at a report. Someone reads it, files a ticket, and then a human has to translate "the model leaked its system prompt under a role-play framing" into an actual control that stops it in production. That translation is where programs quietly die. The report gets circulated, the sprint fills up, and the vulnerability ships.
So the question to ask is whether findings map to runtime enforcement, and whether re-running the suite confirms the fix held. Some vendors own both halves. NeuralTrust pairs TrustTest with TrustGuard, a runtime engine that inspects prompts, responses, and tool calls inline and tracks context across turns, so a discovered weakness becomes an enforced policy rather than a backlog item. Others deliberately do testing only and expect you to bring your own guardrails, which is a legitimate choice as long as you know you are making it.
Whatever you pick, do not let the gap between "we found it" and "we blocked it" be an unowned handoff between two teams.
One structural thing to be aware of
Independent AI security startups are being absorbed quickly. SPLX was acquired by Zscaler in November 2025. Lakera was acquired by Check Point, announced in September 2025. Promptfoo, the open-source testing framework a lot of developers already use, was acquired by OpenAI in March 2026, with the open-source project continuing under its current license.
This matters for two reasons. Roadmaps start following the parent platform's priorities rather than the standalone product's, and in the Promptfoo case the tool that red teams your model is now owned by a model provider. Neither is disqualifying. Both are worth a moment of thought if vendor neutrality is part of your requirements. NeuralTrust's own comparison of ten red teaming platforms goes vendor by vendor if you want the longer breakdown.
Bottom line
Pick something you can run from code, that tests your composed application instead of a bare model, that understands multi-turn escalation, and that has an answer for what happens to a finding after it is found. Then wire it into CI on day one, before the pressure of a launch makes it optional.
The alternative is finding out from a user which of your prompts was load-bearing.