AI Guardrails

Also Known As

TL;DR

Explanation

AI guardrails are the defensive layer between a raw LLM and end users. They operate in two positions: input guardrails screen user prompts before they reach the model (blocking injection attempts, PII, or out-of-scope requests), and output guardrails inspect the model's response before it is returned (filtering toxicity, checking factual constraints, enforcing format schemas). Guardrails can be implemented as: a second classification model (e.g. a moderation API), regex/keyword filters, structured output validation (JSON Schema), semantic similarity checks against a blocklist, or a secondary LLM-as-judge call. Production systems typically layer several of these. Key design considerations are latency budget (every extra call adds roundtrip time), false-positive rate (over-blocking degrades UX), and adversarial robustness (guardrails themselves can be bypassed through encoding tricks or multi-turn jailbreaks).

Diagram

flowchart LR
    USER[User Prompt] --> IG{Input Guardrail}
    IG -->|blocked| DENY1[Return policy error]
    IG -->|allowed| LLM[LLM]
    LLM --> OG{Output Guardrail}
    OG -->|blocked| DENY2[Return fallback response]
    OG -->|allowed| RESP[Response to user]
    subgraph InputChecks
        IC1[Injection detection]
        IC2[PII scrubbing]
        IC3[Topic classifier]
    end
    subgraph OutputChecks
        OC1[Toxicity filter]
        OC2[JSON Schema validation]
        OC3[LLM-as-judge]
    end
    IG --- InputChecks
    OG --- OutputChecks
style DENY1 fill:#f85149,color:#fff
style DENY2 fill:#f85149,color:#fff
style RESP fill:#238636,color:#fff

Common Misconception

Why It Matters

Common Mistakes

• Adding guardrails only on output while ignoring input — prompt injection can exfiltrate the system prompt before output filtering ever runs.
• Hard-coding keyword blocklists without semantic fallback — attackers trivially bypass them with synonyms, l33tspeak, or other encodings.
• Setting guardrail thresholds so tight that legitimate queries are blocked, causing high false-positive rates that erode user trust.
• Not logging guardrail triggers — blocked inputs are a rich signal for adversarial patterns you have not anticipated.

Avoid When

• Using only a keyword blocklist as the sole guardrail — semantic attacks bypass it trivially.
• Running all guardrails synchronously on the critical path if latency is a hard constraint — consider async logging with a fail-open policy for low-risk outputs.

When To Use

• Apply input guardrails on every user-supplied prompt before it reaches the model.
• Apply output guardrails before any LLM response is surfaced to a user or stored in a database.
• Layer multiple mechanisms — a fast keyword filter first, then a slower semantic classifier for ambiguous cases.
• Log every guardrail trigger to build a dataset of adversarial inputs for future model and filter improvements.

Code Examples

// No input guardrail — user prompt goes directly to LLM
$response = $llm->complete($userPrompt);
echo $response; // LLM output displayed with no output filtering

// Input guardrail: classify prompt before sending
$risk = $moderator->classify($userPrompt); // returns risk score 0-1
if ($risk->score > 0.7) {
    return ['error' => 'Request blocked by content policy'];
}

// Call LLM with constrained system prompt
$response = $llm->complete(
    system: 'You are a customer support bot for Acme Shop. Never discuss competitors.',
    user: $userPrompt
);

// Output guardrail: validate structure and content
$parsed = json_validate($response) ? json_decode($response) : null;
if (!$parsed || $moderator->classify($response)->score > 0.5) {
    return ['error' => 'Response did not meet content standards'];
}
return $parsed;

Tags

🧠 Logic Engine

References

• https://www.guardrailsai.com/docs
• https://platform.openai.com/docs/guides/moderation