What You Need to Know
A guardrail is a control that stops a Claude system causing harm. Guardrails sit on five control surfaces, each at a different position on a request's path. Each risk belongs on the one surface that can hold it.
Take a solar installer whose customer assistant reads uploaded roof surveys and holds a tool that cancels booked installations.
Five Control Surfaces, Read by Position
Input controls screen what enters: injection and jailbreak patterns, personal data that should never have been submitted, out-of-scope or abusive requests. They alone can stop a payload before it touches anything. Anthropic advises pre-screening with a lightweight model and pinning the verdict to a structured output.
Instruction-layer controls are the system prompt's scope, refusal policy and escape hatch. They shape behaviour and earn their place.
Capability controls decide what the system may do: which tools exist, which credentials they carry, which actions need a second party. Staff sign-off on each cancellation is one.
Output controls validate before the response leaves: schema and policy checks, blocked claim classes, required citations, redaction on egress.
Architectural removal declines to build the capability at all. An unbuilt tool has nothing to misconfigure, decay or audit.
An Instruction Is Not an Access Control
A system prompt is text the model reads. If a capability is wired, an instruction not to use it is a request. Anthropic's hardening guidance puts prompt policy alongside input validation and least privilege, never in place of them.
Test any design: what stops a confused or compromised turn from reaching the wired capability? If the answer is "the prompt says not to", the risk has no owning control. With the cancel tool wired, the installer's prompt line "never cancel an installation" is only a request.
Untrusted Input Is Everything the System Did Not Author
Two threat models apply. In a direct jailbreak the user is the adversary. In an indirect injection the user is trusted, and the adversarial instruction rides in on third-party content: a retrieved document, a tool result, a connector payload, an uploaded file. An honest customer's roof survey is third-party content too.
The mitigations that hold are structural rather than persuasive:
- Untrusted content arrives inside tool results and nowhere else, with its origin declared and its encoding unambiguous, so an attacker cannot break out of the data context.
- The system prompt states that tool content is data to report, not commands to follow.
- Tool output is screened before the model acts on it.
- Access is scoped so a successful injection has somewhere small to go.
Screening reduces how often injections get through. Scoping bounds the consequence. Detection helps, but least privilege holds. A planted instruction that passes the screen could not use the cancel tool had it never been built.
A Guarantee Has Only Two Homes
"This must never reach a customer" is a guarantee, and wording cannot guarantee an outcome. A guarantee lives at the output gate or in a capability you never built. Where a property must hold every time, Anthropic's consistency guidance points away from prompt wording towards structured outputs.
The gate carries the claim classes the organisation has already decided about: financial commitments, clinical or legal advice, guarantees of outcome. Some are not yours to choose: a provider usage policy sets floor requirements for high-risk uses. The gate blocks, redacts or routes to a person. The installer's gate would route a reply promising a payback period to staff. A gate that only records is a detective control under a preventive label.
Defence in Depth, and Why Removal Still Wins
Layers are independent so one failing does not put harm in front of a user. Anthropic's advanced guardrail material chains a harmlessness screen, a values-bearing system prompt and a policy check for that reason.
Depth is not permission to put a consequence on the wrong layer. An irreversible external action is governed by capability scoping or a human gate, never by firmer wording plus a weekly sample. A cancelled installation cannot be undone, so it needs staff approval or no tool.
In the exam
In the guide's Domain 3 sample, a support agent holds refund and delete tools its users never need, and the keyed answer removes them. Logging is the detective distractor, a confirmation prompt the compensating one, a bigger model the irrelevant one. Every option is a real control, and one is the control that risk needs. That is the shape of nearly every guardrail item.
Read the stem for the phrase that fixes the surface: never reaches, before it is sent, cannot be undone, after the fact. That phrase usually settles the item. The prompt instruction is this domain's most-planted distractor, and it returns in Domains 3 and 7. Domain 3 wires capability controls; Domain 5 decides they must exist.
Friction on an Unnecessary Privilege
When a stem says the role never needs a capability, options adding a confirmation step, an alert or an approval are real controls answering a question nobody asked. Friction on an unnecessary privilege leaves the privilege in place, and the guide keys removal above every guard in front of it.
The guide publishes no Domain 5 sample; Domain 3's is the nearest register anchor.
Exam Traps
Strengthening the system prompt to forbid a behaviour the system remains wired to perform
The prompt is context, not enforcement. A wired capability stays reachable through error, manipulation or injection, and Anthropic's own injection guidance treats prompt policy as one layer beside screening and least privilege rather than as the enforcement point.
Moving to a more capable model to stop policy violations or resist injection
Model capability has nothing to do with what the configuration permits. The guide's own sample keys model size as the irrelevant option, and a stronger model follows an adversarial instruction more competently, not less.
Logging every response, or scheduling a periodic review, against a requirement that the harm must never reach a user
A detective control finds the harm after it has landed. A requirement written as a guarantee is satisfied at the output gate or by removing the capability, and the sample the review team eventually reads is evidence that the control failed.
Offering a written policy, a staff training course, or a privacy notice as the mitigation
None of them changes what the system is permitted to do. They are governance artefacts that describe intent, and the exam plants them in stems that have already established the capability is live.
Practice Scenario
A pharmacy chain's customer assistant answers questions about the medicines it stocks. Clinical governance requires that no reply ever states a dose, a frequency or a duration; those questions must reach a pharmacist. Which change satisfies the requirement as stated?
Build Exercise
Map the Control Surfaces for One Claude System
What you'll learn
- How to state a risk in the language a user or regulator would use rather than in control jargon
- How to assign each risk to the one surface that can actually hold it
- How to test whether a second, independent layer really exists
- How to find every risk currently carried by wording alone
- How to red-team a design so scoping, not phrasing, is what stops the payload
- Take a Claude system you operate, or design one, and write its five named risks in the language a user or a regulator would use
Why: A risk written in control jargon has already chosen its answer. Plain language keeps the surface assignment open.
You should see: Five sentences a non-engineer would recognise, for example: a customer is told something about their medication that only a pharmacist should say.
- Assign each risk to exactly one owning surface: input screening, instruction layer, capability scoping, output validation, or removal
Why: One owning surface forces the judgement the exam tests. Two owners usually means neither has been designed.
You should see: Five assignments with a one-line justification tied to how the risk actually manifests.
- For each assignment, write what happens if that layer fails, and name the independent layer that catches it
Why: Defence in depth is a claim about independence. Writing the failure case is how you find out whether the second layer exists or was assumed.
You should see: A failure sentence per risk, and an honest blank where there is no second layer.
- Find every risk currently carried by an instruction alone, then either move it to an enforcing surface or record it as an accepted risk with a named owner
Why: Wording nobody has agreed to accept is the quiet default state of most systems, and it is this domain most-planted wrong answer made real.
You should see: A list of instruction-only risks, each now re-homed or signed for by a named person or role.
- Red-team the result: write three untrusted payloads, one in a retrieved document, one in a tool result and one in an uploaded file, that try to reach a consequential action
Why: Anthropic recommends testing your own agent with deliberately adversarial content before deployment, and it is the fastest way to see which layer is load-bearing.
You should see: Three payloads, each with a note saying whether scoping or wording stopped it.
Sources
- Mitigate jailbreaks and prompt injections — Anthropic
- Increase output consistency — Anthropic
- Usage Policy — Anthropic
- Claude Certified Architect Professional Exam Guide (v1.0) — Domain 5 — Anthropic