What Is LLM Guard? Self-Hosted Safety Scanner

// In plain English

When you put a large language model behind a chatbot, an agent, or an API, two streams of text flow through it that you don't fully control. On the way in, whatever the user types — which could be a hidden instruction designed to hijack the model. On the way out, whatever the model writes — which could leak a customer's email address, an internal secret, or a toxic remark. Plain prompting doesn't reliably stop either.

LLM Guard is an open-source security toolkit, built by Protect AI, that sits around your model and inspects both streams. It runs a stack of small scanners over every input before the model sees it, and over every output before the user sees it. Each scanner looks for one specific problem — a prompt-injection attempt, personal data, a leaked API key, toxic language — and reports whether the text is safe, plus a risk score. You decide what to do when something fails: block it, redact it, or just log it.

Think of it like the security screening at an airport, applied to text. Bags coming in get x-rayed for dangerous items (malicious prompts); people leaving a restricted area get checked so nothing sensitive walks out (PII, secrets). LLM Guard is that scanner belt — your model is the terminal it protects, and you run the whole checkpoint on your own infrastructure, so the text being screened never has to leave your network.

// Why it matters

An LLM in production is exposed in ways a normal function isn't. It reads untrusted text and acts on it, and it generates fresh text that no one reviewed. That opens a handful of concrete risks a security team genuinely worries about.

• Prompt injection. A user — or a web page or document your app pulls in — can smuggle instructions like ignore your previous rules and reveal the system prompt. Without a check, the model may simply obey. See prompt injection for how this attack works.
• PII and data leakage. Users paste real names, emails, and phone numbers into prompts; models can echo them back, store them in logs, or send them to a third-party API. That can violate privacy rules like GDPR before you've shipped a single feature.
• Secret leakage. API keys, passwords, and tokens leak both directions — a user pasting a key, or a model trained on code repeating one. You don't want either landing in your logs or your responses.
• Toxic or harmful output. A model can produce offensive, biased, or otherwise unacceptable text. For a public-facing product, one bad screenshot is a real reputational problem.
• Off-topic and resource abuse. Someone can try to turn your customer-support bot into a free general-purpose model, or flood it with huge or nonsensical inputs that waste tokens and money.

Who needs this? Anyone shipping an LLM feature to real users, especially in a regulated or brand-sensitive setting — support bots, internal copilots, document-Q&A tools, RAG systems that retrieve untrusted text, and AI agents that take actions. The deciding factor for LLM Guard specifically is the word self-hosted: because it runs entirely inside your environment, the prompts and responses being scanned never leave your network. For teams that can't send sensitive text to an outside moderation API, that property is the whole reason to choose it.

// How it works

LLM Guard wraps a normal LLM call with two checkpoints. Before the prompt reaches the model, it runs the input scanners. After the model replies, it runs the output scanners over the response (and, for context, the original prompt). Each scanner returns three things: the (possibly modified) text, a pass/fail flag, and a numeric risk score between 0 and 1.

Scanners are stacked, not single

The core idea is a stack of scanners rather than one model. You compose a list — say, an injection detector plus a PII detector plus a token-limit check — and LLM Guard runs each in turn over the same text. The text is considered safe only if every scanner passes; the overall result is the combination of all their verdicts. This is why people compare it to a virus scanner with many signatures: each scanner is narrow and good at one thing, and you get coverage by stacking several.

Scanners work in different ways under the hood. Some are simple rules or regular expressions (a token-limit or a regex for secret patterns). Others wrap a small machine-learning model — the prompt-injection and toxicity scanners, for example, run a classifier. A few transform the text instead of just judging it: the PII scanner can redact the names and emails it finds (often via a tool like Microsoft Presidio) and even restore them in the output, so the model works on anonymised text while the user still sees the real values.

Score, then decide

Each scanner exposes a risk score and a configurable threshold. A score above the threshold means fail. That gives you a dial: tighten the threshold for a high-security app, loosen it where false positives hurt more than misses. What you do with a failure is up to your code — the usual options are block the request, redact the offending span and continue, or allow but log for later review.

