Sarghaby Araghatta
Home / Knowledge Base / Guardrails — what they can and cannot do
Evaluation & quality · AI Engineering

Guardrails — what they can and cannot do

Programmatic checks around the model that block, rewrite, or re-route unsafe or off-policy content — on the way in (prompt injection, jailbreaks, PII) and on the way out (toxicity, leaked secrets, wrong format, off-topic).

validate inputvalidate inputvalidate outputvalidate outputgenerate contentUser Input(Prompt)Input Validators(Regex, PII)Classifier Models(Llama Guard)Output Validators(Toxicity Check)Model Output(Generated Content)
Guardrails in AI Content Generation

How it works

A pipeline of validators runs alongside the generation process to ensure safety and compliance. This includes various tools such as regex checks, deny lists, and PII detectors that scan for sensitive information. Classification models like Llama Guard and OpenAI moderation help identify toxic content. These validators work in concert with schema validators and smaller language models that act as judges. When a violation is detected, the system can refuse the input, redact problematic content, retry the generation, or escalate the issue to a human operator for review. This orchestration is managed by frameworks like NeMo Guardrails or Guardrails AI, which streamline the entire validation process and ensure that the model operates within predefined safety boundaries.

As the input flows into the model, these validators act as gatekeepers, checking for potential threats before the model processes the data. For example, if a user tries to inject harmful prompts or sensitive information, the regex checks and PII detectors will flag these issues. This preemptive action prevents the model from generating unsafe or off-policy outputs. On the output side, the validators again come into play, ensuring that the generated content adheres to safety standards, such as avoiding toxicity or maintaining the correct format. This dual approach—checking inputs and outputs—creates a comprehensive safety net around the model.

Imagine a scenario where a user inputs a prompt that could lead to the generation of harmful content. The validators kick in immediately, identifying the risk and either blocking the prompt or modifying it to ensure compliance. If the model generates an output that contains sensitive information or is off-topic, the validators catch this as well. This continuous feedback loop allows for real-time adjustments, enhancing the model's reliability and safety. Without these guardrails, the model would operate in a vacuum, increasing the risk of generating harmful or inappropriate content.

  • Use regex for simple patterns.
  • Employ classifiers for nuanced checks.
  • Implement layered validations for safety.
  • Log violations for auditing.
  • Adjust rules to balance safety and usability.

The software-engineering analogue

You can think of guardrails as a combination of input sanitization, a web application firewall (WAF), and output encoding surrounding an untrusted component. In traditional software engineering, these layers protect against known vulnerabilities and ensure that only safe data is processed. However, the key difference here is that the 'attacker' and the component share a natural-language channel. This means that the rules we set up must rely on probabilistic classifiers rather than deterministic parsers. As a result, we face inherent challenges with false positives and negatives, which can lead to legitimate content being blocked or harmful content slipping through.

This probabilistic nature of language makes it difficult to create foolproof guardrails. While traditional software security can often rely on strict rules and patterns, the nuances of human language introduce ambiguity. For example, a phrase that seems harmless in one context could be harmful in another. This complexity means that while we can create effective guardrails, they will never be perfect, and we must continuously refine them to adapt to new threats.

Why not the obvious alternative

Many newcomers might think that relying solely on the base model's alignment is sufficient for safety. This approach seems straightforward, but it lacks the necessary depth. The base model can be bypassed, and its alignment is not always auditable. If a malicious user knows how to exploit the model's weaknesses, they can easily generate unsafe content. By adding guardrails, we introduce an independent layer of checks that are logged and enforceable, significantly improving our defense against misuse.

However, it's crucial to understand that guardrails are not a silver bullet. They cannot guarantee complete safety; determined users may still find ways to bypass them, especially with sophisticated jailbreak techniques. If the rules are set too tightly, they may inadvertently block legitimate use cases, frustrating users and hindering functionality. Thus, while guardrails are essential, they must be carefully tuned to balance safety and usability.

When to use which

In user-facing applications or systems with agentic capabilities, particularly in regulated domains, implementing layered guardrails is critical. These guardrails should be viewed as a means of risk reduction rather than a foolproof solution. It's wise to pair them with principles of least-privilege access and ensure that there is human oversight for actions that cannot be reversed. This layered approach helps mitigate risks while allowing for flexibility in legitimate use cases.

For instance, in a financial application where sensitive data is handled, having strong guardrails can prevent unauthorized access to personal information. In contrast, in a creative writing tool, the guardrails might focus more on preventing harmful content rather than blocking creative expression. Understanding the context and potential risks helps in designing an effective guardrail strategy that meets specific needs.

Probabilistic Nature of Guardrails Guardrails are not foolproof; they can produce false positives and negatives, requiring careful tuning to avoid blocking legitimate content.

In production: when it breaks

The scenario Guardrails failed to block 15% toxic outputs.
Toxicity Rate > 10%Check Input ValidationCheck Output FilteringPrompt Injection DetectedInadequate ToxicityThresholdAdd Advanced Input ChecksAdjust Toxicity FilterSensitivity
Guardrails debugging flow

Why it happens. The guardrail may not be adequately trained to recognize specific patterns of PII, or it could be operating with outdated rules that fail to capture newer forms of data leakage. Insufficient coverage in the training dataset can lead to blind spots where sensitive information is not flagged.

  • Review the guardrail's training dataset for coverage of PII patterns.
  • Check the performance metrics of the guardrail against a validation set with known PII instances.
  • A/B test the guardrail with updated rules or a retrained model to see if detection improves.
The call The fix involves retraining the guardrail with a more comprehensive dataset that includes diverse PII examples. The tradeoff may be an increase in false positives, requiring a balance between sensitivity and specificity. Monitor the percentage of blocked PII prompts to ensure the guardrail's effectiveness post-deployment.

What it delivers

Ultimately, guardrails provide an auditable and tunable safety layer that effectively catches common and known-bad cases. They offer a practical solution to enhance the safety of AI models without overselling their capabilities. By implementing guardrails, practitioners can operate with greater confidence, knowing that they have measures in place to address potential risks while still allowing for productive interactions with the model.