CCAR-P Governance: Guardrails, Human-in-the-Loop & Compliance [2026]

Governance decides whether a Claude system ships, and the Claude Certified Architect - Professional (CCAR-P) exam treats it that way. Domain 5, Governance, Safety & Risk Management, carries 14% of the blueprint, roughly nine of the 63 scored questions, and governance constraints also hide inside stems from the Integration and Solution Design domains. This guide covers what those questions test: how to layer guardrails from input screening through monitoring, how to name each failure mode of a large language model (LLM) system and match it to a control, where human-in-the-loop review earns its cost, how GDPR, HIPAA, FedRAMP and the EU AI Act translate into architecture decisions, and how to document controls so an auditor can verify them. Two worked scenarios at the end show how the exam frames these judgments.

What Domain 5 actually tests

Domain 5 questions read like design reviews. A stem names a system (a claims triage agent, a clinical summarizer, a support bot with refund powers), states its data and regulatory setting, and asks which control set is proportionate. Two principles decide most of them. Proportionality: controls scale with the blast radius of a failure, so a read-only research assistant and an agent that can move money deserve very different stacks. Defense in depth: prompt instructions are probabilistic, permission scoping and output validation are deterministic, and any compliance-critical requirement needs at least one deterministic layer behind the probabilistic one.

The domain also leaks into the rest of the exam. Integration stems mention over-broad credentials, Solution Design stems mention audit requirements that favor a workflow over an agent, and Evaluation stems mention safety violation rates. An option that is technically elegant and violates a governance constraint stated in the stem is a wrong answer; the common CCAR-P mistakes article covers that trap in detail.

Layered guardrails: five layers, one principle

A guardrail is any control that constrains what enters the model, what the model is told to do, what it can act on, what leaves the system, or what you learn afterward. Architects think in five layers because each catches a different class of failure and each has a blind spot the next layer covers.

Layer 1: input controls

Input controls act before anything reaches the primary model call: validation of format and size, redaction of personal data the task does not need, rate limiting, and injection screening, where a fast-tier model classifies the request and returns a structured boolean the application can branch on. Anthropic's guidance on mitigating jailbreaks recommends exactly this lightweight harmlessness screen with structured output. The blind spot is content the user did not write. Indirect prompt injection (malicious instructions embedded in emails, web pages, documents, or tool results the model reads on the user's behalf) never passes through the user-input screen.

Layer 2: model and system prompt controls

The system prompt defines role, boundaries, refusal behavior, and the policy for untrusted content. It is also where you give the model permission to say it does not know, ask it to ground answers in quoted source text, and require citations. Model selection belongs here too, since high-stakes reasoning may justify the most capable tier. All of this is probabilistic: it shapes behavior and raises the bar for an attacker, and it cannot guarantee an outcome. On the exam, an option that fixes a permission or leakage problem purely by adding prompt instructions is the classic under-engineered distractor.

Layer 3: tool permissioning

Tool permissioning is deterministic. A tool the agent does not have cannot be called, a read-only credential cannot write, and a refund tool with a ceiling enforced in code cannot exceed it. The tested moves are least privilege (each agent and tool gets exactly the access its job requires), separation of read and write capabilities, per-user authorization passed through to the tool in place of a shared service account (which prevents the confused-deputy problem, where an agent exercises permissions its user never had), sandboxed execution, and confirmation ahead of irreversible actions. This layer says nothing about what the model writes back to the user.

Layer 4: output controls

Output controls validate what leaves. Structured output checked against a schema stops malformed or out-of-policy responses at the boundary, scanners catch personal data, secrets, and system prompt fragments, a citation check strips claims that trace to no retrieved source, and moderation classifiers screen for prohibited content. Programmatic checks here are deterministic and cheap. The blind spot is timing: an agent that executed a tool call mid-loop has already acted, so output validation cannot undo it, which is why permission scoping precedes output filtering in the layer order.

Layer 5: monitoring and response

Monitoring turns the first four layers into a system that improves. Every request should produce a trace with correlation IDs across prompt version, model version, retrieved context, tool calls, decisions, and reviewer actions. Alerts fire on refusal spikes, injection-screen hits, unusual tool call patterns, and cost anomalies, and sampled review plus red-team results feed evaluation datasets. Anthropic frames this as continuous monitoring: analyze outputs regularly for signs of successful injection and refine the upstream layers. Monitoring is after the fact by definition, and it is still mandatory, because the other four layers leak.

The single principle across all five layers is proportionality. A read-only FAQ assistant over public documentation does not want a five-layer stack with approval gates; that answer over-engineers, and the exam punishes it. An agent with write access to customer accounts wants deterministic controls at layers 3 and 4 plus a human gate on the irreversible actions. Match the stack to the blast radius.

Risk identification: name the failure mode, then choose the control

