LLM guardrails mapped to the OWASP Top 10 for LLM Applications

No. A guardrail inspects prompts and responses at runtime, so it cannot tell whether the model weights themselves were tampered with. LLM03 Supply Chain and LLM04 Data and Model Poisoning need controls before deployment: model provenance checks, pinned versions with recorded checksums, a reviewed model registry, and an approval step before any new weights or fine-tuned models reach production. For training and fine-tuning data, the controls are data pipeline controls: source allowlists, access logs, and review of what enters the corpus. Guard validators such as toxicity or regex checks can catch some symptoms of a poisoned model, but they reduce only a slice of the risk. Ask your implementation partner which model sources are allowed, how weights are verified, and who signs off on each change. Keep a record of each approval, because it becomes evidence for later reviews.

Output filtering reduces leakage only partly. An output rail can match known phrases from the system prompt, but a model can paraphrase, translate or encode the instructions, and a filter will miss those variants. The stronger control is design: keep secrets, credentials and internal routing logic out of the system prompt, and enforce access decisions in application code or the AI gateway rather than trusting the model to withhold them. Treat the system prompt as public. Then use canary strings and red-team probes to check whether leakage still happens. garak can run prompt-extraction style probes against an endpoint, and its JSONL report gives you a record of each attempt. Confirm with your partner exactly which probes they run and how often they repeat them.

The weakness sits in the retrieval layer, so the fix belongs there. A guard that reads the final answer cannot know whether a chunk should have been retrieved for this user at all. The controls are retrieval access control: each chunk carries its source permissions, the vector search filters by the caller's identity before results reach the model, and tenant or department boundaries are enforced in the index, not in the prompt. Embedding pipelines also need controls: validated sources, versioned embedding models, and rebuild procedures when permissions change. Retrieval rails in NeMo Guardrails can inspect chunks for injected instructions, which covers a related slice. Ask whether your vector database supports metadata filtering on identity claims, and whether deletions in the source system propagate to the index.

Guardrails reduce some hallucinations but do not eliminate misinformation. NeMo Guardrails includes fact-checking and hallucination detection, and Guardrails AI can run validators that check structure or known facts. These checks help where an answer can be compared with a trusted source, such as a retrieved passage. They cannot judge correctness in general. LLM09 Misinformation is addressed mainly through evaluation: a fixed set of test questions with expected answers, grounding requirements that force citations, and human review for high-impact outputs. Track evaluation results over model and prompt versions. Ask your partner how the evaluation set is built, who owns it, and what happens when answers drift after a model update.

Guardrails can limit some tool use but cannot replace permission design. Execution rails can check a proposed tool call against an allowlist, and an output rail can require human confirmation for specific actions. Those checks handle part of LLM06 Excessive Agency. The rest depends on scoped credentials: each tool should use a service identity that holds only the permissions its task needs, with read and write access separated. Limit the rate and value of actions, and log every call for review. If a credential can delete records, a guard that misreads a request still leaves that capability in place. Ask your partner for a permission inventory per tool and a test that confirms the agent cannot exceed it.

Test each guard against known attack sets, measure the result, and repeat the test after every change. garak, an Apache 2.0 tool from NVIDIA, probes models for prompt injection, data leakage, jailbreaks and other weaknesses. It runs from the command line, can test models through a REST endpoint configured in YAML, and writes a JSONL report of each attempt and its evaluation. By default it makes 5 generations per prompt and marks a probe as FAIL when any attempt produces undesirable output. Run the same suite against the bare model and against the guarded endpoint, then compare. Testing is recurring work, so retainers or internal teams should cover it. Ask whether the partner tests the guardrail configuration itself, not only the model.

