Guardrails & Runtime Checks
Input rails, output rails, tool policies, and sandboxes — the deterministic containment layer around a probabilistic core.
Guardrails are checks OUTSIDE the model — deterministic code wrapped around a probabilistic core, because you cannot prompt your way to a guarantee. Input rails run before the model: injection heuristics, topic and abuse filters, PII redaction (aa-23), size and rate limits. Output rails run after: schema validation (aa-03's typed outputs are a guardrail), groundedness checks for RAG, content policy classifiers, secret/PII scanners, and link/domain allow-lists before anything renders. Tooling exists across the spectrum — from provider moderation endpoints to rules engines like NeMo Guardrails and validator libraries like Guardrails AI — but the architecture matters more than the brand.
Action rails govern what an agent may DO, which is where real damage lives. Least-privilege tools (read-only credentials for read-only jobs); allow-lists over deny-lists for commands, domains, and recipients; human approval gates for consequential and irreversible actions (spend, send, delete, deploy) — the hooks you built in Course 01 are exactly this pattern; per-session budgets (token spend, tool-call counts, iteration caps) so runaway loops die by construction; and sandboxed execution for anything the model writes — generated code runs in a disposable container with no network by default, never in your process.
Two disciplines keep rails honest. Fail closed: when a guardrail errors or times out, block and escalate — a checker that fails open is decoration. And log every trigger into your observability stack: rail hits are security telemetry AND eval fodder (false-positive rates matter too; a rail that blocks 5% of legitimate traffic quietly kills the product). Design the whole thing assuming some injections land (aa-22): rails exist so a compromised model turn is a contained event, not an incident.