Guardrails

Checks wrapped around a model that block bad input going in and bad output coming out, enforced in code rather than politely requested in the prompt.

stop it saying bad thingsthe safety fenceguard railsgaurdrailsai safety checkscontent filter for llm outputkeep it on topicmake sure it never promises a refund

See it

Live demo coming soon

What it is

Guardrails are the code around the model, not inside it. They come in two halves: input guards that inspect what reaches the model (off-topic questions, injection attempts, personal data you should not be sending a vendor) and output guards that inspect what comes back (policy violations, leaked system prompt, an unsupported claim, a JSON blob that fails your schema). Each guard blocks, rewrites, or escalates to a human.

Build them cheap first. A regex for account numbers, a schema validator, an allowlist of tools the agent may call, and a hard rule that no generated SQL runs against production do more real work than an elegant classifier. Reserve a second model call as a judge for the fuzzy cases where rules cannot reach, and treat every guard as something you write an eval for.

The big misconception: prompt wording is not a guardrail. 'Never discuss competitors' is a suggestion that one clever paragraph of user input can undo, so put the actual enforcement in deterministic code the model cannot talk its way past. Also watch the other failure mode: guards tuned too tight refuse legitimate requests, and users hate a scolding product more than an imperfect one.

Ask AI for it

Add a guardrail layer around this LLM call. On input: strip or reject personal data, flag prompt-injection patterns in retrieved or user-supplied text, and classify off-topic requests before they reach the model. On output: validate against a strict schema, run a blocklist and policy check, and verify any factual claim is supported by the retrieved sources. Implement each guard as a separate composable function returning allow, rewrite, or block with a reason, and enforce them in application code rather than in prompt text. Never log the raw blocked content or the personal data a guard just detected: log a redacted event carrying the rule id, the guard outcome, the request id, and a non-reversible fingerprint (salted hash) of the payload, behind access controls and a short retention window, so triage is possible without storing the thing you refused to send. Fall back to a safe canned response plus a human handoff when a guard blocks.

You might have meant

prompt injectionjailbreakstructured outputhuman in the loophallucination