Which NeMo Guardrails, Guardrails AI or LLM Guard fits your LLM app
Start with the risks you must block and how much Colang or Python you are willing to maintain. LLM Guard was archived on July 9, 2026 and receives no security fixes, so it should not be chosen for a new rollout. If your team already runs it, plan a supported migration and keep the existing deployment limited to fixes you can apply yourself. Its MIT license and its 15 input and 20 output scanners are reasons teams adopted it, not reasons to start a new deployment on an unmaintained project. Confirm the pinned PyPI version and the Python 3.10 to 3.12 range it requires before you change anything in production, because the last PyPI release is from May 2025.
Choose NeMo Guardrails when the main requirement is conversational policy: keeping a support assistant on topic, steering dialog flows, and running input, retrieval, execution and output rails from one config.yml with Colang files. It is Apache-2.0 licensed, with v0.24.1 released on September 16, 2026. The cost is the Colang learning curve and a migration review if you adopt Colang 2.x, since NVIDIA says converted configurations still need manual review. Choose Guardrails AI when the main requirement is validating outputs against specific checks, such as regex matching or toxicity detection from Guardrails Hub, or forcing responses into a Pydantic model. Its v0.11.0 release on August 14, 2026 is Apache-2.0 licensed. Its cost is writing and reviewing validators, plus the chain order you choose.
Before you decide, run a short test against your own prompt injection and data leakage cases with each candidate in the request path, and measure the added latency at your expected volume. Ask each vendor or maintainer which checks are covered by default and which need a model download or an external service, because that decides your infrastructure footprint in an air-gapped or regulated environment. A mixed design is possible: dialog policy in NeMo Guardrails and validated output schemas in Guardrails AI, provided you test their interaction in one pipeline.
Which guardrail fits which scenario
This table maps common team situations to the guardrail option that fits best and the condition that makes that fit hold. Read each row against your own risks, then check the alternative column to see when another option is the better pick. The main takeaway is that the choice depends less on features than on whether you need dialog control, schema validation, or a maintained codebase for regulated operation.
| Scenario | Best fit | Why |
|---|---|---|
| Policy-heavy chat assistant needing topic and dialog control | NeMo Guardrails | Colang dialog and topic rails define allowed conversation flows directly. This holds if your policy is about what the assistant may discuss and how it steers users. Pick Guardrails AI if the main risk is malformed or unsafe field content rather than conversation scope. |
| API service needing schema-validated output | Guardrails AI | Validators from Guardrails Hub can be chained on inputs and outputs, and structured output can match Pydantic models. This fits when downstream systems break on bad fields. Pick NeMo Guardrails if you mainly need to steer multi-turn dialog. |
| Existing LLM Guard deployment already in production | Keep LLM Guard only for support, then plan a migration | The repository was archived on July 9, 2026 and receives no security fixes, so run it under your own patching and monitoring. Plan migration to NeMo Guardrails or Guardrails AI, and confirm which scanner outputs your controls depend on before replacing them. |
| Regulated team needing maintained, auditable guardrail code | NeMo Guardrails or Guardrails AI | Both are Apache-2.0 and actively released in 2026, which supports a maintained dependency baseline. Confirm with your assessor which control evidence you need, since neither library issues certifications. Avoid building new controls on LLM Guard, which is archived. |
| Team mixing dialog rules with input and output scanning | NeMo Guardrails, with validators added where needed | Input, dialog, output, retrieval and execution rails sit in one configuration model. This fits teams with RAG or tool use. Confirm how each scanner or validator is wired in, since integration effort grows with each added component. |
| Team that must keep Python version pinned to a narrow range | Check before choosing | NeMo Guardrails supports Python 3.10 through 3.13. The LLM Guard PyPI release requires Python below 3.13. Confirm the runtime your platform team supports before committing to either library. |
How each option works in the request path
NeMo Guardrails wraps the conversation flow itself. Teams define five rail types: input rails that inspect the user message, dialog rails that steer the conversation through defined flows, retrieval rails that check RAG chunks, execution rails that govern custom actions and tools, and output rails that check the model's reply before it reaches the user. Behavior is set in a config.yml file, optional Python actions, and Colang files. The library can be called from Python, or it can run as a server that loads configurations from a folder and exposes a /v1/chat/completions endpoint, so an application can point an OpenAI-style client at it.
- Rail placement: Input and output rails sit on either side of the model call, while dialog and execution rails sit inside the flow that decides which action runs.
- Colang versions: Colang 1.0 is the default, and Colang 2.0 is also supported. Confirm which version your team standardizes on before writing policies.
- Server mode: The server loads a configuration folder and exposes an HTTP API, and the provided Dockerfile builds a server image.
- Built-in checks: Self-check moderation, fact-checking, hallucination detection, jailbreak and injection detection, and topic safety models are available as library components.
- Migration: The
nemoguardrails converttool helps move Colang 1.0 configurations to 2.x, but NVIDIA says converted files still need manual review.
Confirm which rail types and built-in models your use case needs, and test latency on your own hardware, because each enabled rail adds work to the request path.
Guardrails AI places guards around the model call, with an input guard before the prompt is sent and an output guard on the response. Each guard is built from validators published on Guardrails Hub, such as regex matching or toxicity detection. Validators are installed separately after pip install guardrails-ai and can be chained together. The same library can also generate structured output that matches a Pydantic model, using function calling or prompt optimization, so it covers both checking and shaping responses.
- Validator model: Each check is a discrete validator, so a policy is a chain of named checks rather than a conversation flow.
- Hub dependency: Validators come from Guardrails Hub, so the team needs a process to review, pin and approve each validator it installs.
- Structured output: Pydantic models define the expected shape of responses, which helps downstream systems that parse model output.
- Service mode: Running
guardrails startlaunches a standalone Flask REST service, and applications call it through the OpenAI SDK. - Custom validators: Teams can write their own validators and contribute them to the Hub.
Confirm which validators are maintained and how each one is versioned before you rely on it for a control, and check the anonymous metrics choice that guardrails configure offers during setup.
LLM Guard works as a set of scanners. Input scanners inspect prompts before the model runs, and output scanners inspect responses afterward. The project documents 15 input scanners, including Anonymize, Ban Topics, Invisible Text, Prompt Injection, Secrets, Token Limit and Toxicity, and 20 output scanners, including Deanonymize, Factual Consistency, JSON, Malicious URLs, No Refusal, Sensitive and Toxicity. It can be used as a Python library installed with pip or deployed as an API server. Its scanners are chosen per request path, so the same scanner set can sit in front of a chat endpoint or behind an application.
- Scanner model: Each scanner returns a judgment on one risk type, so coverage is defined by which scanners are enabled.
- Input coverage: Prompt injection, secrets and anonymization checks run before the model call.
- Output coverage: Sensitive data, malicious URLs and output format checks run on responses.
- Deployment: The library runs inside your application, and the API server option runs it as a separate service.
- Archive status: The repository was archived on July 9, 2026 and receives no security fixes, so existing deployments need a migration plan.
For any existing deployment, confirm the scanner versions in use, record the archive status in your risk register, and plan a move to a maintained guardrail. No new LLM Guard rollouts are recommended.
Prompt injection, data leakage and output checks across the three
This table compares how each library handles injection, sensitive data, output checks, structured output, deployment, Python support, maintenance and license. Read the rows as questions to put to each project, since a supplied fact is marked where it exists and a confirmation item is marked where it does not. The main takeaway is that LLM Guard's scanner coverage is documented but the project no longer receives fixes, which shifts the decision toward NeMo Guardrails or Guardrails AI for new work.
| Capability | NeMo Guardrails | Guardrails AI | LLM Guard |
|---|---|---|---|
| Prompt injection detection | Library includes jailbreak and injection detection; confirm the models and rails you enable | Via Guardrails Hub validators; confirm which injection validator fits your input path | Documents a Prompt Injection input scanner among 15 input scanners |
| Data leakage and sensitive data | Confirm coverage for PII and secrets through custom actions or third-party integrations | Via Guardrails Hub validators such as regex matching; confirm sensitive-data validators you need | Documents Anonymize, Secrets and Sensitive scanners; no new fixes since archive |
| Output validation | Output rails plus self-check output moderation and fact-checking | Output guards built from chained validators | Documents 20 output scanners, including Factual Consistency, JSON and Malicious URLs |
| Dialog and topic control | Colang dialog and topic rails configured in config.yml | Not a conversation-flow feature; confirm if you need it | Documents Ban Topics as an input scanner; no dialog rails |
| Structured output | Confirm whether your use case needs it; not described in supplied facts | Generates output matching Pydantic models using function calling or prompt optimization | Documents a JSON output scanner, not model-bound generation |
| Deployment as a server | Guardrails server exposing /v1/chat/completions; Dockerfile provided | Standalone Flask REST service started with guardrails start | Deployable as an API server or Python library |
| Python version support | Python 3.10, 3.11, 3.12 and 3.13 | Confirm the current range in the Guardrails AI README before you pin | Last PyPI release 0.3.16 requires Python 3.10 or newer but below 3.13 |
| Maintenance status | Active; v0.24.1 released September 16, 2026 | Active; v0.11.0 released August 14, 2026 | Archived July 9, 2026; no longer maintained or receiving security fixes |
| License | Apache-2.0 | Apache-2.0 | MIT |
What the licenses and maintainers mean for your risk
License type tells you what you may do with the code, but maintenance status tells you whether fixes will arrive. For this shortlist, the gap between an active project and an archived one matters more than the license label, so check both before you commit.
NeMo Guardrails under Apache 2.0
NeMo Guardrails is Apache-2.0 licensed and developed in the NVIDIA-NeMo/Guardrails repository, with v0.24.1 published on September 16, 2026. For a regulated team, this means you can self-host and modify the library with a permissive license, and you can watch the release history for security-relevant changes. Confirm your own patch window with the maintainer's release cadence and your internal change process, since a library update still needs regression testing against your Colang policies.
Guardrails AI under Apache 2.0
Guardrails AI is also Apache-2.0 licensed, with v0.11.0 published on August 14, 2026, after v0.10.2 on June 4 and v0.10.0 on April 3, 2026. Its validators come from Guardrails Hub, which are installed separately, so your license review should cover each validator you chain as well as the core package. Ask which validators carry their own license terms before you approve a production build.
LLM Guard archived with no fixes
LLM Guard is MIT licensed, but its repository was archived on July 9, 2026, and the README states the project and its Hugging Face models are no longer maintained. Archiving means no security fixes will ship, so a vulnerability found in a scanner or its models stays open. Existing deployments need a documented exit plan and a compensating control such as an additional scanning layer, and new rollouts should not start on it.
Last LLM Guard PyPI release
The last LLM Guard release on PyPI is 0.3.16, uploaded on May 19, 2025, and it requires Python 3.10 or newer but below 3.13. A pinned version of that package will not receive upgrades through the normal index, and the Python constraint can conflict with a platform that has moved to Python 3.13. Inventory every environment that pins llm-guard and record the version in your software bill of materials, so audit evidence shows which build runs in production.
NeMo Guardrails Python support
NeMo Guardrails supports Python 3.10, 3.11, 3.12 and 3.13, which covers the interpreter range that LLM Guard's last release excluded at 3.13 and above. Platform teams can align the runtime across services without pinning an older interpreter. Confirm the supported versions against the release you deploy, because a container base image or an internal Python standard can still block an upgrade.
How the three fit together in a production stack
The first decision is where each control runs in the request path, because the three options do different work at different points. Input checks sit before the model and screen the prompt for injection attempts, banned topics or sensitive data. LLM Guard's documented input scanners, including Prompt Injection, Secrets, Anonymize and Invalid Text-style checks, fit this position, but because the project is archived, a new deployment should not depend on it. NeMo Guardrails places its input rails in the same spot inside the orchestration layer, and its dialog rails (configured in Colang) decide how the conversation proceeds once a message passes. Output checks sit after generation. Guardrails AI validators, chained from Guardrails Hub, are the natural fit for checking responses and for enforcing a Pydantic-shaped structure on model output.
Combining the options is possible, but each one you add creates its own policy files, configuration keys and test cases. A team running NeMo Guardrails for dialog control, Guardrails AI for output validation and an input scanner for prompts maintains three sets of rules that can disagree about what is blocked. Before you adopt a second or third layer, write down which control owns each risk category, such as prompt injection, data leakage, toxicity or malformed output, so that one tool is the authority for each. Then confirm that the layers do not block the same request twice in ways that confuse logs and incident response.
Latency depends on your model, hardware, rail count, validators chosen and whether any check calls another model, so no general figure in this comparison should be treated as a benchmark for your workload. Build a test harness that sends representative prompts, including benign traffic at your real volume, through each candidate chain, and measure added time at the median and tail percentiles. Run the same harness after each policy change. Ask the vendor or your integration partner to document which checks make network or model calls, since those calls usually dominate the overhead.
What drives the cost of running each option
Running any of the three guardrail options costs more in people and testing than in software, since all three are open source. The cards below separate the recurring work (policies, models, latency, tests, upgrades) from the one-time work, so you can ask each vendor or implementation partner for a quote that names who does what.
Policy authoring and maintenance
NeMo Guardrails expresses dialog and topic policies in Colang, Guardrails AI expresses checks as validators chained into guards, and LLM Guard expresses them as scanner selections and thresholds. Someone must write, review and retire these rules as your product and attack patterns change. Ask for the expected number of rules or validators in scope, who owns them after handover, and whether the quote covers policy review cycles.
Model and classifier dependencies
NeMo Guardrails includes self-check moderation, fact-checking, hallucination detection and NVIDIA content safety and topic safety models, so some rails depend on model calls. Guardrails AI validators come from Guardrails Hub and may pull their own models, and LLM Guard scanners load models from Hugging Face. Each model adds hardware, a license to review and a model to update. Confirm which models each rail or validator needs, where they run, and who pays for the GPUs or API calls that serve them.
Latency and infrastructure
Every input and output check sits in the request path, so added latency and compute scale with traffic. A dialog rail that calls a model per turn costs more to run than a regex or scanner pass. Ask the implementer to benchmark the chosen rails against your expected request volume in your environment, and to state where the service runs, how many replicas it needs and how it is monitored.
Testing guardrails in CI
A guardrail is only as good as its regression tests. Teams need a set of known-bad prompts, expected refusals and false-positive cases that run on every change to rails, validators or models. Budget for building that test corpus, wiring it into your pipeline and reviewing failures. Ask whether the quote includes a test suite handed over with the system, and who maintains it when a rail changes behavior.
Upgrade and migration work
Upgrades carry a real cost on each platform. NVIDIA documents a Colang 1.0 to 2.x migration using the nemoguardrails convert tool and says converted configurations still need manual review. Guardrails AI releases move quickly, and LLM Guard is archived, so existing deployments need a planned exit. Ask for an upgrade path, the regression evidence delivered with each change, and the cost of a move to a maintained option if the current one stops receiving fixes.
NVIDIA platform dependency
The open-source NeMo Guardrails library is Apache-2.0 licensed and runs without the platform. If you later consider the NeMo Guardrails microservice, a production container deployed on Kubernetes with Helm, you take on a second cost layer: cluster operations, the platform itself and any NVIDIA support terms. Ask for a separate quote for each, and confirm which parts of the platform your organization would actually need.
What implementing each option actually involves
Effort depends on the policy set and the team more than on the library, so start by writing down which rails you need (input, dialog, output, retrieval, execution) before choosing one. NeMo Guardrails is configured through a config.yml file, optional Python actions and Colang files. Colang 1.0 is the default, and Colang 2.0 is also supported. If your team already has Colang 1.0 policies, NVIDIA's migration guide describes a conversion path using the nemoguardrails convert tool, and it states that converted configurations still need manual review. Budget engineering time for that review and for testing each converted rail against your own prompts, not just for running the tool.
Guardrails AI is installed with pip, and its validators come from Guardrails Hub, so each validator you chain (for example, regex matching or toxicity detection) is a separate install and a separate dependency to track. Confirm which validators your policy needs, whether your security team accepts their source and maintenance status, and whether your build pipeline can pull them from inside your network. If you plan to expose the library to other services, check the standalone service mode, which runs through guardrails start and is called through the OpenAI SDK. Decide early whether anonymous metrics reporting, which guardrails configure asks about, is permitted in your environment.
LLM Guard is archived and no longer maintained, so the work here is supporting existing deployments, not starting new ones. Inventory every place it runs, including the Python library installs and any API server deployments, and record the pinned version. The last PyPI release is 0.3.16, and it requires a Python version that NeMo Guardrails and Guardrails AI may not share, so confirm your runtime before any migration plan. Plan the move to a maintained option as a project with its own test set: replay your recorded prompts and responses against the new rails, compare what each one blocks, and keep the old scanners running in parallel until results match your risk requirements. Confirm with your security and compliance leads which findings must be documented during the cutover.
Questions buyers ask before choosing or hiring help
Which runtime guardrail option should a regulated bank or healthcare team choose?
For most regulated teams, NeMo Guardrails or Guardrails AI is the starting point, because both are Apache-2.0 and actively released, while LLM Guard is archived. Choose NeMo Guardrails when you need to control conversation flow, topics and dialog behavior with a reviewable policy language (Colang), and when your team can own that language. Choose Guardrails AI when your main need is validating inputs and outputs with validators from Guardrails Hub and enforcing structured output that matches Pydantic models. In both cases, the deciding factors are the specific risks you must block, the latency your request path can tolerate, and who will maintain the policies after launch. Pair either option with a testing tool such as garak or promptfoo so you can show evidence that the controls work.
Can we still use LLM Guard, and what does the archive mean for us?
You can keep running an existing LLM Guard deployment, but the project was archived on GitHub on July 9, 2026, and its README states it is no longer under active development or maintained. That means no security fixes will be published upstream. The last PyPI release, 0.3.16, was uploaded on May 19, 2025, and requires Python 3.10 or newer but below 3.13. For existing deployments, the practical steps are to inventory where it runs, record the pinned version, decide on compensating controls and plan a migration to a maintained option. DeployOpen does not recommend new LLM Guard rollouts. Confirm with your security team how an unmaintained dependency is treated under your own vulnerability management policy.
How long does a guardrail implementation take, and what drives the timeline?
No fixed duration can be given for a generic deployment, so ask for a timeline in the written scope. The main drivers are the number of applications and entry points that need guarding, how many risk categories you must block, whether you run the open-source library inside your own application or a separate service, and how much policy tuning the business expects. For NeMo Guardrails, the Colang 1.0 to 2.x migration and the need for manual review of converted configurations add time if you have existing policies. For Guardrails AI, the time depends on which validators you select and whether you write custom ones. Evaluation against your own test cases usually takes longer than the initial setup, so plan for it explicitly.
What cost components should we expect, and what should we request in a quote?
The software in this comparison is open source, so the costs you pay are for people and infrastructure. Expect one-time costs for requirements, policy design, integration into your application, testing and documentation. Expect recurring costs for model and inference hosting, monitoring, policy maintenance, upgrades to new releases and periodic re-testing. DeployOpen does not publish a price list. A quote follows from written scope, so request a list of deliverables, the systems in scope, the risk categories to be covered, the environments (cloud accounts, data centers or air-gapped networks), the testing approach, the handover documentation, and what is excluded. Ask whether ongoing support or upgrades are priced as a retainer separately from the initial fixed-scope work.
Can an internal team run NeMo Guardrails or Guardrails AI without outside help?
Yes, it is possible for a team with Python skills and someone who can own policy design, since both libraries are open source and installable with standard tooling. NeMo Guardrails requires learning Colang, its configuration files (config.yml) and optional Python actions, and it supports Python 3.10 through 3.13. Guardrails AI requires choosing validators from Guardrails Hub, installing them separately and wiring them into guards. The harder work is ongoing: keeping policies current, testing for bypasses, handling upgrades such as v0.24.1 for NeMo Guardrails or v0.11.0 for Guardrails AI, and producing evidence for an assessor. Assess whether your team has that capacity before deciding between in-house and outside help. DeployOpen can plan, implement, harden and document the setup, or support it through a retainer.
Does NeMo Guardrails require NVIDIA hosted services to run?
No. The NeMo Guardrails open-source library is Apache-2.0 licensed and can be called through its Python API or run as a guardrails server that loads configurations from a folder and exposes an HTTP API. A Dockerfile is provided to build a server image, so you can host it in your own infrastructure. NVIDIA also offers a separate NeMo Guardrails microservice, a production container image built on the same configuration model and deployed on Kubernetes with Helm. That microservice is an option for teams who want it, not a requirement. Confirm the current support terms, and any platform dependencies, with NVIDIA before you plan around the microservice.
How does the Colang migration affect our plan?
Colang 1.0 is the default in NeMo Guardrails, and Colang 2.0 is also supported, so the migration is a decision about when and whether to move. NVIDIA documents a migration path using the nemoguardrails convert tool, and states that converted configurations still need manual review. Plan for a review step, regression tests against your existing dialog and topic rails, and an update to your runbooks. If you are starting fresh, decide early which Colang version your team will standardize on, because policies written in one version will not automatically carry over. Ask for the migration effort to be listed as its own line item in any quote.
How DeployOpen works on this
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For this decision, we help you choose between NeMo Guardrails, Guardrails AI and LLM Guard, then implement the option that fits your risks and systems.
How we scope
- We start by listing the risks your LLM application must block, such as prompt injection, data leakage and unsafe output.
- We map which request path, model endpoints and existing services the guardrail must sit in front of.
- Engagements are fixed-scope, so deliverables, timelines and exclusions are agreed in writing before work begins.
How we build
- We implement the chosen guardrail inside your infrastructure, with configuration kept in version control.
- We wire the guardrail into your CI pipeline and test it against the attack categories agreed in scope.
- Where a tool is archived or lacks maintenance, we document the risk and recommend a maintained alternative instead.
How we hand over
- You receive configuration, policy files, test results and architecture documentation covering the agreed scope.
- We document how to confirm the license, version and maintainer status of each component before upgrading.
- Your team gets a walkthrough of how to update policies, add validators or rails, and rerun the tests.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
- Retainer support can cover version upgrades and re-running the agreed attack tests after library changes.
- Ask any vendor or DeployOpen quote to itemize build, testing, documentation and retainer effort separately.
