Rebuff vs Vigil vs LLM Guard: Prompt Injection Detectors

The three best-known open-source prompt injection detectors are Rebuff, Vigil, and LLM Guard’s PromptInjection scanner, and as of 2026 none of the three is a safe default for new production work: Rebuff was archived in May 2025, LLM Guard was archived in July 2026, and Vigil is self-described alpha. The short reason is maintenance status, but the architecture differences still matter when you decide what to copy, what to fork, and what to put in the request path instead.

Prompt injection sits at the top of the OWASP Top 10 for LLM applications (LLM01), and a handful of open-source detectors exist specifically to catch it at runtime. Three come up most often: Rebuff, Vigil, and the PromptInjection scanner inside LLM Guard. They share a common insight, that no single technique catches prompt injection reliably so you layer several, but they differ in architecture, maturity, and, critically, maintenance status. This comparison covers all three honestly, including the parts that affect whether you should deploy them today.

The shared design idea: layered detection

All three tools reject the notion of a single magic classifier. Prompt injection is adversarial; any one detector can be evaded, so the durable pattern is defense-in-depth across detection methods. Where they differ is which layers they implement and how mature each layer is.

Rebuff: the canonical four-layer design — but archived

Rebuff (Protect AI, Apache-2.0) is the tool most people name first, and its architecture is the cleanest statement of the layered idea. It combines four defenses:

1. Heuristics — fast filters that catch obviously malicious input before it reaches the LLM.
2. LLM-based detection — a dedicated model that reads the incoming prompt and judges whether it’s an attack.
3. Vector database — embeddings of previously seen attacks, so the system recognizes variants of attacks it has encountered before.
4. Canary tokens — markers injected into prompts; if a canary leaks into output, you’ve detected a prompt-leakage attack and can store the offending input for future recognition.

Rebuff ships Python (pip install rebuff) and JavaScript/TypeScript SDKs. Its authors were always candid that “Rebuff is still a prototype and cannot provide 100% protection against prompt injection attacks.”

The decisive fact for 2026: the Rebuff repository was archived by its owner on May 16, 2025, and is now read-only. It is no longer maintained. The architecture remains an excellent reference for how to think about layered injection detection, and the code still runs, but you should not build new production systems on an archived, unmaintained dependency without a plan to fork and maintain it yourself. Treat Rebuff as a design blueprint, not a supported product.

Repository: Rebuff is open source under Apache-2.0 and its code lives on GitHub at github.com/protectai/rebuff. Because the repository is archived and read-only, a production adopter should fork it and pin the fork; the pip install rebuff package still installs, but no upstream fixes are coming.

Vigil: YARA signatures plus embeddings — but alpha

Vigil (deadbits) assesses prompts against a set of scanners to detect prompt injections, jailbreaks, and other risky inputs. Its layer set overlaps with Rebuff’s but leans toward signature-based detection:

• Vector database similarity search against known attack patterns
• Heuristics via YARA rules — the signature engine borrowed from traditional malware detection
• A fine-tuned transformer classifier
• Prompt-response similarity checks and canary tokens for leakage/goal-hijacking detection

Vigil ships the detection signatures and datasets needed for self-hosting and includes a Streamlit playground UI for interactive testing. It is genuinely extensible — you can add custom scanners, write new YARA signatures, or extend the vector DB.

The honest caveat: Vigil describes itself as alpha and experimental, intended for research purposes. The YARA-signature approach is a distinctive and useful idea — it gives you human-readable, version-controllable detection rules — but the project’s stated maturity means it is better suited to research, prototyping, and as a source of detection signatures than to carrying production traffic unattended.

LLM Guard PromptInjection: simple, broad, and now archived

The PromptInjection scanner inside LLM Guard (Protect AI, MIT) was for a long time the pragmatic production choice, for one reason that had nothing to do with cleverness: it was the only one of the three still being maintained. That reason has expired. Protect AI archived the repository on 9 July 2026, and the notice on it states that the project and its associated Hugging Face models are no longer under active development or maintained. The PromptInjection scanner is one of a substantial set of input scanners in a toolkit that now ships no further releases.

