LLM guardrails in 2026: revisit NeMo Guardrails, Guardrails AI and LLM Guard before you ship another chatbot without input checks

An internal chatbot can look ready after a few happy-path demos. Then someone pastes a payroll CSV into the prompt, tries a jailbreak that worked on a public model last month, or asks the bot to call a tool with a destructive argument. The model does what models do: it tries to be helpful. The gap is not the model. The gap is the missing runtime checks.

In normal software we learnt to validate input before we trust it. With LLM features many teams have unlearnt that habit, because the request is natural language and “the system prompt should handle it” feels enough. Evaluation catches quality before you ship. Observability shows what happened after traffic arrives. Guardrails sit in the middle: they check input and output while the request is live. This post revisits three open-source options that teams still meet in that middle layer: NVIDIA NeMo Guardrails, Guardrails AI, and LLM Guard. The aim is not to crown a winner. The aim is to help you pick something you can maintain.

What a guardrail layer actually does

Before comparing tools, it helps to be clear about the job. A practical guardrail setup usually covers some mix of these:

• Input checks: reject or rewrite prompts that look like injection, off-topic requests, secrets, or PII you do not want into the model.
• Output checks: block or edit answers that leak data, go off policy, or fail a format you need.
• Topic and dialog control: keep an assistant inside the subjects and flows you approved.
• Retrieval checks: for RAG, filter or validate chunks before they reach the model.
• Tool and execution checks: for agents, validate tool names, arguments and results before side effects happen.

Eval tools (covered in an earlier post) decide whether a change is safe to merge. Observability tools decide whether production is drifting. Guardrails decide whether this request may proceed.

NeMo Guardrails: programmable rails and Colang

History and licence. The project lives at NVIDIA-NeMo/Guardrails. The repository was created in April 2023. The library is open source under the Apache License 2.0 (stated in the project README and pyproject.toml). The Python package on PyPI is nemoguardrails. The latest release at the time of writing is v0.24.1 (16 September 2026).

How it works. You describe policies as rails that run at different stages of an LLM interaction. Official docs list five rail types: input, retrieval, dialog, execution and output. Dialog and flow logic are often written in Colang, a Python-like modelling language for controllable dialogue. Colang 1.0 is the default; Colang 2.0 is supported as beta. You can call the library from Python (LLMRails) or run the included guardrails server with an OpenAI-style chat completions endpoint.

NVIDIA also documents a separate NeMo Guardrails microservice aimed at production on the NeMo microservices platform. That microservice is built on the same library and config model, but it is not the same install path as pip install nemoguardrails. For many Indian product teams the practical starting point is still the open-source library or its API server, unless you already run the wider NeMo platform.

Where it is strong.

• Teams that need more than a single toxicity filter: topic control, dialog flows, RAG retrieval rails, and tool or execution rails in one config story.
• Teams that want YAML plus Colang as the source of truth, portable between local development and a later server deployment.
• Teams that want community validators without reinventing them: NeMo documents an out-of-the-box Guardrails AI integration for input and output validators from that ecosystem.

What to watch.

• Rails that call models or external validators add latency. NeMo’s Guardrails AI integration notes that chaining multiple validators has a latency cost; cache and reuse help, but you still need a budget.
• Colang and multi-rail configs have a learning curve. Start with input and output rails before you rewrite the whole conversation in flows.
• Pin the package version and read release notes before you upgrade.

Guardrails AI: Guards, validators and structured output

History and licence. The project lives at guardrails-ai/guardrails. The repository was created in January 2023. It is licensed under Apache 2.0. The Python package is guardrails-ai. The latest release at the time of writing is v0.11.0 (14 August 2026). Guardrails AI the company also markets commercial and enterprise offerings around the open-source core; the framework itself can run without a hosted product.

How it works. The centre of the design is a Guard that wraps LLM calls with validators on the way in and the way out. Validators measure specific risks (PII, toxic language, jailbreak patterns, length, JSON shape, and many more). Historically many validators came through Guardrails Hub (guardrails hub install ...). As of 0.11.0, Guardrails-AI-owned validators move to public PyPI packages (for example pip install guardrails-ai-detect-pii) and import from the guardrails_ai namespace; the old hub CLI path remains temporarily with deprecation warnings. The same library also helps you get structured output, including Pydantic models, so validation and schema enforcement sit next to each other.

You can also run Guardrails Server (guardrails start) as a local HTTP service in front of your app. The project README announced that hosted remote inferencing for validators would be discontinued, with a planned cutoff of 25 August 2026, pushing teams toward local or self-managed validation endpoints.

Where it is strong.

• Python teams that want a library of ready validators and a clear Guard abstraction around existing LLM calls.
• Applications that need structured JSON or Pydantic objects, not only free text, with validation in the same path.
• Teams that may later plug the same validators into NeMo rails, using the documented NeMo integration.

What to watch.

