7.2 — Guardrails and Safe Deployment

What You Need to Know

A guardrail is a check with an enforcement point. It inspects something. When it fires, it stops or changes what happens next. A behaviour shaper is different: the model reads something and decides. To fail closed means to refuse the guarded action when its check cannot run. Sub-skill 7.1 named the controls. This sub-skill asks where each control runs and what it does when it fires.

This lesson uses one made-up example throughout: a travel booking website that has a chat assistant. Customers describe the trip in their own words. Claude drafts a quote, and a booking tool reserves the hotel room. Every customer message is untrusted input. Booking a room 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. List it separately from the guardrails.

Most guardrail tables lose entries the first time somebody applies this test. A system-prompt rule inspects nothing and enforces nothing. A log records events after they happen. A dashboard alerts a human who may be asleep. All three are worth having. None of them is a guardrail.

At the travel site, a system-prompt line saying "always ask for the travel dates" is a shaper. A check in the booking tool that rejects a booking with no travel dates 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 layer that checks in a different way. That is the reason to use layers.

Input checks run before the model sees anything. They include classification with a lightweight model, pattern filtering, redaction, and plain validation of size and type. They are cheap and useful, but they are probabilistic. They see only what arrives through the channel that they are on. The travel site's classifier screens chat messages. It sees nothing that reaches Claude by another route.

The system prompt and the model's training are the middle layer. They shape behaviour, and it is recommended that you state an untrusted-content policy there. They enforce nothing. That last sentence is the most important sentence in the sub-skill. At the travel site, nothing in the prompt stops a booking if Claude follows an instruction hidden in a customer message.

Tool-level controls are the layer that enforces. 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. Removing a tool is stronger than denying it, because Claude cannot attempt a tool that is not in the request. The travel site's assistant has no refund tool, so no message can persuade it to give a refund.

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. Developers skip that part. A model that produced a bad answer and a system that published it are two different failures. The output layer prevents the second failure. The output check should stop a quote with a nonsense price before it reaches the customer.

Claude Code includes a worked example of a set of safeguards in layers. The published set has eight parts:

a permission system
context-aware analysis of the full request
input sanitisation
network commands such as curl and wget, excluded from 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 creates build work directly. It applies when Claude is used to make a High-risk AI Recommendation. That is a recommendation in one of eleven named High-risk Areas. The areas are legal, medical, finance, credit, insurance, housing, employment, education and credentials, healthcare access, public benefits and services, and legal status and adjudication. The policy defines each area by what the recommendation does. Employment, for example, covers screening, ranking, advancing or rejecting candidates, and hiring. Two controls apply 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. That person must have the authority to change or modify the recommendation. Qualified means that the person has the training or experience to judge the output in that field. It also means that the person holds 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 is outside its scope. It excludes general information that is not applied to someone's own circumstances. It also excludes internal drafting that is not the final recommendation. The policy lists four decisions that are wholly in the person's favour, such as paying an insurance claim. Where the law allows, one of these decisions can proceed 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: a step where a person reviews the output before it goes further. The gate has a named owner who can change the output. The disclosure becomes a line that the affected person sees. The specification also includes 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 release an agent that acts on somebody's behalf, the policy describes your product. You are responsible for making sure that what the agent does complies with the policy. This includes what the agent does through tools, browsers and connected systems.

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. The disclosure does not have to name Anthropic, Claude or the model. A friendly persona name does not remove the requirement. The Universal Usage Standards separately prohibit using outputs to convince someone they are talking to a person when they are not.

The travel site'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 travel site's booking credential can create one reservation. It cannot edit other customers' reservations.

Privacy here means minimising what enters the context window. Data the task does not need never enters it. That rule controls leakage and cost at the same time. A quote needs the trip description and the travel dates, not the customer's payment history.

Identity and access management means every tool call resolves to an identity with checkable entitlements. Where the agent acts on the end user's behalf, that identity is the end user's identity. Where the agent does not, it is a named service identity. The identity is never an anonymous shared credential whose use cannot be attributed afterwards. The travel site'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 get a token. The conditions are a subject_prefix, exact claims such as ref, an audience or a CEL condition, an expression written in the Common Expression Language. 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 limit the rule to one repository and a protected branch. The rule's oauth_scope sets the maximum access that the token can have. 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 gives access to Files, Skills and Managed Agents.

The permission settings in Claude Code and the Agent SDK have allow, ask and deny rules. Deny takes precedence over a narrower allow. A deny rule with only the tool name removes the tool from the request entirely. A scoped deny applies in every permission mode, including bypassPermissions. A published evaluation order says which layer takes effect. That order decides whether least privilege works in practice. A check that comes after an auto-approval never runs.

Fail Closed on the Security Path

