5.1 — Guardrails, Safety Controls, and the Surface a Risk Belongs To

CCAR-P Domain 5 · Task 5.1

What You Need to Know

A guardrail is a control that stops a Claude system causing harm. Each risk belongs on the one surface that can hold it.

Five Control Surfaces

1. Input controls — screen what enters (injection, PII, out-of-scope)
2. Instruction-layer — system prompt scope, refusal policy, escape hatch
3. Capability controls — which tools exist, credentials, second-party approval
4. Output controls — schema/policy checks, blocked claims, citations, redaction
5. Architectural removal — decline to build the capability at all

Key Principles

• An instruction is not an access control. If a capability is wired, a prompt not to use it is only a request.
• Untrusted input is everything the system did not author — retrieved docs, tool results, uploads (indirect injection).
• A guarantee has only two homes: the output gate, or a capability you never built.
• Defence in depth — layers independent so one failing does not put harm in front of a user. Removal still wins for irreversible external actions.

Structural Mitigations for Untrusted Input

• Untrusted content arrives inside tool results with declared origin
• System prompt states tool content is data, not commands
• Tool output screened before the model acts
• Access scoped so a successful injection has somewhere small to go

Exam Traps

• Strengthening the system prompt to forbid a behaviour the system remains wired to perform
• Moving to a more capable model to stop policy violations or resist injection
• Logging / periodic review against a “must never reach a user” requirement
• Adding confirmation/approval in front of a capability the role never needs