Best LLM Guardrails Tools in 2026: What to Use Now That LLM Guard Is Archived

Open the GitHub page for protectai/llm-guard today and there is a gray banner across the top: this repository has been archived. The commit history stops on July 8, 2026, and the README states that the project and its associated models on Hugging Face are no longer under active development or maintained. It had 3,201 stars, an MIT license, 15 input scanners and 20 output scanners, and it is the tool most "best LLM guardrails" listicles still put near the top.

That is worth knowing before you pip install it into a production request path this week.

The archive is not really a surprise once you follow the ownership. Protect AI, which maintained LLM Guard, was acquired by Palo Alto Networks in a deal that completed on July 22, 2025. Around the same stretch, Check Point announced it was acquiring Lakera on September 16, 2025, reportedly for about $300 million. Then Palo Alto announced its intent to acquire Portkey on April 30, 2026, and OpenAI announced it was acquiring promptfoo on March 9, 2026. In eighteen months, most of the independent names in this category became line items inside a larger security platform.

The useful news is that the maintained open-source options are in better shape than the archive suggests. Every license, version and price below came from the vendor's own page or repository in August 2026, and the redaction test near the end ran on a laptop with the versions named.

The Three Jobs People Call "Guardrails"

Buying for one of these when you need another is the most common mistake in this category.

Input rails inspect what goes into the model: injection detection, jailbreak classification, topic restriction and PII stripping. They run on untrusted text, so this is the layer under active adversarial pressure.

Output rails inspect what comes back: toxicity, PII leaks, groundedness against retrieved sources, format validation. They catch a different failure mode, the model misbehaving on its own or repeating something it should not have.

Red teaming is not a runtime rail at all. It is a test suite that attacks your app on purpose, in CI, before you ship. Confusing it with a runtime filter is how teams end up with a good pentest report and no production defenses.

Most production systems need all three, and they are usually three different tools.

Why Injection Does Not Get "Fixed"

Prompt injection holds the top spot in the OWASP Top 10 for LLM Applications 2025 for the second consecutive edition, as LLM01, ahead of sensitive information disclosure and supply chain vulnerabilities.

It is stubborn for architectural reasons rather than because nobody has patched it. An LLM receives instructions and data in the same channel with no structural separation, so text that arrives as content can be read as a command. There is no equivalent of a prepared statement to bind a parameter safely.

The clearest demonstration is EchoLeak, CVE-2025-32711, CVSS 9.3, disclosed by Aim Security in June 2025 and written up as the first real-world zero-click prompt injection exploit in a production LLM system. An attacker emailed a Microsoft 365 Copilot user with a payload hidden in an HTML comment or as white-on-white text. Nobody clicked anything. Later, when the user asked Copilot something unrelated, the RAG layer pulled that email into the context window and the hidden text was read as instructions. The exploit chained several bypasses, including evading Microsoft's cross prompt injection classifier and abusing a Teams proxy the content security policy already allowed. Microsoft patched it server-side and reported no exploitation in the wild.

The lesson is that an input classifier is necessary and not sufficient, because this injection never went near the input box.

The Architectural Fix That Beats Every Filter

Simon Willison's framing from June 16, 2025 is the most useful thing to internalize before comparing tools. He calls it the lethal trifecta: access to private data, exposure to untrusted content, and the ability to communicate externally. Hold any two and an agent is broadly safe. Grant all three in one session and an attacker who controls the untrusted content can read the private data and ship it out, no exploit code required.

This matters because it is a design constraint you can enforce with certainty, which no probabilistic classifier can offer. Removing one leg is worth more than any accuracy improvement, and it costs nothing per request. Treat every tool below as depth behind that decision, not a substitute for it.

Open Source Options Worth Using

Five of these are genuinely open source and self-hostable: NeMo Guardrails and Guardrails AI under Apache 2.0, Presidio under MIT, promptfoo under MIT, and Llama Prompt Guard 2 under Meta's Llama license with an MIT base model. All five run on your own hardware, and four of the five carry no usage restrictions at all.

NVIDIA NeMo Guardrails

NeMo Guardrails is Apache 2.0, at version 0.23.0 released July 1, 2026, with about 6,900 stars and commits landing this month. The repository moved, so bookmark the new path: NVIDIA/NeMo-Guardrails now redirects to NVIDIA-NeMo/Guardrails.

