What you need to know
Guardrails are runtime controls the architect adds around the model. The exam focuses on where they sit, what kind of check each one is, and what happens when the check itself fails.
Three control points
| Control point | When | Question it answers | Typical checks |
|---|---|---|---|
| Input screening | Before the model call | Should this content reach the model at all? | Length and format limits, known-bad patterns, a classifier for jailbreak or injection attempts, PII redaction |
| Output screening | Before the response reaches a person or system | Is this output safe and compliant to deliver? | Schema validation, forbidden fields or phrases, policy and toxicity checks, grounding checks |
| Action authorization | Before any tool with side effects runs | Is this caller allowed to do this, here, now? | Identity, permission, scope, limits, approval status |
Input screening covers retrieved documents and tool results too, not only what the user typed.
Model-based or deterministic?
| Check | Use when | Example |
|---|---|---|
| Deterministic (code, rules, schemas, allowlists) | The rule is exact and must be predictable and auditable | Refund over limit, banned field present, caller lacks permission |
| Model-based (a classifier or judge) | Detection needs language understanding and the patterns are open-ended | A cleverly worded jailbreak, a policy-violating tone |
Authorization is always deterministic. Model-based checks fail differently (they miss novel patterns and sometimes flag harmless ones), so chain them with deterministic checks rather than relying on either alone. A fast, small model often works well as a first-pass screen.
Fail open or fail closed?
Every guardrail is a dependency that can itself fail: a timeout, an outage, a crash.
- Fail closed: if the check cannot run, the request or action is blocked (or queued) until it can.
- Fail open: if the check cannot run, the request proceeds unchecked.
Safety-critical gates, and anything protecting money, data or irreversible actions, fail closed. Fail-open is acceptable only for low-risk, advisory checks, and should still be logged and alerted, because a silently failing guardrail gives the appearance of protection with none of the effect.
Guardrails need monitoring too
Log every block and every check failure with the reason. Rising block rates may mean an attack or an over-sensitive rule; falling rates after a change may mean a check stopped running.
In the exam
Guardrail questions describe a request path and an incident or requirement. Place each check at the right point, pick deterministic checks for exact rules and authorization and model-based checks for open-ended language risks, and choose fail-closed for consequential controls. Watch for designs that screen only user input, or that check the response after the action has happened.
Check your understanding
An agent can call transfer_funds. Where must the check on whether the user may make this transfer run?
Show answer
Answer: B. Authorization must happen before the side effect. Checking the message or the response cannot stop a tool call, and a nightly review is too late.
A content-safety classifier times out during a traffic spike. It guards a public assistant that can only answer questions. What should happen?
Show answer
Answer: A. A safety gate that cannot run should block or degrade safely, and the failure should be logged and alerted. Silent fail-open removes the protection without anyone knowing.
Which TWO checks should be deterministic rather than model-based?
Show answer
Answer: B, C. Exact limits and banned fields are rules code can enforce predictably and auditably. Disguised attacks and tone need language understanding.
Apply it: Place Larkfield's guardrails
Map the guardrails for Larkfield's intake system. Remember that claim emails and attachments come from the public, that the system creates claims and sends acknowledgements, and that it must never deny or pay a claim.
- List the checks at each control point: input, output, action authorization.
Done when: attachments and Policy Admin results are covered, not only the email text. - Mark each check as deterministic or model-based, with the reason.
- Decide fail open or fail closed for each, and what happens to the claim when a check fails closed.
- Name the monitoring for the guardrails themselves.
Show model answer
1 and 2. Checks
| Point | Check | Type |
|---|---|---|
| Input | Attachment type and size limits; page count routing | Deterministic |
| Input | Injection classifier on email text and OCR output ("ignore your instructions", requests to change claim status) | Model-based, open-ended patterns |
| Input | Redact bank card numbers and national ID numbers not needed for intake | Deterministic patterns |
| Output | Extracted fields match the schema; key fields agree with Policy Admin | Deterministic |
| Output | Acknowledgement contains no decision language (accepted, denied, approved, paid) | Deterministic phrase list, plus a model check on a sample |
| Action | create_claim only with a valid policy and intake role credentials | Deterministic |
| Action | No payment, closure or denial tool is reachable at all | Deterministic (absent capability) |
3. Failure behaviour. Everything fails closed. A claim that fails input screening, output validation or authorization goes to the handler queue with the reason attached; nothing is lost, and the one-day SLA is protected by the queue's own alert. The injection classifier failing (timeout) also routes to a handler rather than skipping the check.
4. Monitoring. Block and fail-closed counts per check per day, with alerts on sudden rises (possible attack or broken rule) and on drops to zero (a check that may have stopped running); a weekly review of a sample of blocked claims for false positives.