Architecturally it is simpler than Rebuff’s four-layer design: a transformer-based classifier that scores a prompt for injection likelihood and returns a valid/invalid verdict plus a risk score. It does not, on its own, give you Rebuff’s canary tokens or Vigil’s YARA layer. What it gave you was a pinnable dependency embedded in a broader scanner library, so you could compose it with Anonymize, Secrets, Toxicity, and the rest. The library is still worth reading as a reference implementation of two-sided scanning, and its cheap pattern scanners age well, but its model-backed classifiers are now frozen against the attack phrasings that existed when the repository closed. For the full picture of that library, see our LLM Guard input/output scanning walkthrough.

Side-by-side

How to choose by use case

The right detector depends less on raw detection cleverness than on what you are building and how much you can maintain.

• Production API or app, small team: none of these three. All three are frozen, and a runtime detector is exactly the component where that hurts, because attack phrasings keep moving after the classifier stops learning. Put a maintained guardrail in the request path instead, and compare the options in Llama Guard vs NeMo vs OpenAI Moderation and NeMo Guardrails: what Colang rails enforce.
• Security research or a detection-rule library: Vigil. Its YARA-signature layer gives you human-readable, version-controllable rules you can study, fork, and reuse even if you never run Vigil in production.
• Designing your own in-house detector: Rebuff as a blueprint. The four-layer pattern (heuristics, LLM judge, vector DB of known attacks, canary tokens) is the cleanest reference architecture, even though the repo itself is archived.

If you are weighing detection against a broader policy layer rather than a pure injection detector, that is a guardrail decision, covered in choosing an LLM guardrail.

Can you run more than one detector together?

Yes, and for adversarial input it is often the point. These tools were all designed around layered defense, so stacking a primary classifier in front with a signature or canary-token layer behind it is a reasonable pattern. The part that is not negotiable is that the primary layer should still be receiving updates, which now means sourcing it from outside these three. The trade-offs to weigh are added latency per request, the combined false-positive rate (each layer can independently refuse a legitimate user), and the maintenance burden of every dependency you add. In practice most teams run one maintained primary detector and reserve extra layers for the highest-risk paths. For where these detectors fit alongside full scanning suites, see the best LLM vulnerability scanners for 2026.

What none of them are

All three are detectors, not complete defenses, and all three say so. A prompt-injection detector reduces risk; it does not eliminate it, because the attack surface is adversarial and evolving. Pair any of them with:

• Pre-deployment red teaming to find what gets through before you ship — our garak walkthrough and PyRIT explainer cover the scanning side.
• Output-side defenses, because a detector that misses an injection on input is your last chance to catch the consequence on output — see the classifier-on-output pattern.
• Honest measurement of detection rate against benign false-positive cost, because a detector tuned to catch everything will refuse legitimate users. aisecbench.com covers prompt-injection detector benchmarking methodology, and our false-positive cost guide covers tuning the threshold.

For the attack techniques these detectors are built to catch, aisec.blog breaks down injection mechanics in operational detail.

Practical Recommendation

For new production deployments in 2026, do not start with any of these three. Rebuff has been read-only since May 2025, LLM Guard since July 2026, and Vigil never left alpha, so adopting any of them means committing to maintain a fork yourself. What they remain genuinely good for is design. Study Rebuff’s four-layer architecture as the reference pattern, since canary tokens and the vector-DB-of-known-attacks idea are worth replicating. Mine Vigil for its YARA signatures, which are human-readable detection rules you can lift into your own stack. Read LLM Guard as a working reference implementation of two-sided scanning, and if you already run it, pin the version you have and treat the archive as a migration trigger rather than an emergency. Put a maintained guardrail in the request path, and measure detection rate against benign false-positive cost on your own traffic before you trust any threshold. For broader stack guidance, guardml.io and aidefense.dev cover the surrounding guardrail and defense landscape.

Detectors are one row in a six-row market, and the neighbouring rows catch different things: probe suites test before release, guardrail layers enforce policy on both directions of a turn, and artefact scanners look at the weight file itself. The categories are mapped in LLM Security Tools: The 2026 Category Map.

Related across the network

• Rebuff: Open-Source Prompt Injection Defense, Layer by Layer — aisecreviews.com