It is the most structured option, organized around five rail types mapping to distinct pipeline stages: input, dialog, retrieval for RAG chunks, execution around custom actions, and output. Policies are written in Colang, a Python-adjacent DSL for describing conversational flows.

It fits anything shaped like a conversation with rules about where it may go, and its retrieval rails are the right hook for the EchoLeak problem of untrusted text arriving through RAG rather than the user. The tradeoffs: Colang is a real language to learn, and several rail types call an LLM to decide, adding latency and token cost per request. If a comparison post quotes a "sub-100ms, GPU-accelerated" figure for NeMo, treat it with suspicion, because the repository publishes no latency benchmarks at all.

Guardrails AI

Guardrails AI is Apache 2.0, at v0.10.2 released June 4, 2026, with roughly 7,300 stars and active commits. It is built around a hub of composable validators, each detecting one risk such as toxicity, PII, profanity, hallucination or bias, which you assemble into input and output guards around a model call.

This is the natural fit for structured output validation and per-field rules rather than conversational flow, and the validator-per-risk design is easy to adopt incrementally. The catch is that your guarantee depends entirely on which validators you pick, and some of the more interesting ones call out to a model, so read each one before assuming it is a local computation.

Presidio

Presidio is MIT licensed, at 2.2.364 released July 22, 2026, with about 10,400 stars, and it does one job properly: detecting and anonymizing PII in text, images and structured data. It combines named entity recognition with pattern matching and checksum validators, and runs entirely on your hardware with no API call.

Update your bookmarks and your Docker pulls, because this one moved too, and in the opposite direction from everything else in this article. It is no longer microsoft/presidio; that URL now 301s to data-privacy-stack/presidio. Presidio is transitioning to a community-owned project under a vendor-neutral organization, with Microsoft's support, and the LICENSE now reads "Copyright (c) Presidio Contributors" rather than Microsoft. It stays MIT, and existing integrations are expected to keep working. The one change that will actually break a pipeline is that the container images moved from the Microsoft Container Registry to ghcr.io/data-privacy-stack/presidio-*, so a hardcoded mcr.microsoft.com pull is the thing to grep for.

So while the commercial end of this category was being absorbed into large security vendors, the best open PII tool went the other way, out of a big vendor and into community stewardship. If your requirement is that Social Security numbers and customer names never reach a third-party model, this is the piece to reach for, and it is the one I ran locally below. It is not an injection defense and does not claim to be.

Llama Prompt Guard 2

Meta's Llama Prompt Guard 2 is the open-weight classifier route: a small self-hosted model that labels a prompt benign or malicious, covering injection and jailbreaks. The 86M version builds on Microsoft's MIT-licensed mDeBERTa-base, and a 22M version on DeBERTa-xsmall cuts latency and compute by about 75 percent for a modest accuracy cost. Be precise on licensing: the base model is MIT, but the Prompt Guard weights ship under Meta's Llama license as a gated download, which is not the same as an MIT dependency.

The numbers are strong and, more usefully, honestly bounded. The model card reports .998 AUC on English and 97.5 percent recall at a 1 percent false positive rate, then a real-world attack prevention rate of 81.2 percent at 3 percent utility reduction. That gap between benchmark AUC and real-world prevention is the most valuable line in the document. The limitations are stated plainly too: a 512-token window means chunking long inputs, the 22M variant lacks multilingual pretraining, and adversaries may build attacks specifically to bypass it. Tokenization is adversarially hardened against whitespace manipulation and fragmented-token tricks.

promptfoo

promptfoo is MIT licensed with about 24,000 stars and commits landing today, and it covers red teaming rather than runtime filtering. Its red team mode generates adversarial prompts from attack plugins spanning injection, jailbreaks, PII leakage, SSRF, SQL injection, excessive agency and hallucination, then reports what got through. It belongs in CI beside your test suite. Note for long-term bets: OpenAI announced it was acquiring promptfoo on March 9, 2026. The license is MIT and the code is public, so the downside is bounded, but the roadmap is no longer independent.

Managed and Cloud Options

Amazon Bedrock Guardrails

Bedrock Guardrails is the easiest option to price honestly because AWS publishes per-policy rates. You are billed only for the filters you enable, and a text unit is up to 1,000 characters, so a 5,600-character input bills as six units.