• Validator packaging changed in 0.11.0. Update install and import paths before the hub shim is removed in a future major release.
• Remote Hub inference going away means you own model download, GPU or CPU cost, and endpoint ops for heavy validators.
• Do not confuse “many validators exist” with “we should enable all of them”. Each check costs time; pick the few that match your real risk.

LLM Guard: scanner toolkit, now archived

History and licence. protectai/llm-guard is a Python toolkit for scanning LLM inputs and outputs. It is licensed under the MIT License. The package on PyPI is llm-guard. The latest usable release at the time of writing is 0.3.16, published 19 May 2025.

How it works. LLM Guard is organised as input scanners and output scanners. You compose a pipeline that runs checks such as prompt injection, toxicity, secrets, PII anonymisation, topic bans, regex, and on the output side things like sensitive data, bias, malicious URLs, JSON validity and relevance. The mental model is closer to a security scanner chain than to a dialog policy language.

The maintenance signal that matters. On 8 July 2026 the maintainers merged a commit titled “Archiving Project” and marked the GitHub repository archived. The README warns that the project and its associated models on Hugging Face are no longer under active development or maintenance. The code remains MIT licensed and installable, but that is not the same as a production dependency with security fixes and scanner updates.

Where it was strong.

• Teams that wanted a focused scanner library without learning a dialog language.
• Clear split between sanitize or detect on the way in, and check or redact on the way out.

What to watch now.

• Do not start a new production chatbot on LLM Guard as your only long-term guardrail plan. Archived scanners do not track new jailbreak patterns or dependency CVEs for you.
• If you already run it, treat it as legacy: freeze the version, document the risk, and plan a move to a maintained stack (NeMo rails, Guardrails AI validators, or a commercial gateway your security team already owns).
• Forking is allowed under MIT, but a fork without owners is still an unmaintained scanner.

Side by side, without a table

Primary approach

• NeMo Guardrails: programmable rails (input, retrieval, dialog, execution, output) plus Colang flows; library and optional server or NVIDIA microservice path.
• Guardrails AI: Guard plus validators (and Hub or public PyPI validator packages); strong structured-output story.
• LLM Guard: input and output scanner pipeline.

Licence

• NeMo Guardrails: Apache 2.0.
• Guardrails AI: Apache 2.0.
• LLM Guard: MIT.

Maintenance (late 2026)

• NeMo Guardrails: actively released; latest v0.24.1 in September 2026.
• Guardrails AI: actively released; latest v0.11.0 in August 2026, with Hub packaging and remote-inference changes.
• LLM Guard: repository archived 8 July 2026; last PyPI release 0.3.16 from May 2025.

Best fit

• NeMo Guardrails: conversational apps that need policy, dialog control, RAG and tool rails in one place.
• Guardrails AI: Python apps that need composable validators and structured outputs, optionally reused inside NeMo.
• LLM Guard: study existing deployments or short experiments only; not a fresh production foundation.

We did not run latency benchmarks for this post. Official docs already warn that stacking validators costs time; measure on your own traffic shape before you put five model-backed checks on every request.

A practical way to start this week

For an Indian engineering team shipping an internal assistant (HR FAQ, IT helpdesk, sales knowledge bot), a calm sequence looks like this:

1. Write down the risks that would actually hurt: prompt injection into internal docs, PII in prompts, off-topic legal or medical advice, unsafe tool calls. 2. Add cheap deterministic checks first: max length, allow-listed tools, regex for secrets, “must not answer” topic list. 3. Put those checks on the request path, not only in a notebook. Log allow, rewrite and block decisions. 4. If you need dialog or agent control, prototype with NeMo Guardrails input and output rails before you invest in full Colang flows. 5. If you mainly need validators and structured JSON, start with Guardrails AI Guards and two or three validators that match your risks. 6. Wire the same red-team cases into your eval suite (promptfoo or similar) so a guardrail change is tested like a code change. 7. If LLM Guard is already in the repo, open a ticket to replace it; do not expand its use.

How to choose

• If you are building a multi-turn assistant with RAG or tools and want one policy config, start with NeMo Guardrails.
• If you are a Python team wrapping existing LLM calls and need validators plus schema, start with Guardrails AI.
• If someone proposes LLM Guard for a greenfield bot in late 2026, push back and ask for a maintained alternative.
• Many teams will combine NeMo for orchestration with Guardrails AI validators for specific checks. That combination is documented; it is not an exotic idea.

Revisit checklist

• Do we validate user input before it reaches the model, or only hope the system prompt is enough?
• Do we check model output for PII, policy and format before the user sees it?
• For agents, do tool arguments pass an allow list before execution?
• Are guardrail packages pinned, and do we know which ones are still maintained?
• Have we measured the latency of every model-backed validator we enabled?
• Do blocked and rewritten requests show up in our observability tools?
• Does every successful jailbreak or leak become both a regression test and a new rule?

Shipping a chatbot without input checks is the same habit as shipping an API without validation. Revisit that habit. Put runtime guardrails next to eval and observability, practise on a small set of real risks, and apply the checks on every request, not only on the demo script.