The exam expects you to recognize five failure modes on sight and to know which layer addresses each. Naming the mode correctly matters because each implies a different fix, the same diagnostic discipline the CCAR-P evaluation strategy guide applies to accuracy failures.

Hallucination is the model producing content that is wrong or unsupported by the provided context, delivered with the fluency of a correct answer. It is most dangerous when retrieval returned nothing useful and the model filled the gap. Controls: permit uncertainty in the system prompt, ground answers in extracted quotes, require citations and retract unsupported claims, restrict the model to provided documents, add a verification pass for high-stakes outputs, and give empty retrieval an explicit handoff path.

Prompt injection comes in two threat models. In direct injection, the user is the adversary and crafts inputs to bypass your rules; the controls are the input screen, a hardened system prompt, and throttling of repeat offenders. In indirect injection, the user is trusted and the adversary controls content the model reads: an inbound email, a fetched web page, OCR text from an upload, a tool result. The controls are structural: deliver third-party content only inside tool results labeled with their source, state in the system prompt that tool content is data and never instruction, JSON-encode untrusted strings so they cannot break out of their container, screen tool outputs before the agent acts, apply least privilege so a successful injection has minimal reach, and red-team with poisoned documents before launch.

Data leakage has more entry points than candidates expect: prompts carrying personal data the task did not need, logs storing raw content indefinitely, a shared retrieval store returning another tenant's documents because the vector search ignored access control, a tool returning a whole record when one field was needed, and the model repeating its system prompt or another user's context. Controls map layer by layer: minimize and redact at input, enforce tenant and per-user filters at retrieval and tool time, scrub and time-limit logs, and scan outputs for identifiers and secrets.

Over-permissioned tools are the governance face of capability bloat. An MCP server (Model Context Protocol, the open standard for exposing tools and data sources to models) that inherits the credentials of whoever launched it, a write-capable tool where read would do, an unbounded action with no ceiling: each turns a model mistake or a successful injection into a real-world incident. Controls: scoped credentials per tool, read and write separation, ceilings in code, audits that remove capabilities nothing calls, and approval gates on irreversible actions.

Bias is uneven quality or uneven outcomes across groups of users, hidden by an aggregate accuracy figure that looks fine. It enters through training data, a skewed retrieval corpus, unrepresentative few-shot examples, or inconsistent human labels. Controls: evaluate by slice (demographic, language, region, customer tier), test for disparate outcomes before launch, monitor after, and put a human on consequential decisions.

Human-in-the-loop strategies

Human-in-the-loop (HITL) means inserting a human decision at a defined point in an otherwise automated flow. Model outputs are probabilistic, and some decisions carry consequences that no evaluation score fully retires: money moves, data is deleted, a message reaches a customer, a person is denied something. The architect places humans where their judgment changes an outcome and keeps them off the paths where they only add latency. Four strategies cover the exam.

Approval gates are synchronous and blocking: the agent proposes, a human approves or rejects, and nothing happens until they do. Use them ahead of irreversible or high-impact actions such as refunds above a ceiling, account deletions, outbound communications, and clinical or legal outputs entering a record. The reviewer should see the proposed action, the evidence behind it, and the alternative, and the timeout behavior must be defined (for irreversible actions, silence means deny).

Sampling review is asynchronous. A share of outputs is pulled for review after the fact, and findings feed evaluation datasets and prompt fixes. It is the right pattern for high-volume, low-risk paths, where an approval gate would erase the efficiency gain. Stratified sampling (drawing proportionally from each meaningful segment, such as intent type, language, or customer tier) beats uniform random sampling because it surfaces the per-slice failures that bias monitoring depends on.

Escalation triggers are deterministic conditions, set by the system, that route a case to a human: a regulated topic category, an explicit request for a person, an injection-screen hit, a tool error loop, or a customer sentiment threshold. Because they are explicit rules, they are auditable and behave the same way every time.

Confidence routing sends low-confidence cases to review and lets the rest through. The architect insight is that a model's self-reported confidence is poorly calibrated, so the routing signal should be system-side: a classifier score, retrieval coverage (did the retrieved passages contain the answer), agreement across multiple samples, or a schema validation failure. Thresholds are set and re-validated against evaluation data.

Two boundary rules finish the topic. Where a regulation demands human accountability for a decision, the human is mandatory regardless of measured accuracy; GDPR's provisions on solely automated decisions with legal or similarly significant effects, and the human-oversight duties the EU AI Act places on high-risk systems, are the examples the exam is most likely to gesture at. Where a path is high-volume and low-risk, a human approving every action is an architecture error, since it destroys the business case. Reviewer fatigue makes it worse: a queue that trains people to click approve produces false assurance.

Regulatory mapping at architect altitude