Content filters: $0.15 per 1,000 text units for text, $0.00075 per image · Denied topics: $0.15 per 1,000 text units · Sensitive information filters: $0.10 per 1,000 text units, and free when done by regex · Word filters: free · Contextual grounding checks: $0.10 per 1,000 text units · Automated Reasoning checks: $0.17 per 1,000 text units per policy

Two lines there deserve attention. Word filters and regex-based sensitive information filters cost nothing, which makes the cheapest useful guardrail in this category a deny list you write yourself. And contextual grounding checks, the direct answer to a RAG system inventing facts, are priced below the content filters.

Model the cost before enabling everything. Take one million requests a month, an average prompt of 800 characters (one text unit) and an average response of 1,600 characters (two text units), so three text units per request. Content filters on both sides bill three million text units, which is 3,000 thousand-unit blocks at $0.15, or $450 a month. Denied topics on the input only adds one million units at $0.15, or $150. Sensitive information filters on the output at $0.10 per thousand units adds $200. That lands near $800 a month: fine if you planned for it, a surprise if you enabled four policies because the console made it easy.

Azure AI Content Safety and Prompt Shields

Azure bundles text and image moderation, Prompt Shields for direct and indirect injection, groundedness detection and protected material detection into a single price rather than charging per policy the way Bedrock does.

The free tier is 5,000 text records and 5,000 images per month, and usage stops when the limit is reached rather than overflowing into billing. The standard tier is $0.38 per 1,000 text records and $0.75 per 1,000 images, checked in Central US with the currency set to USD. A text record is up to 1,000 characters measured by Unicode code points, so a 7,500-character input counts as eight records.

Worth noting for anyone comparing the two: because that $0.38 covers Prompt Shields, groundedness and protected material detection together, and Bedrock charges $0.15 for content filters plus $0.10 for grounding plus $0.10 for PII separately, the cheaper option genuinely depends on how many policies you intend to turn on. Bedrock wins if you want one or two. Azure can win if you want all of them. Check the rate for your own region before assuming either way, because these are region-specific.

Lakera Guard, now Check Point

Lakera Guard is the best-known dedicated runtime prompt firewall, with API-first detection of injection, jailbreaks, data leakage and policy violations. Check Point announced the acquisition on September 16, 2025, expected to close in Q4 2025, with Lakera becoming the foundation of a Check Point center of excellence for AI security. If you are evaluating it now, ask directly how it is packaged post-acquisition, because standalone pricing rarely survives absorption into an enterprise platform.

Prisma AIRS, now holding Protect AI

Protect AI's Guardian and Recon products and its LLM red teaming layer now sit inside Palo Alto's AI security module. That is where LLM Guard's capabilities went commercially, which is the context for the archive. With Portkey announced in April 2026, Palo Alto is assembling the gateway layer too, positioning the AI gateway as the enforcement point for agent traffic.

Quick Comparison

A PII Redaction Test You Can Run Locally

PII stripping has the clearest requirement of any guardrail, so it is the one worth measuring rather than assuming. The usual first implementation is a handful of regular expressions. Here is that approach next to Presidio on the same synthetic support ticket, using presidio-analyzer 2.2.364 and spaCy 3.8.15.

Python
Copy
import re
from presidio_analyzer import AnalyzerEngine
from presidio_analyzer.nlp_engine import NlpEngineProvider
from presidio_anonymizer import AnonymizerEngine

TICKET = (
    "Hi, this is Marcus Delgado from Cleveland. My order never arrived. "
    "You can reach me at marcus.delgado@northgate-supply.com or (216) 555-0142. "
    "I paid with card 4111 1111 1111 1111 and my SSN on file is 401-55-9302. "
    "The request came from 198.51.100.24 if that helps."
)

# The regex layer most teams ship first.
NAIVE = {
    "EMAIL": r"[\w.+-]+@[\w-]+\.[\w.]+",
    "PHONE": r"\(?\d{3}\)?[\s.-]?\d{3}[\s.-]?\d{4}",
    "SSN": r"\b\d{3}-\d{2}-\d{4}\b",
    "CARD": r"\b(?:\d[ -]?){13,16}\b",
    "IP": r"\b(?:\d{1,3}\.){3}\d{1,3}\b",
}

def naive_findings(text):
    out = []
    for label, pattern in NAIVE.items():
        for m in re.finditer(pattern, text):
            out.append((label, m.group().strip()))
    return out

