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. ![The protectai/llm-guard repository on GitHub showing a banner reading "This repository was archived by the owner on Jul 9, 2026. It is now read-only", a Public archive badge, 3.2k stars and an MIT license](/images/blog/best-llm-guardrails-tools/llm_guard_archived.webp) 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](https://www.prnewswire.com/news-releases/palo-alto-networks-completes-acquisition-of-protect-ai-302510757.html). Around the same stretch, Check Point [announced it was acquiring Lakera](https://www.checkpoint.com/press-releases/check-point-acquires-lakera-to-deliver-end-to-end-ai-security-for-enterprises/) on September 16, 2025, reportedly for about $300 million. Then Palo Alto [announced its intent to acquire Portkey](https://www.paloaltonetworks.com/company/press/2026/palo-alto-networks-to-acquire-portkey-to-secure-the-rise-of-ai-agents) 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](https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf) 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](https://arxiv.org/abs/2509.10540) 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 arXiv abstract page for "EchoLeak: The First Real-World Zero-Click Prompt Injection Exploit in a Production LLM System", describing CVE-2025-32711 in Microsoft 365 Copilot and the chain of bypasses including evading the XPIA classifier and abusing a Microsoft Teams proxy](/images/blog/best-llm-guardrails-tools/echoleak_paper.webp) 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](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/) 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](https://github.com/NVIDIA-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`. ![The Guardrails repository on GitHub under the NVIDIA-NeMo organization, showing 6.9k stars, 802 forks, a commit from 13 hours ago and a description of an open-source toolkit for adding programmable guardrails to LLM-based conversational systems](/images/blog/best-llm-guardrails-tools/nemo_guardrails_repo.webp) 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](https://github.com/guardrails-ai/guardrails) 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. ![The guardrails-ai/guardrails repository on GitHub, an Apache 2.0 licensed framework for adding guardrails to large language models](/images/blog/best-llm-guardrails-tools/guardrails_ai_repo.webp) 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](https://github.com/data-privacy-stack/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. ![The presidio repository on GitHub under the data-privacy-stack organization, showing 10.4k stars, an MIT license, and a description covering detection, redaction, masking and anonymization of sensitive data across text, images and structured data](/images/blog/best-llm-guardrails-tools/presidio_repo.webp) 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](https://presidio.dataprivacystack.org/project_transition/) 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](https://github.com/meta-llama/PurpleLlama/blob/main/Llama-Prompt-Guard-2/86M/MODEL_CARD.md) 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 Llama Prompt Guard 2 86M model card on GitHub, showing that the models use a modified tokenizer to resist adversarial tokenization attacks such as fragmented tokens or inserted whitespace, and that the base models mDeBERTa-base and DeBERTa-xsmall are open-source MIT-licensed models from Microsoft](/images/blog/best-llm-guardrails-tools/prompt_guard_2_card.webp) 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](https://github.com/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](https://aws.amazon.com/bedrock/pricing/). 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 Azure AI Content Safety pricing page for Central US in USD, showing a free web tier of 5,000 text records and 5,000 images per month, and a standard web tier at $0.38 per 1,000 text records and $0.75 per 1,000 images, both covering Text, Prompt Shields, protected material detection and groundedness detection](/images/blog/best-llm-guardrails-tools/azure_content_safety_pricing.webp) 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 | Tool | License | Layer | Self-hosted | Status | |---|---|---|---|---| | **[NeMo Guardrails](https://github.com/NVIDIA-NeMo/Guardrails)** | Apache 2.0 | Input, dialog, retrieval, output | Yes | Active, v0.23.0 | | **[Guardrails AI](https://github.com/guardrails-ai/guardrails)** | Apache 2.0 | Input and output validators | Yes | Active, v0.10.2 | | **[Presidio](https://github.com/data-privacy-stack/presidio)** | MIT | PII detection and redaction | Yes | Active, 2.2.364 | | **[Llama Prompt Guard 2](https://github.com/meta-llama/PurpleLlama/blob/main/Llama-Prompt-Guard-2/86M/MODEL_CARD.md)** | Llama license, MIT base model | Injection and jailbreak classifier | Yes | Active | | **[promptfoo](https://github.com/promptfoo/promptfoo)** | MIT | Red teaming in CI | Yes | Active, OpenAI acquiring | | **[Bedrock Guardrails](https://aws.amazon.com/bedrock/pricing/)** | Commercial | Input and output | No | From $0.10 per 1k text units | | **Azure Prompt Shields** | Commercial | Input and output | No | $0.38 per 1k text records | | **Lakera Guard** | Commercial | Runtime prompt firewall | No | Check Point, post-acquisition | | **LLM Guard** | MIT | Input and output scanners | Yes | **Archived July 2026** | ## 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 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 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 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 Hi, this is from . My order never arrived. You can reach me at or . I paid with card and my on file is . The request came from if that helps. ``` "My `` 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 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 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 from . My order never arrived. You can reach me at or . I paid with card and my SSN on file is . The request came from 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](/tools/invisible-character-remover) strips the hidden characters, the [Unicode Character Inspector](/tools/unicode-inspector) shows the real code points, and the [Base64 Encoder Decoder](/tools/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](/tools/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](/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](/tools/unicode-inspector)** - Reveal the actual code points in a suspicious prompt when the text looks ordinary but behaves strangely. - **[Base64 Encoder Decoder](/tools/base64-encoder-decoder)** - Decode obfuscated payloads during triage so you are reading what the model reads. - **[Regex Tester](/tools/regex-tester)** - Validate deny-list and PII patterns against adversarial samples before they enter a production request path. ## Related Guides - [Best LLM Gateways](/blog/best-llm-gateways) - the enforcement point most teams end up putting guardrails behind, and where Portkey now sits - [Best AI Code Security Tools](/blog/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](/blog/llm-evals-guide) - how to measure whether a guardrail change made your app better or just quieter - [Non-Human Identity Security](/blog/non-human-identity-security-guide) - 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.*

llm guard alternatives

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