LLM Guardrails for Production: Input Validation and Output Filtering

We spent three weeks building a customer support agent that performed beautifully in staging, only to watch it hallucinate a 90% discount code during its first hour in production. That incident taught me that relying on system prompts alone is a recipe for disaster; you need active, programmatic defenses.

Implementing LLM guardrails isn't just about safety—it's about reliability. If you're building features that interact with users, you need to treat the LLM as an untrusted third-party service, even if you’re hosting it yourself.

Why Prompt Engineering Isn't Enough

Early in my development cycle, I thought I could solve everything with a sufficiently complex system prompt. I'd add instructions like "do not mention competitors" or "never promise a refund." It worked until a clever user tested the edge cases.

The reality is that LLMs are probabilistic, not deterministic. If you want to build a product that doesn't embarrass you, you need two distinct layers of control: input validation before the prompt reaches the model, and output filtering before the response reaches the user.

Implementing Input Validation

Think of input validation as the first line of defense. You’re essentially filtering out malicious or nonsensical queries before they consume expensive tokens.

I usually start with PII redaction and intent classification. If a user tries to inject a system prompt—a classic "jailbreak" attempt—the model shouldn't even see it.

1. PII Detection: Use a library like Presidio to strip emails, phone numbers, or credit card info before the text hits your API.
2. Semantic Similarity: Compare the incoming user message against a set of "allowed" topic embeddings. If the cosine similarity is below a threshold (say, 0.75), reject the request.
3. Prompt Injection Checks: Use a secondary, smaller, and cheaper model (like a distilled BERT or a tiny Llama variant) to classify the intent of the incoming message. If it flags as "adversarial," drop it immediately.

By catching these at the gateway, you save money and prevent the LLM from entering a state you didn't intend.

The Role of Output Filtering

Even with clean input, the LLM can still go off the rails. Output filtering is your safety net. This is where you catch hallucinations, toxic content, or format violations.

I’ve found that enforcing structure is the most effective way to minimize bad outputs. If you are struggling with this, check out my previous notes on getting reliable structured output from an LLM in production, which covers using Pydantic models to force the model’s hand.

When building your filtering layer, look for these three things:

• Format Compliance: Does the output match your expected JSON schema? If not, treat it as a failure and retry or return a graceful error.
• Toxicity/Safety Scoring: Use tools like Replicate or HuggingFace models to perform a sentiment and safety scan on the generated text. If the toxicity score exceeds a specific threshold, block the response.
• Hallucination Detection: Use a "self-correction" pattern where you ask the model to verify its own answer against the provided context. If the model says "I cannot verify this," don't show the answer to the user.

Putting it Together: A Practical Example

Here is a simplified look at how I structure this in a Python-based middleware:

PYTHON
def process_request(user_input):
    # 1. Input Validation
    if contains_pii(user_input):
        return "Request blocked: PII detected."
    
    if is_adversarial(user_input):
        return "Request blocked: Potential injection."

    # 2. LLM Call
    response = call_llm(user_input)

    # 3. Output Filtering
    if not is_safe(response):
        return "ICE9178">'m sorry, I can't generate that content."

    return validate_json_structure(response)

This flow adds roughly 200-300ms of latency, but the peace of mind is worth it. In a production environment, you should also consider how these layers integrate with your broader infrastructure. If you're managing these services in Kubernetes, ensuring your internal communication remains secure is just as important as the model itself. I often lean on tools like those discussed in Kubernetes security: implementing zero-trust with Kyverno and policies to ensure that the services running these guardrails are isolated and authenticated.

Frequently Asked Questions

How much latency do these guardrails add? It depends on your stack, but for simple string matching and regex-based PII detection, it's negligible. If you're running a secondary LLM for validation, expect an extra 300ms to 800ms depending on the model size.

Should I use an off-the-shelf framework or build my own? I started by building my own, but frameworks like Guardrails AI or NeMo Guardrails have caught up significantly. If you’re just starting, use a framework. If you have highly specific compliance needs, building custom validation logic is better.

What is the biggest risk I'm still facing? Even with the best filters, you can't catch everything. The biggest risk remains "logic hallucinations"—where the model provides a factually wrong answer that sounds perfectly professional. No guardrail will replace a human-in-the-loop for high-stakes decisions.

Final Thoughts

The goal of these guardrails isn't to make the model perfect; it's to make the system predictable. You'll never be able to account for every possible user interaction, but you can build a system that fails gracefully rather than catastrophically.

Next time, I want to experiment with asynchronous validation—running the guardrails in parallel with the LLM call to hide the latency. I’m still working out how to handle the "race condition" where the output is generated before the input check completes, but it’s the logical next step for performance-heavy apps.