Guardrails Proxy
A policy-and-safety layer that inspects model traffic in real time and enforces what the org cannot leave to the model's goodwill: prompt-injection detection, PII redaction, content moderation, and usage policy. Necessary but not sufficient -- it pairs with pre-deployment red-teaming rather than replacing it.
The Pattern
"Traditional guardrails aren't enough... you can't fix stupid." -- Ian Webster, Promptfoo (source)
A guardrails proxy is a policy-and-safety layer that inspects model traffic in real time and enforces rules the org cannot leave to the model's goodwill: prompt-injection detection, PII redaction, content moderation, and usage or compliance policy. It sits in the request path -- often beside the model router, but as a distinct concern. The model router decides where a call goes; the guardrails proxy decides whether it is allowed and safe (usagepanda).
The honest framing is that this layer is necessary but not sufficient. Runtime filtering catches a class of harms, yet the real risks are application-specific -- improper RAG access controls, business-logic mistakes -- and a foundation model's safety training will not stop them.
Why It Matters
Ian Webster's lesson from shipping AI to 200 million Discord users is that you "can't fix stupid": the dangerous failures live at the application layer, not in the base model (Promptfoo). So the platform pairs the runtime proxy with pre-deployment red-teaming -- AI-versus-AI attacks tailored to each app's business context -- run through the eval service, rather than trusting either alone. The proxy is the last line in production; the red-team is the line before it ships. Treating guardrails as a single on/off box is the mistake; treating them as defense in depth is the pattern.
Sources
Last reviewed: 2026-06-24