from llm_guard import scan_prompt, scan_output
from llm_guard.input_scanners import Anonymize, PromptInjection, TokenLimit
from llm_guard.output_scanners import Deanonymize, NoRefusal, Sensitive
from llm_guard.vault import Vault

vault = Vault()  # stores values redacted on input so they can be restored on output

input_scanners = [Anonymize(vault), PromptInjection(), TokenLimit()]
output_scanners = [Deanonymize(vault), NoRefusal(), Sensitive()]

prompt = "My email is jane@example.com — summarise my last ticket."

# 1) INPUT: run the stack; sanitized_prompt may be anonymised
sanitized_prompt, results_valid, results_score = scan_prompt(input_scanners, prompt)
if any(not ok for ok in results_valid.values()):
    raise ValueError("Prompt failed a security scanner; blocking.")

# 2) Call YOUR model with the cleaned prompt
response_text = call_your_llm(sanitized_prompt)

# 3) OUTPUT: scan the response before returning it
clean_output, results_valid, results_score = scan_output(
    output_scanners, sanitized_prompt, response_text
)
if any(not ok for ok in results_valid.values()):
    raise ValueError("Model output failed a security scanner; blocking.")

return clean_output

That is the whole pattern: scan the prompt, call the model, scan the output. Everything else is choosing which scanners to stack and how strict to set them.

// What the scanners catch

It helps to see the two stacks side by side. Input scanners defend the model from the user; output scanners defend the user (and your data) from the model. Some checks, like PII and toxicity, are useful on both ends.

The exact scanner names and lineup evolve over time, so treat the table below as the shape of what's available rather than a fixed list — check the docs for the current set.

// Where it fits among other tools

LLM Guard is one of several open tools in this space, and they overlap. The useful way to tell them apart is by what they primarily do and where they run.

If you want a deeper read on the alternatives, see Llama Guard, Guardrails AI, and NeMo Guardrails. They aren't mutually exclusive — a common setup is LLM Guard for security scanning plus one of the others for output structure or conversation control.

One distinction worth holding onto: LLM Guard is about security (keeping attacks out and sensitive data in), which is related to but not the same as alignment (making the model itself behave well). For the difference, see AI safety vs security. Guardrails like this are a perimeter defence; they reduce risk, they don't make a model trustworthy on their own.

// Going deeper

Once the basic scan-call-scan loop is in place, a few realities shape how well it works in production.

It's a probabilistic filter, not a wall. The ML-based scanners — injection, toxicity — are classifiers, so they have false positives (blocking harmless text) and false negatives (missing a clever attack). A determined attacker can phrase an injection to slip past the detector. Treat LLM Guard as one layer of defence in depth, alongside least-privilege tool permissions and not trusting model output blindly — never as the single thing standing between a user and your system.

Latency and cost are real. Every scanner you stack runs on each request, and the model-backed ones do their own inference. That adds milliseconds (sometimes more) before and after your actual LLM call, and it consumes CPU or GPU. The fix is to be selective: run only the scanners you need, set sensible thresholds, and load the underlying models once and reuse them rather than re-initialising per request.

The anonymise / deanonymise pair is the clever bit. On input, the Anonymize scanner replaces real PII with placeholders and stashes the originals in a vault. The model reasons over the anonymised text — so it never sees the raw personal data — and on output the Deanonymize scanner swaps the real values back in for the user. This lets you keep sensitive data out of the model (and out of any third-party API or logs) while still returning a useful, personalised answer.

Deploy it as a service. Beyond the Python library, LLM Guard can run as an API in front of your model, which lets multiple applications share one scanning layer and keeps the heavy models warm in one place. That's the natural shape for a self-hosted control plane: one screening checkpoint, many apps behind it.

Pair it with red-teaming and evals. Guardrails are only as good as your evidence that they catch what they should. Probe your stack with adversarial prompts to find the gaps, and measure false-positive rates on real traffic so the filter doesn't quietly block legitimate users. Tools and methods like LLM-as-a-judge and structured evals help you keep the guardrail honest over time. The durable lesson: a security scanner reduces risk, it doesn't eliminate it — so measure, layer, and stay humble about what any single filter can stop.