What a guardrail is — and what it can never be

Lesson 1 of 5 in The Guardrail Catalog: Runtime Checks, Mapped Per Cloud.

A guardrail is a runtime check that runs outside the model. Text arrives, a check inspects it, and a policy decides: pass, block, mask, or escalate. The model is not asked to be good — it is watched.

That single sentence rules out most of what teams call guardrails. A system prompt paragraph saying “never reveal internal pricing” is not a guardrail; it is a request to a probabilistic system that reads attacker-controlled text as readily as yours. Safety training baked into model weights is not a guardrail either — it is a property of the thing you are trying to constrain. If a check cannot be disabled, audited, and unit-tested independently of the model, you do not have a guardrail. You have a hope.

The checks that qualify are boring and inspectable: an injection heuristic on retrieved documents, a PII classifier on outputs, a JSON-schema validator on tool arguments, a grounding check comparing an answer against its sources, a regex that strips image tags before rendering. Every one of them is deterministic enough to test, cheap enough to log, and separate enough to own.

Key terms: guardrails, containment, prompt injection, grounding, least privilege, defense in depth

Where guardrails sit in the defence stack

  1. Guardrails — detect known-bad — classifiers and validators at runtime, outside the model

    Input filters, output classifiers, tool-call validators, PII redaction, grounding checks. Probabilistic and bypassable, so they are the outermost, cheapest layer, never the last one. Their real product is two things: the easy attacks stopped, and the signal that something is being attempted.

  2. Human oversight — gate the irreversible — approval on the small set of actions that matter

    An approval gate on high-consequence actions. Deterministic in the sense that a human really can say no — but a scarce resource, and degraded by volume. Meta’s Agents Rule of Two (31 October 2025) points here directly: if a task genuinely needs untrustworthy input and sensitive data and the ability to change state or communicate externally in one session, it should not run autonomously.

  3. Containment — bound unknown-bad — least privilege, egress control, sandboxing, budgets

    The layer that works when the classifier missed and the reviewer clicked yes. It does not need to recognise the attack: a credential that cannot write, a network that cannot reach the attacker, a sandbox that cannot touch the host, a budget that stops after $5 of tokens. This is the layer that turns a critical incident into an annoying log line.

  4. Recovery — assume all of the above failed — traces, kill-switch, revocation, backups

    Full traces so you can reconstruct what happened, a kill switch you have actually tested, credential revocation you can execute in minutes, and restorable backups. The layer nobody budgets for until the first incident.

Interactive sorting exercise: Sort each control: is it a guardrail (a runtime check that detects known-bad) or containment (a bound on damage that needs to recognise nothing)? Two items are neither.

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.