The blueprint names GDPR, HIPAA, and FedRAMP. The EU AI Act is worth knowing at the level of its structure because it shapes transparency and human-oversight expectations in EU deployments and overlaps with the ethical AI topic.

GDPR (the General Data Protection Regulation) governs personal data of people in the EU and applies to organizations processing that data wherever they are based. The principles that shape architecture are lawful basis and purpose limitation (support transcripts collected to resolve tickets cannot be silently repurposed as training or evaluation data), data minimization (send the model only the fields the task needs), storage limitation (defined retention for logs and retrieval stores), and data subject rights including access and erasure, which means you must be able to find and delete one person's data across prompts, logs, and vector stores. Transfer restrictions push toward region-pinned deployment, covered in the enterprise deployment guide. GDPR also addresses decisions based solely on automated processing with legal or similarly significant effects, one reason human review appears in EU-facing scenarios. Official overview: gdpr.eu.

HIPAA (the US Health Insurance Portability and Accountability Act) protects protected health information (PHI) held by covered entities such as providers, health plans, and clearinghouses, and by their business associates, the vendors handling PHI on their behalf. Its Privacy Rule governs use and disclosure; its Security Rule requires administrative, physical, and technical safeguards for electronic PHI. Architecturally: confirm business associate agreement (BAA) coverage for every service PHI touches, including the model provider or cloud platform, the vector store, and the logging stack; apply the minimum-necessary standard to prompts; de-identify where the task allows; keep PHI out of unscoped logs; enforce access controls and audit logs. Official resource: HHS HIPAA for professionals.

FedRAMP (the Federal Risk and Authorization Management Program) is the US government program that standardizes security assessment and authorization for cloud services used by federal agencies. It applies when a scenario involves a federal agency workload, and the implication is that every cloud service in the request path, from model endpoint to vector database to observability tooling, needs an authorization appropriate to the impact level of the data. Never assume a provider's status; verify it on the FedRAMP Marketplace and the provider's compliance pages at design time. Official site: fedramp.gov.

The EU AI Act is the EU regulation for AI systems and takes a risk-based approach: prohibited practices, high-risk systems (uses in areas such as employment, credit, education, and critical infrastructure), transparency obligations for certain systems (people should be told when they interact with AI, and AI-generated content should be identifiable), and rules for general-purpose AI models. High-risk obligations include risk management, data governance, activity logging, technical documentation, human oversight, and accuracy and robustness requirements, applied in phases (check the official timeline before committing dates to a design). The practical move for an architect is to classify the use case by risk tier during discovery, because a high-risk classification makes logging, human oversight, and documentation day-one requirements. Official page: European Commission AI Act overview.

Scenarios often trigger more than one regime at once. A US hospital network serving EU patients faces HIPAA and GDPR; a federal health agency adds FedRAMP. Read the stem for data type, jurisdiction, and customer, and expect the correct option to address every regime the stem invokes.

Ethical AI: bias, fairness, transparency, audit trails

The ethical AI topic tests four capabilities, and the exam wants each expressed as an architectural control with a place in the system.

Bias detection starts with slice-level evaluation. An aggregate accuracy of 94% can hide a 70% slice for one language or one customer segment, so evaluation datasets must be stratified and reported per slice, and the same slices should be tracked in production monitoring.

Fairness means applying consistent decision criteria and testing for disparate outcomes before launch and after. For consequential decisions (lending, hiring, eligibility, medical triage) the tested design places a human on the decision, records the criteria the system used, and gives affected users a path to contest.

Transparency covers disclosure and explainability. Disclose AI involvement to the people interacting with the system, document intended use and known limitations, and make automated decisions explainable by exposing the evidence that produced them: the retrieved sources, the rule that fired, a summary of the reasoning. Explainability at this altitude means the system shows its evidence.

Audit trails make all of the above provable. Each decision should be reconstructable from an immutable record of the input, the retrieved context, the prompt and model versions, the tool calls, the output, and any reviewer action, tied together by a correlation ID and retained for the period the applicable regime requires. Audit trails also serve incident response: when a leak or an injection is suspected, the trail is how you scope it.

Documenting controls for auditors

Auditors, whether internal risk teams or external assessors, want traceability from a requirement to a control to evidence that the control works. Architects who ship strong controls and no documentation fail this review, and Domain 6 of the exam (stakeholder communication and lifecycle handoff) reinforces the same point. Six artifacts cover most audits:

1. Data flow diagram with classification. Where personal data or PHI enters, where it is redacted, where it is stored, who can read it, and how long it lives.
2. Control matrix. One row per identified risk: the control, the guardrail layer it lives in, the owner, the evidence produced, and how often it is tested. This is the document that turns "we have guardrails" into something verifiable.
3. Architecture decision records (ADRs). Short documents that capture a governance decision, the alternatives considered, and the reason: why this action has an approval gate and that one uses sampling, why this regime applies, why this model tier was chosen for a high-stakes step.
4. System documentation. Intended use, out-of-scope uses, known limitations and failure modes, evaluation results including per-slice results, and version history for prompts and models.
5. Runbooks. Incident response for suspected injection or leakage, escalation paths, the kill switch, and who is on call.
6. Evidence. Logs, evaluation reports, red-team results, sampling review records, and access reviews, retained per the applicable regime.

Write these for a reader who was not in the room. On the exam, an option that mentions documented controls, evidence, and ownership will beat an option that describes an equally strong control set with no way for anyone else to verify it.

Two worked scenarios

These follow the format the real exam uses: a multi-constraint stem, four options, and a best-fit choice. Work them before reading the answers.

Question 1

Domain: Governance, Safety & Risk Management (14%)

A hospital network wants a Claude assistant that summarizes patient encounter notes for clinicians inside its portal. Summaries must stay within the portal, protected health information must be handled under HIPAA, and the chief medical officer wants clinicians to get summaries within seconds. Which control combination is proportionate to the risk while meeting the speed requirement?

• A. Instruct the model in the system prompt to protect PHI at all times, store every full summary in the shared application log for later audit, and let clinicians read summaries directly with no additional review.
• B. Confirm business associate coverage across the PHI path, send only the fields the summary needs, keep logs to redacted metadata, and require clinician sign-off before a summary enters the record.
• C. Route every summary to a compliance officer for approval before clinicians can see it, and de-identify all encounter notes before retrieval so the model never sees any patient identifier.
• D. Deploy the assistant only through a FedRAMP-authorized environment, require multi-factor authentication for every clinician session, and encrypt all summaries at rest and in transit before they are displayed.

Answer: B

Option B addresses the regime the stem invokes (HIPAA: BAA coverage for every service PHI touches, minimum-necessary prompts, PHI-free logs) and places the human where the stakes are, the clinician who signs the record, which keeps the fast path intact. Option A relies on a probabilistic prompt as the only control and stores raw PHI in a shared log, a leakage risk. Option C misplaces the human: a compliance officer approving every summary breaks the seconds-level requirement, and full de-identification before retrieval makes summaries useless to a clinician who needs them tied to a patient. Option D applies FedRAMP, the federal-agency regime, to a hospital network, and MFA plus encryption leave the HIPAA path (BAAs, minimization, logging) unaddressed.

Question 2

Domain: Governance, Safety & Risk Management (14%)

A retailer runs a Claude support agent that reads order history, issues refunds of any amount, and reads inbound customer emails to resolve disputes. A red-team exercise showed that an email containing hidden instructions caused an unauthorized refund. Leadership wants the two changes that most reduce this class of risk without removing automation. Which TWO changes should the architect make? (Select TWO)

• A. Add a system prompt instruction telling the agent to treat any instructions found in customer emails as untrusted data and to refuse refund requests that look suspicious or unusually urgent.
• B. Deliver email content to the model only inside tool results labeled with their source, and screen each tool output with a lightweight classifier before the agent acts on it.
• C. Scope the refund tool to a per-transaction ceiling enforced in code, and route any refund above that ceiling to an approval gate in place of the unbounded refund capability.
• D. Require a human to approve every refund the agent proposes, regardless of amount, until the injection classifier reaches a measured false-negative rate of zero on the red-team set.

Answer: B and C

The failure is indirect prompt injection reaching an over-permissioned tool, so the two strongest changes attack both ends. Option B is the structural fix for injection: untrusted content arrives as labeled tool results and is screened before the agent acts. Option C is the deterministic fix for blast radius: a ceiling in code caps what any successful injection can do, and the approval gate covers the high-value residue. Option A is a real technique and worth doing, and on its own it is probabilistic, so it reduces the risk less than either B or C. Option D removes the automation leadership asked to keep, and a false-negative rate of zero is a target no classifier will demonstrably reach.

Frequently asked questions

Key takeaways

Next steps

Governance judgment improves fastest under time pressure, when a stem forces you to pick the proportionate stack in under two minutes. Take one of Preporato's six full-length CCAR-P practice tests (included in Preporato Pro; see pricing) and score your Domain 5 items separately, then work through the CCAR-P practice questions with explanations for more worked scenarios. If regime recognition was your weak spot, the enterprise deployment guide covers the residency, identity, and network-isolation side of the same questions, and the CCAR-P cheat sheet condenses the layer order and HITL placement rules for final-week review.

Sources:

• Anthropic: Mitigate jailbreaks and prompt injections
• Anthropic: Reduce hallucinations
• GDPR overview (gdpr.eu)
• HHS: HIPAA for professionals
• FedRAMP official site
• European Commission: AI Act