Guardrails are checks running around the model, not inside it.
Input guardrails screen for injection, abuse and PII before the model sees them.
Output guardrails check responses for leaked data and policy violations.
They are deterministic code, so they behave predictably under attack.
They are the layer that catches what a jailbroken model would otherwise emit.
Guardrails are checks that run around the model rather than inside it.
They are ordinary deterministic code, which is exactly why they are worth having.
A jailbreak persuades a model, and it cannot persuade a regular expression.
Input guardrails run before the model sees anything.
They screen for injection patterns, abuse, and personal data that should be redacted.
They can also reject requests that are simply out of scope.
Output guardrails run after generation and before the user sees the response.
They check for leaked secrets, policy violations, and anything the response should not contain.
They can verify structure, so a malformed response never reaches a caller.
They can check claims against retrieved sources for a grounding signal.
The trade-off is latency and false positives, since a strict filter blocks legitimate requests.
Log everything blocked and review it, or you will not notice the good requests being lost.
Guardrails are a layer, not a solution, and they catch what a jailbroken model would emit.
Combine them with least-privilege tools and human approval for real defence in depth.
Frameworks exist, and simple explicit checks you understand often serve better.
One question on this card. Every option explains itself once you pick, right or wrong.
16 concepts in this module, then a graded test with every answer explained.