Here a developer's instincts give the wrong answer. In availability engineering, when a dependency is down, the right action is usually to degrade gracefully and continue to serve. On the security path, do the opposite. The classifier may time out, the validation may return an inconclusive result, or the approval service may not answer. In each case, refuse the consequential action and hold it. Do not proceed unguarded and reconcile later. If you do, any dependency failure removes the check. If the travel site's message classifier times out, the assistant holds the booking.

The handler below applies the pattern to the travel site's booking action.

python

class ScreenUnavailable(Exception):
    pass

def book_room(request, screen, reservations, queue, notify):
    """Fail closed: an unavailable check holds the action, it does not waive it."""
    try:
        verdict = screen(request, timeout=5.0)
    except (TimeoutError, ScreenUnavailable):
        queue.hold(request, reason="message screen unavailable")
        notify("Booking held: the message screen could not run.")
        return "held"

    if verdict.blocked:
        queue.hold(request, reason=verdict.reason)
        notify(f"Booking held: {verdict.reason}")
        return "held"

    reservations.reserve(request)   # credential scoped to one reservation, not every booking
    return "booked"

Two properties make this fail-closed behaviour ready for production use. First, it separates the consequential action from the whole feature. So holding a booking is not the same as taking the site offline. Second, the held work goes to a queue and someone is notified. For that reason, a queue plus a notification is better than an error page. At the travel site, a held booking waits in a queue and the support team contacts the customer.

Claude Code names the same idea in its own safeguards. In Manual mode (config value default), unmatched commands require approval by default. This behaviour is fail-closed matching by name. As of September 2026, an interactive session does not start in Manual mode. 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 same idea at the level of a mode. It denies any call that would otherwise prompt. That is what a headless agent (one with no person present to answer a 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; making the model the final fallback when the retries fail is not

Suppose a fallback returns the decision to the model when the classifier is down. That fallback 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 is part of this sub-skill, not a topic beside it. Increase the exposure in stages. Monitor the security-relevant events specifically, not only the error rate. Before you deploy, red-team (deliberately attack) your own agent 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 that you can use without debate.

The travel site opens the assistant to a small share of visitors first. Its red-team set includes trip descriptions and tool outputs that tell Claude to waive the booking fee.

The docs treat 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. If you cannot see a guardrail fire, you cannot maintain it. That is why a deployment that is otherwise well built but has no monitoring 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)". The guide names those three principles. The most common wrong answer throughout is a safety strategy made of one layer.

The high-risk part of the Usage Policy is the examinable one. In that part, the wrong option is almost always a technically sound control that does not meet the obligation. An example is a better classifier where the policy asks for a qualified person's review. The exam tests whether you recognise when a scenario is inside one of the High-risk Areas at all. Teams routinely build a healthcare triage assistant but think that they are 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", remains in its URL and as an alias.

Exam Traps

Exam Trap

Picking an output check that flags the text over one that blocks the action

An output check that flags text is a report; one that blocks the action is a guardrail. A verdict sent to a dashboard prevents nothing. Make the publish call depend on the verdict.

Exam Trap

Choosing graceful degradation: proceeding when the check is unavailable and reconciling afterwards

Suppose a check lets the action proceed when the check cannot run. Then whoever can make the check fail can act without the check. Hold the consequential action, queue it and notify an owner.

Exam Trap

Answering a high-risk-domain scenario with a purely technical control, such as a stronger classifier

Technical layers do not satisfy a policy obligation. For a High-risk AI Recommendation, a qualified person who can change it must review it first, and the affected person must be told AI was used.

Exam Trap

Relying on a canUseTool callback that rejects the tool at call time to enforce least privilege

Auto-approved tools never reach canUseTool, so its check is skipped for anything an earlier step approved. A scoped deny rule applies in every permission mode. Remove the tool with a bare-name deny rule.

Practice Scenario

A helpdesk software company publishes integration listings in its app directory. Claude drafts them from partner-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?

Option AHold the listings unpublished until a check can run again, and cut the publishing credential down to the single listing scope it needs

Option BKeep publishing but raise the strictness of the output check for the duration of the incident, so the later layer compensates for the missing one

Option CRetry the classifier a fixed number of times, then fall back to the judgement of the model on the submitted copy

Option DPublish the listings and flag them for review afterwards, since blocking on an unavailable dependency turns a provider outage into an outage of your own

Build Exercise

Name the Enforcement Point for Every Layer You Claim to Have

Difficulty

35 minutes

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 tempting wrong answer in this sub-skill is a strategy made of behaviour shapers. Seeing your own table shrink helps you remember the distinction.
You should see: A thinner table than you started with, and a clear view of which layers actually enforce something.
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 a narrowing that you have not tested is not 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 is 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 makes the human in the loop the right answer specifically where a technical control cannot meet the obligation.
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