Guardrails

Guardrails

Step 1 of 10

layers4

The model sits in the middle of three checks, and its own instructions are the weakest of the four layers.

The Idea

A guardrail is a check outside the model. Input filters catch prompt injection and unsupported requests. Tool permissions decide what the loop can actually reach. Output checks scan for secrets and unsafe content. The model's own instructions are the weakest layer, because text can argue with text.

Real-World Example

A bank teller is polite and well trained, and still cannot move a large sum alone. The limit lives in the system, not in their judgment, precisely so that a convincing story is not enough.

The Tradeoff

Every layer adds latency, cost and false positives, and an over-eager filter that blocks real work gets switched off by the first frustrated team. Put the hard limits where they cannot be talked around — scopes, quotas, allow-lists — and keep the soft checks for things a human will review anyway.

Your turn

Put the steps in the right order.

1. 1Run the model, which may propose a tool call↑↓
2. 2Screen the incoming request and the retrieved context↑↓
3. 3Scan the finished answer before it reaches the user↑↓
4. 4Check the call against the credentials and scopes it is allowed↑↓

Check order

Mini quiz

1 / 3

Instructions in retrieved documents should be treated as:

• AData, never commands
• BPart of the system prompt
• CA signed policy
• DHigher priority than the user