provider = NlpEngineProvider(nlp_configuration={
    "nlp_engine_name": "spacy",
    "models": [{"lang_code": "en", "model_name": "en_core_web_sm"}],
})
analyzer = AnalyzerEngine(nlp_engine=provider.create_engine(), supported_languages=["en"])
anonymizer = AnonymizerEngine()

results = analyzer.analyze(text=TICKET, language="en")

print("NAIVE REGEX FOUND:")
for label, val in sorted(set(naive_findings(TICKET))):
    print(f"  {label:8} {val}")

print("\nPRESIDIO FOUND:")
for r in sorted(results, key=lambda r: r.start):
    print(f"  {r.entity_type:14} {TICKET[r.start:r.end]!r:34} score={r.score}")

print("\nANONYMIZED:")
print(" ", anonymizer.anonymize(text=TICKET, analyzer_results=results).text)

The regex layer finds the five structured identifiers and stops there:

text
Copy
NAIVE REGEX FOUND:
  CARD     4111 1111 1111 1111
  EMAIL    marcus.delgado@northgate-supply.com
  IP       198.51.100.24
  PHONE    (216) 555-0142
  SSN      401-55-9302

Presidio finds those five plus the two a pattern can never catch, and also produces a few things you did not ask for:

text
Copy
PRESIDIO FOUND:
  PERSON         'Marcus Delgado'                   score=0.85
  LOCATION       'Cleveland'                        score=0.85
  EMAIL_ADDRESS  'marcus.delgado@northgate-supply.com' score=1.0
  ORGANIZATION   'marcus.delgado@northgate-supply.com' score=0.85
  URL            'marcus.de'                        score=0.5
  URL            'northgate-supply.com'             score=0.5
  PHONE_NUMBER   '(216) 555-0142'                   score=0.4
  CREDIT_CARD    '4111 1111 1111 1111'              score=1.0
  DATE_TIME      '1111'                             score=0.85
  ORGANIZATION   'SSN'                              score=0.85
  US_SSN         '401-55-9302'                      score=0.85
  IP_ADDRESS     '198.51.100.24'                    score=0.6

PERSON and LOCATION are the entire argument for a real PII engine. No regular expression recognizes "Marcus Delgado" as a name or "Cleveland" as a city, and those are exactly the fields most compliance conversations are about.

Now look at the noise, because this is the part vendor documentation skips. marcus.de matched as a URL at 0.5 confidence, because .de is a real top-level domain sitting inside the email address. The digits 1111 were tagged DATE_TIME at 0.85. The literal string "SSN" was labeled an ORGANIZATION. That last one is not cosmetic, because it corrupts the redacted text:

text
Copy
Hi, this is <PERSON> from <LOCATION>. My order never arrived. You can reach me
at <EMAIL_ADDRESS> or <PHONE_NUMBER>. I paid with card <CREDIT_CARD> and my
<ORGANIZATION> on file is <US_SSN>. The request came from <IP_ADDRESS> if that helps.

"My <ORGANIZATION> on file" is a redaction bug that would reach a customer. The fix is to stop asking for every entity type and set a floor on confidence, which takes two arguments:

Python
Copy
ENTITIES = [
    "PERSON", "LOCATION", "EMAIL_ADDRESS",
    "PHONE_NUMBER", "CREDIT_CARD", "US_SSN", "IP_ADDRESS",
]

results = analyzer.analyze(
    text=TICKET, language="en", entities=ENTITIES, score_threshold=0.4,
)

That produces seven findings, all correct, and clean output:

text
Copy
PERSON         'Marcus Delgado'                       score=0.85
  LOCATION       'Cleveland'                            score=0.85
  EMAIL_ADDRESS  'marcus.delgado@northgate-supply.com'  score=1.0
  PHONE_NUMBER   '(216) 555-0142'                       score=0.4
  CREDIT_CARD    '4111 1111 1111 1111'                  score=1.0
  US_SSN         '401-55-9302'                          score=0.85
  IP_ADDRESS     '198.51.100.24'                        score=0.6

Hi, this is <PERSON> from <LOCATION>. My order never arrived. You can reach me
at <EMAIL_ADDRESS> or <PHONE_NUMBER>. I paid with card <CREDIT_CARD> and my SSN
on file is <US_SSN>. The request came from <IP_ADDRESS> if that helps.

