“LLM security tools” is a shopping phrase, not a product category. It covers at least six kinds of software that inspect different things, run at different times, and fail in different ways. A team that buys one category believing it does the job of another ends up with three overlapping input filters, no probe coverage, and an unscanned model file loaded straight off a public hub.
This page is the map. Each category below is defined by what it inspects and when it runs, because those two properties determine what it can possibly catch. Tool names are examples of a category, not endorsements of a shortlist; for a ranked shortlist against your own constraints, run the interactive scanner picker.
The six categories at a glance
| Category | Inspects | Runs | Examples | Structurally cannot catch |
|---|---|---|---|---|
| Pre-deployment scanner | Model or endpoint responses to adversarial prompts | Before release, in CI | garak | Attacks invented after the probe library was written |
| Red-team framework | Multi-turn conversations, agent tool calls, retrieved content | Scheduled campaigns | PyRIT, Promptfoo | Anything you did not script an attack for |
| Injection detector | Individual inbound prompts | In the request path | Rebuff, Vigil | Harm that arrives through the model’s own output |
| Guardrail / policy layer | Inputs, dialog state, retrieved chunks, outputs | In the request path | Llama Guard, NeMo Guardrails, LLM Guard (archived July 2026; reference only) | Policies nobody wrote down |
| AI gateway | Traffic, keys, quotas, routing | At the network edge | Commercial gateways, self-hosted proxies | Semantic attacks that look like normal traffic |
| Model-artifact scanner | Serialized weight files before they load | At ingest, in the registry | ModelScan, picklescan | Malicious behaviour trained into the weights |
Two things fall out of that table immediately. First, only one row inspects the model’s own artefacts, and it is the row most teams do not own at all. Second, three of the six rows (injection detectors, guardrails, and AI gateways) run in production, which is why “we have LLM security tooling” so often means “we have filters” and nothing has ever probed the system.
1. Pre-deployment scanners
A pre-deployment scanner fires a catalogue of adversarial prompts at a target and scores the responses. The canonical open-source example is garak, which separates probes (the attacks) from detectors (the scoring), so its coverage is legible: you can read the probe list and know what it tests. Output is a run log and a report, and the decision it supports is whether to ship.
This is the closest analogue to a vulnerability scanner in classic infrastructure security, and it has the same limitation: it tests for known classes. A scanner that reports zero hits tells you the probe library did not find anything, which is a weaker claim than “the system is safe”. The mechanics of probe and detector architecture are covered in the garak vulnerability scanner walkthrough, and the field is compared in Best LLM Vulnerability Scanners 2026.
Buy this category when you need a release gate and an audit trail. Do not buy it expecting protection: nothing in this category blocks anything at runtime.
2. Red-team frameworks
Frameworks are the layer above scanners. Instead of a fixed probe list, they give you attack strategies, datasets, converters, and scorers, and expect you to compose an attack campaign. That matters because the attacks that break well-guarded systems are rarely single prompts. They are patient multi-turn escalations, or instructions smuggled into a document the agent retrieves, or a tool call the model was talked into making.
PyRIT and Promptfoo occupy this category from opposite ends: one is a research-grade toolkit for building attack chains, the other a developer-workflow harness that generates adversarial cases from plugins and gates a pipeline. The comparison is in Open Source LLM Red Teaming Tools, the architecture in the PyRIT framework explainer, and the CI-shaped version of the question in Automated LLM Red-Teaming in CI. For conversational products specifically, Best Tools to Test AI Chatbot Security covers what full-conversation testing needs that single-shot probing misses.
Buy this category when the deployment has agency: tools, retrieval, memory, or anything that acts on the world. Scanners largely test the model; frameworks test the application around it.
3. Prompt-injection detectors
Narrow classifiers that answer one question about one inbound prompt: is this an injection attempt? They stack heuristics, embedding similarity against known attack corpora, canary tokens, and a classifier model. Because they are narrow, they are cheap enough to run inline on every request, and they beat general-purpose guardrails inside their specialty.
They also inherit the classifier’s failure mode. Every threshold that catches more attacks also refuses more legitimate traffic, and injection phrasing mutates faster than public corpora update. The head-to-head is in Prompt Injection Detectors: Rebuff vs Vigil compared; the broader detection problem, including the signals that survive rephrasing, is in How to Detect Prompt Injection Vulnerabilities.
Buy this category when untrusted text reaches your model, which is nearly always. Pair it with output-side controls, because an injection that slips through the input filter is only visible in what the model then does.
4. Guardrail and policy layers
Guardrails are the general case of the previous category, applied in both directions and organised around a policy rather than a single attack class. Llama Guard is a classifier model with a taxonomy of harm categories. LLM Guard, archived in July 2026 and now reference only, is a pipeline of composable analysers on input and output. NeMo Guardrails is a programmable layer that can also constrain the dialog itself, not just filter its endpoints.
The category’s real cost is not licensing, it is the latency and token budget of adding inference to every turn, plus the ongoing work of writing down policy precisely enough for software to enforce. Start with Choosing an LLM Guardrail for the decision, Llama Guard vs NeMo vs OpenAI Moderation for production trade-offs, NeMo Guardrails: What Colang Rails Enforce for the rail model in detail, and LLM Guard input/output scanning for the analyser catalogue (archived July 2026; reference only). Output-side detection deserves its own attention, covered in Classifier on Output: Patterns That Work.
Buy this category when you have a public endpoint. Do not confuse having it with having tested it: guardrail configurations are exactly the kind of thing that silently stops matching reality after a model upgrade.
5. AI gateways
Gateways sit at the network edge and treat model traffic as traffic: routing, key custody, per-tenant quotas, spend caps, audit logging, and sometimes a filter plugin. They are infrastructure controls, and they solve infrastructure problems — a leaked key, an unbounded bill, a shadow deployment nobody registered.
They do not understand the semantics of the request. An adversarial prompt is a well-formed request from an authenticated client, and a gateway will faithfully route it. Treat this category as the place where governance and cost control live, not as a security filter, and read any vendor claim that a gateway “prevents prompt injection” as a claim about a bundled classifier rather than about the gateway.
6. Model-artifact and supply-chain scanners
The layer teams skip. Before a model serves a single request, its weights arrive as a file, and several common serialization formats execute code on load. Protect AI’s ModelScan exists for exactly this: per its repository it scans H5, Pickle, and SavedModel artefacts for unsafe code and ranks findings by severity, covering PyTorch, TensorFlow, Keras, scikit-learn, and XGBoost saves. picklescan does the narrower pickle-only version of the job, and safetensors avoids the problem by not being a code-execution format at all.
None of these read the weights for behaviour. A model can be entirely free of malicious loader code and still be backdoored by its training data, which is a different problem with a different, much less mature toolset. What artefact scanning buys you is the elimination of the stupid failure: arbitrary code executing on a machine in your cluster because someone pulled an unvetted checkpoint. Library-level and framework-level advisories in the same supply chain are tracked at mlcves.com.
Buy this category the moment you ingest weights you did not train, and wire it into the registry rather than a developer’s laptop.
What is not an LLM security tool
- SAST and dependency scanning. Essential, and aimed at your Python, not your prompts. They will not find a jailbreak.
- A web application firewall. Signature matching against payload shapes does very little against natural-language attacks that are, by construction, ordinary text.
- A generic DLP product. It inspects egress, so it may catch a leaked secret in an output, but it has no notion of system-prompt extraction or excessive agency.
- An evaluation harness on its own. Accuracy regression tests are valuable and orthogonal. Where they meet security is threshold tuning, which is its own discipline: see False Positive Cost in Refusal Systems.
Sequencing, and how to check coverage
For a team starting from nothing, the order that produces the most risk reduction per unit of effort is: artefact scanning at ingest, a pre-deployment scanner in CI, an injection detector inline, then a guardrail policy layer, then a red-team framework once the system has agency, with a gateway added whenever key sprawl or spend becomes the pressing problem. That ordering is deliberately front-loaded with the cheap, unambiguous wins.
To check the result rather than assume it, map the stack against a published risk taxonomy. The OWASP Top 10 for LLM Applications 2025 is the practical choice, and the entry-by-entry version of that exercise is the OWASP LLM Top 10 scanning checklist. Organisations that need the mapping in governance language rather than engineering language will find the same ground covered by the NIST Generative AI Profile. Then scan the deployed system end to end, guardrails included, using the method in How to Scan an LLM for Prompt Injection.
The recurring mistake this map is meant to prevent is simple to state. Filters are not tests, tests are not protection, and neither of them ever looked at the file the model was loaded from.
