What You Need to Know
A guardrail is a check with an enforcement point. It inspects something, and when it fires it stops or changes what happens next. A behaviour shaper is different: the model reads something and decides. Failing closed means refusing the guarded action when its check cannot run. Sub-skill 7.1 named the controls. This one asks where each control runs and what it does when it fires.
Take a plumbing firm with a chat assistant on its website. Customers describe the job in their own words. Claude drafts a quote, and a booking tool puts an engineer's visit in the diary. Every customer message is untrusted input. Booking a visit is a consequential action.
A Guardrail Is a Check With an Enforcement Point
Ask three questions of any proposed control. What does it inspect? Where does the code run? What happens when it fires? If the answer to the third is that the model reads something and decides, the control is a behaviour shaper. Put it on the diagram under a different heading.
Most guardrail tables shrink the first time somebody applies this test. A system-prompt rule inspects nothing and enforces nothing. A log records after the fact. A dashboard alerts a human who may be asleep. All three are worth having. None of them is a guardrail.
At the plumbing firm, a system-prompt line saying "always ask for a postcode" is a shaper. A check in the booking tool that rejects a booking with no postcode is a guardrail.
The Four Layers and What Each Can Catch
Each layer has a different failure mode. A payload that defeats one layer still meets another that does not see the same way. That is the reason to layer.
Input checks run before the model sees anything. They include classification with a lightweight model, pattern filtering, redaction, and plain shape validation on size and type. They are cheap and useful, but probabilistic, and they see only what arrives through the channel they sit on. The firm's classifier screens chat messages. It sees nothing that reaches Claude by another route.
The system prompt and the model's training sit in the middle. They shape behaviour, and stating an untrusted-content policy there is recommended. They enforce nothing. That is the most important sentence in the sub-skill. At the firm, nothing in the prompt stops a booking if Claude follows an instruction hidden in a customer message.
Tool-level controls are where enforcement lives. They decide which tools exist at all, what scope their credentials carry, which calls require approval, and which calls a deterministic pre-execution check blocks. Removal is stronger than denial, because a tool that is not in the request cannot be attempted. The firm's assistant has no refund tool, so no message can talk it into one.
Output checks run after the call. They validate the shape, classify against policy, and redact what must never appear. They also block the resulting action rather than merely flag the text, and developers skip that part. A model that produced a bad answer and a system that published it are two different failures, and the output layer prevents the second. A quote with a nonsense price should stop before it reaches the customer.
Claude Code ships a worked example of a layered safeguard set. The published set has eight parts:
- a permission system
- context-aware analysis of the full request
- input sanitisation
- network commands such as
curlandwgetleft out of the auto-approved set - an isolated context window for web fetch
- trust verification for first-time codebases and new MCP servers
- command injection detection
- fail-closed matching
Every one of those inspects something different.
Content Policy Is an Engineering Obligation
The governing document is Anthropic's Usage Policy. It has three parts:
- Universal Usage Standards, the prohibitions that apply to everyone.
- High-risk Use Case Requirements.
- Additional Use Case Guidelines, which cover consumer-facing chatbots and agents, products serving minors, agentic use cases and software listed in Anthropic's directories.
The high-risk part turns directly into build work. It applies when Claude is used to make a High-risk AI Recommendation, which means a recommendation in one of eleven named High-risk Areas: legal, medical, finance, credit, insurance, housing, employment, education and credentials, healthcare access, public benefits and services, and legal status and adjudication. Each area is defined by what the recommendation does. Employment, for example, covers screening, ranking, advancing or rejecting candidates, and hiring. Two controls attach to every such recommendation:
- Qualified human-in-the-loop. A qualified person must meaningfully review the recommendation before it is delivered as advice or used to implement a decision, and must have the authority to change or modify it. Qualified means having the training or experience to judge the output in that field, and holding a licence where the law requires one.
- Disclosure. The person who receives the advice, or who is the subject of the decision, must be clearly told that AI was used to produce it.
The policy also lists what falls outside. General information that is not applied to someone's own circumstances is excluded, and so is internal drafting that is not the final recommendation. Where the law allows, one of four listed decisions wholly in the person's favour, such as paying an insurance claim, can go ahead without the review. A partial or conditional approval does not count.
Read those controls as a specification. The review becomes a human gate in the workflow, with a named owner who can change the output. The disclosure becomes a line the affected person sees. Around them sit a refusal path with a defined message, an escalation route, and a log entry that proves the gate ran.
The third part matters to this cert more than its position suggests. If you ship an agent that acts on somebody's behalf, the policy describes your product: you are responsible for making sure that what the agent does, including through tools, browsers and connected systems, complies with the policy.
The chatbot rule in that part applies whether or not a High-risk AI Recommendation is involved. All consumer-facing chatbots or AI agents that communicate directly with external users must disclose that users are interacting with AI rather than a human. At a minimum, the disclosure comes at the beginning of each chat session or in the product interface. It does not have to name Anthropic, Claude or the model, and a friendly persona name does not remove it. The Universal Usage Standards separately prohibit using outputs to convince someone they are talking to a person when they are not.
The plumbing firm's assistant is a consumer-facing chatbot, so it says it is an AI at the start of every chat.
Secure by Design, Made Specific
Least privilege is the smallest set of tools and the narrowest credential scope that still does the job. Remove tools the task does not need rather than denying them at call time. Prefer a read-only tool where reading is enough. Issue a scoped credential rather than an administrative one, so a publishing tool can write one listing without administering the whole content-management system. The firm's booking credential can add one visit to the diary. It cannot edit other customers' jobs.
Privacy here is minimisation applied to the context window. Data the task does not need never enters it. That is a leakage control and a cost control at once. A quote needs the job description and the postcode, not the customer's payment history.
Identity and access management means every tool call resolves to an identity with checkable entitlements. That is the end user's identity where the agent acts on their behalf, and a named service identity where it does not. It is never an anonymous shared credential whose use cannot be attributed afterwards. The firm's booking call carries the customer's identity.
As of September 2026, Workload Identity Federation applies least privilege and identity to the credential itself. A federation rule's match conditions decide which workloads may mint a token. The conditions are a subject_prefix, exact claims such as ref, an audience or a CEL condition. Every condition you configure must pass. On GitHub Actions, repo:your-org/* alone matches every repository in the organisation. With no ref constraint, it also matches pull-request runs from forks. So pin the rule to one repository and a protected branch. The rule's oauth_scope is a ceiling on what the token can reach. A workload that only calls Claude gets workspace:inference, which covers Messages, Models and the OpenAI-compatible endpoint. The setup wizard's workspace:developer also reaches Files, Skills and Managed Agents.
The permission settings in Claude Code and the Agent SDK have allow, ask and deny rules, and deny takes precedence over a narrower allow. A bare-name deny removes the tool from the request entirely. A scoped deny binds in every permission mode, bypassPermissions included. A published evaluation order says which layer wins. That order is where least privilege becomes real or fails to. A check placed after an auto-approval is a check that never runs.
Fail Closed on the Security Path
Here a developer's instincts work against them. In availability engineering, the right move when a dependency is down is usually to degrade gracefully and keep serving. On the security path, do the opposite. The classifier may time out, the validation may come back inconclusive, or the approval service may not answer. In each case, refuse the consequential action and hold it. Do not proceed unguarded and reconcile later. That turns the check into something any dependency failure removes. If the plumbing firm's message classifier times out, the assistant holds the booking.
The handler below applies the pattern to a publishing action.
class ScreenUnavailable(Exception):
pass
def publish_listing(draft, screen, publisher, queue, notify):
"""Fail closed: an unavailable check holds the action, it does not waive it."""
try:
verdict = screen(draft, timeout=5.0)
except (TimeoutError, ScreenUnavailable):
queue.hold(draft, reason="content screen unavailable")
notify("Listing held: the content screen could not run.")
return "held"
if verdict.blocked:
queue.hold(draft, reason=verdict.reason)
notify(f"Listing held: {verdict.reason}")
return "held"
publisher.publish(draft) # credential scoped to one listing, not the whole site
return "published"Two properties make that shippable. First, it separates the consequential action from the whole feature, so holding a publication isn't the same as taking the site down. Second, the held work has somewhere to go and someone to tell. A queue plus a notification beats an error page for that reason. At the firm, a held booking waits in a queue and the office rings the customer.
Claude Code names the same idea in its own safeguards. In Manual mode (config value default), unmatched commands require approval by default. That is fail-closed matching by name. As of September 2026, Manual is not where an interactive session starts: from Claude Code v2.1.283, terminal and VS Code sessions start in auto mode. claude -p and the Agent SDK still start in default. The Agent SDK's dontAsk mode is the mode-level version. It denies any call that would otherwise prompt. That is what a headless agent with nobody to prompt should do. Calls that your allow rules pre-approve still run. So do calls that need no approval in default mode, such as read-only commands.
Retrying is fine; ending the retry chain at the model is not
A fallback that hands the decision back to the model when the classifier is down replaces the enforcement point with the layer that enforces nothing. Layers are not interchangeable either: a stricter output check cannot see what an input screen would have caught before the draft was written.
Rollout and Observation Are Part of the Guardrail
Deployment discipline belongs inside this sub-skill rather than beside it. Stage the exposure. Monitor the security-relevant events specifically, not only the error rate. Red-team your own agent before deploying, with documents and tool outputs that deliberately contain injection attempts. Confirm both that Claude ignores them and that your screening and confirmation steps catch the rest. Give reports a defined path with an owner. Keep a rollback nobody has to argue for.
The plumbing firm opens the assistant to a small share of visitors first. Its red-team set includes job descriptions and tool outputs that tell Claude to waive the call-out charge.
The docs frame monitoring as an input to the guardrails rather than a report about them. Analyse outputs regularly for signs of successful injection. Use what you find to refine prompts, validation and filtering. A guardrail you cannot see firing is a guardrail you cannot maintain. That is why an otherwise well-built deployment with no observation is a wrong answer rather than an incomplete one.
In the exam
The guide phrases the scope as "safe and responsible deployment practices (content policy, guardrail layering) and secure-by-design principles (privacy, identity and access management, least privilege)". It names those three principles. The favourite wrong answer throughout is a safety strategy made of one layer.
The high-risk part of the Usage Policy is the examinable one. There the distractor is almost always a technically sound control that does not discharge the obligation, such as a better classifier where the policy asks for a qualified person's review. The skill being tested is recognising when a scenario has landed inside one of the High-risk Areas at all. Teams routinely build a healthcare triage assistant while thinking of themselves as building a summariser.
Caveats
Claude Code's security documentation adds a warning: while these protections significantly reduce risk, no system is completely immune to all attacks. The Usage Policy's older name, "Acceptable Use Policy", survives in its URL and as an alias.
Exam Traps
Choosing the option that adds a layer when the question is about the enforcement point, so an output check that flags the text is picked over one that blocks the action.
Two options can both describe an output check and differ entirely in what they do when they fire. The keyed one prevents the consequential action; the distractor records that it happened. A model that produced a bad answer and a system that published it are separate failures, and only the second is under your control at that layer.
Choosing graceful degradation because it sounds like good engineering: proceed when the check is unavailable, and reconcile afterwards.
It converts a check into a suggestion that any dependency failure removes, and whoever can cause the failure gets the unguarded path for free. Where a scenario names an unavailable check and a consequential action, the answer holds or refuses. The distractor usually carries a reasonable-sounding availability justification, which is what makes it tempting.
Answering a high-risk-domain scenario with a purely technical control, such as a stronger classifier or a tighter schema.
Where the Usage Policy requires a qualified person to review a High-risk AI Recommendation before it is delivered or acted on, and requires the person affected to be told AI produced it, no amount of engineering discharges that. The keyed answer puts a qualified human in the loop before the output reaches the person it affects, and the technically sound distractor is there precisely because it is technically sound.
Reading least privilege as denying a tool at call time, or treating monitoring, staged rollout and red-teaming as operations rather than guardrails.
Removing a tool from the request is stronger than denying it, a scoped deny binds in every permission mode while an allow rule does not, and a check placed after an auto-approval never executes. Observation is part of the same discipline: the docs treat analysis of outputs as an input to refining the guardrails, so a deployment with good checks and no visibility is failing this sub-skill rather than merely under-instrumented.
Practice Scenario
An ironmonger's trade-supply site publishes product listings that Claude drafts from supplier-submitted copy. An input classifier screens the submissions, an output check runs before publication, and the publishing tool holds the site's full content-management credentials. During a provider incident the classifier call starts timing out. What should the pipeline do?
Build Exercise
Name the Enforcement Point for Every Layer You Claim to Have
What you'll learn
- How to audit a guardrail set by enforcement point rather than by intention
- How to decide fail-closed behaviour for each consequential action in writing
- How to narrow a credential and prove the narrowing
- How to check a deployment against the high-risk obligations in the Usage Policy
- Write your application guardrails as a four-row table: input, system prompt and model, tool level, output. For each row record what it inspects, where the code runs, and what happens when it fires.
Why: The three columns are the definition of a guardrail. Writing them out is what separates the controls from the intentions.
You should see: A four-row table, with at least one row you cannot fill in honestly.
- Strike out any row whose third column is that the model reads something and decides. That row is a behaviour shaper rather than a guardrail.
Why: The exam distractor in this sub-skill is a strategy made of shapers. Seeing your own table shrink makes the distinction permanent.
You should see: A thinner table than you started with, and a clear view of which layers are load-bearing.
- For every consequential action, decide the fail-closed behaviour in writing: what is refused, what is held and queued, who is notified, and how held work resumes once the check is available again.
Why: Fail closed is only shippable when the held path has somewhere to go, and the resume path is the half teams forget until a queue silently fills.
You should see: One paragraph per consequential action, naming the queue, the notification and the resume trigger.
- Re-scope the credential behind each tool to the narrowest thing that still does the job, then prove the narrowing by attempting the wider action and watching it fail.
Why: Least privilege is about blast radius rather than about what the current call happens to need, and an unproven narrowing is a comment rather than a control.
You should see: A failed wider call, captured in your notes with the error it returned.
- Check your scenario against the High-risk Areas in the Usage Policy. If it lands in one, add a review by a qualified person who can change the output before it is delivered or acted on, tell the affected person clearly that AI produced it, and log that the gate ran.
Why: The obligation is on the deployment rather than on the model, and the exam keys the human in the loop specifically where a technical control cannot discharge it.
You should see: Either a written finding that your use case is outside the High-risk Areas, or a gate, a disclosure string and a log entry.
- Red-team the finished thing with your own adversarial submissions, then add monitoring on the security-relevant events specifically, so the next refinement comes from evidence rather than from a hunch.
Why: The docs treat analysis of outputs as an input to the guardrails, which makes red-teaming and monitoring part of the control set rather than operations around it.
You should see: A short list of attempts, which layer stopped each, and at least one new monitored event.
Sources
- Usage Policy — Anthropic, the three parts, the High-risk Areas, the human-in-the-loop and disclosure controls, the exclusions, and the chatbot AI-disclosure rule
- Mitigate jailbreaks and prompt injections — Anthropic, input and tool-output screening, continuous monitoring, red-teaming and chained safeguards
- Security — Anthropic, a shipped layered safeguard set, fail-closed matching, and the no-system-is-immune caveat
- Configure permissions (Claude Agent SDK) — Anthropic, the evaluation order, deny precedence, and dontAsk as the fail-closed mode
- Configure permissions (Claude Code) — Anthropic, allow, ask and deny rule syntax and the scopes they load from
- Choose a permission mode — Anthropic, Manual mode as the config value default, auto as the interactive starting mode from v2.1.283, and dontAsk
- Workload Identity Federation — Anthropic, federation rule match conditions
- Use WIF with GitHub Actions — Anthropic, pinning a rule to one repository and a protected branch
- WIF reference — Anthropic, oauth_scope values and the scope as a ceiling
- Structured outputs — Anthropic, constraining a screening verdict to a parseable value
- Claude Certified Developer Foundations Exam Guide — Domain 7, Guardrails and Safe Deployment — Anthropic