Two caveats on these numbers. I used en_core_web_sm to keep the install small, while Presidio's default configuration expects en_core_web_lg, which scores differently and generally better on names. And PHONE_NUMBER came back at exactly 0.4, sitting right on the threshold, which is your reminder to tune the floor against your own text rather than copying 0.4 out of a blog post.

The lesson transfers to every tool here: a guardrail on default settings with no threshold produces false positives, and a false positive in a redaction path is a product bug, not a security win.

How to Pick

A chatbot with rules about what it may discuss: NeMo Guardrails, using retrieval rails to inspect RAG chunks before they enter the context window.

Per-field validation on structured output: Guardrails AI, adopted one validator at a time.

A hard requirement that personal data never leaves your infrastructure: Presidio, self-hosted, with an explicit entity list and a tuned threshold.

An injection classifier you control: Llama Prompt Guard 2, 22M or 86M depending on your latency budget, with the Llama license read by whoever reviews licenses where you work.

Already on Bedrock and want something on today: enable the free word filters and regex-based PII filters first, measure, then add paid policies deliberately.

No adversarial tests at all: start with promptfoo in CI, not a runtime filter. Knowing which attacks work on your app beats a filter you cannot evaluate.

Inherited LLM Guard in a requirements file: Guardrails AI for the validator model plus Presidio for the anonymization scanners covers most of what people actually used it for.

Adding Guardrails to an Existing App This Week

1. Audit for the lethal trifecta. If the app has private data, untrusted content and outbound communication, removing one leg beats every tool here and costs nothing at runtime.
2. List every path text reaches your context window. User input, RAG documents, tool output, web fetches. EchoLeak came through retrieved email, so a list that stops at "the prompt" is not finished.
3. Normalize and decode before you inspect. Payloads hide in zero-width characters and are routinely base64-encoded to beat literal string checks. Our Invisible Character Remover strips the hidden characters, the Unicode Character Inspector shows the real code points, and the Base64 Encoder Decoder shows what the model will actually read.
4. Write the cheap deny list, then test it. Word filters and regex PII filters are free on Bedrock. Validate every pattern against adversarial samples in our Regex Tester first, because a wrong one either blocks real traffic or passes everything.
5. Add PII redaction with an explicit entity list. Use the corrected Presidio config above, not the defaults, and log what was redacted so you can tune the threshold on real traffic.
6. Put red teaming in CI. Run promptfoo against a preview environment so a system-prompt regression fails a build instead of reaching users.
7. Price it, then log every block. Run the text-unit math against your real traffic, remembering that guarding both sides doubles the billable evaluations. A guardrail you cannot audit is one you cannot tune.

Conclusion

This category consolidated in eighteen months. Lakera is Check Point's, Protect AI and Portkey are Palo Alto's, promptfoo is heading to OpenAI, and LLM Guard has been archived since July 2026. Check a repository's own status page before trusting any comparison post, this one included.

The maintained open layer is still strong: NeMo Guardrails and Guardrails AI are Apache 2.0 and active, Presidio is MIT and now community-owned, and Llama Prompt Guard 2 is a self-hosted classifier whose model card honestly publishes the gap between its .998 AUC and its 81.2 percent real-world prevention rate.

None of them closes prompt injection, because instructions and data still share one channel. Presidio produced a visible redaction bug on defaults in this very article, and Meta's own numbers show roughly a fifth of real attacks getting through. Spend the first hour on architecture and on which leg of the trifecta you can remove. Everything else is depth behind that decision.

Related DevToolLab Tools

• Invisible Character Remover - Strip zero-width and invisible characters that injection payloads hide in before your filters ever see the text.
• Unicode Character Inspector - Reveal the actual code points in a suspicious prompt when the text looks ordinary but behaves strangely.
• Base64 Encoder Decoder - Decode obfuscated payloads during triage so you are reading what the model reads.
• Regex Tester - Validate deny-list and PII patterns against adversarial samples before they enter a production request path.

Related Guides

• Best LLM Gateways - the enforcement point most teams end up putting guardrails behind, and where Portkey now sits
• Best AI Code Security Tools - the other half of AI security, scanning the code your assistant writes rather than the prompts it reads
• LLM Evals Guide - how to measure whether a guardrail change made your app better or just quieter
• Non-Human Identity Security - what the agent behind your guardrails is authenticating as, and why it probably has too much access

Licenses, prices and product lineups change often, and this category is consolidating quickly. Verify current terms and repository status on each vendor's own page before committing to a tool.