The cost comes from work outside the guardrail product. Guardrail software under Apache 2.0 has no license fee, but the other controls need people and infrastructure: model provenance and approval processes, identity and permission design for retrieval and tools, evaluation datasets, and recurring red-team runs. Some of this is one-time setup, such as the permission model and the evaluation set. Other parts recur, such as re-running tests after each model or prompt change and reviewing new model versions. Cost rises with the number of tools, data sources and models. Ask for a quote that lists each control, who performs it, what is delivered, and what the recurring test cycle includes. DeployOpen does not publish prices, and a quote follows from a written scope.

Many teams can handle parts of this work internally, but the split is uneven. Guard configuration, garak test runs and logging are within reach of a platform team that can write Python and operate containers. Retrieval permission design, identity integration and model provenance need collaboration between security, data owners and platform engineering. Evaluation sets need domain experts who can judge correct answers. A practical split is to keep ownership of policies and approvals internal while a partner plans, implements and documents the controls, then supports the recurring tests. DeployOpen implements and tests self-hosted platforms in the client's own environment, and most engagements are fixed-scope with the scope agreed in writing first.

No. Runtime guardrails reduce some of the OWASP LLM Top 10 2025 risks, mainly LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure and LLM05 Improper Output Handling, but they do not cover the whole list. Risks such as LLM03 Supply Chain, LLM04 Data and Model Poisoning, LLM06 Excessive Agency, LLM08 Vector and Embedding Weaknesses and LLM10 Unbounded Consumption need controls in identity, tool permissions, data pipelines, rate limits and model sourcing. Map each risk to the controls that address it, then record which gaps remain open.

The main drivers are policy tuning, test volume, self-hosted classifier compute and gateway integration. Policy tuning is ongoing work: rails written in Colang for NeMo Guardrails or validators chosen from Guardrails Hub need examples from your own traffic to reduce false positives. Test volume grows with each risk you cover, because garak runs five generations per prompt by default, so a broad probe set produces many attempts. Classifier models need CPU or GPU capacity that recurs. Gateway integration with LiteLLM or Apache APISIX adds work on routing and logging. Ask any quote to itemize these four areas separately.

The timeline depends on the number of risks in scope, the number of applications and models behind the gateway, and how quickly your owners decide on blocking policies. No duration is fixed in advance. A typical first phase covers input rails for prompt injection, output rails for sensitive data, and a baseline garak run, then expands. Each rails configuration also needs manual review after any Colang 1.0 to 2.x migration, which NVIDIA says is required. Agree the phases, deliverables and dates in writing before work starts, since most engagements are fixed-scope.

Your team needs to supply a named owner for each application and for the policy decisions, a representative sample of prompts and outputs with sensitive cases labeled, and written risk decisions on what counts as unsafe, what must be blocked and what should only be logged. You also need access to the model endpoints and the AI gateway, plus a decision on where logs are stored. The EU AI Act Article 19(1) requires providers of high-risk systems to keep automatically generated logs for at least six months unless other law provides otherwise, so confirm retention with your legal team early.

Yes, if you have engineers who can write and test rails, operate a self-hosted gateway and maintain a red-team routine. NeMo Guardrails is Apache-2.0 licensed and Guardrails AI is Apache-2.0 licensed, and both are free to run. The harder work is ongoing: tuning policies, reviewing false positives, retesting after model or prompt changes and keeping evidence current. Ask a partner to show how it would hand over runbooks, test suites and configuration versioning so the work does not depend on one person.

Test each guard against attacks it is meant to stop, and measure both missed attacks and blocked legitimate requests. garak, an Apache-2.0 tool from NVIDIA, probes models for prompt injection, data leakage, jailbreaks and other weaknesses, and writes a JSONL report of every attempt. Pair these automated probes with scenarios drawn from your own applications, and rerun the full suite after every policy, model or gateway change. Document the results as evidence, but remember that the report shows what was tested, not that the system is secure.

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted guardrails in your own infrastructure, and it runs security testing, including AI and agent security testing and red teaming. It prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Ongoing testing and tuning are available as retainers, and the scope is agreed in writing before work begins.