What You Need to Know
A risk register has one row for each way a system can fail. It is an architecture artefact, not a document: each row changes the build. Every row has five fields.
- Mechanism. What goes wrong, in the language of the system rather than of assurance.
- Blast radius. How far the consequence reaches, who bears it, and whether it can be undone.
- Detection signal. What moves in the telemetry while it is happening.
- Owning control. Which control carries it, and which of objective 5.1's surfaces it sits on.
- Residual, and who accepted it. A risk with no owning control is an accepted risk, and acceptance is a decision somebody signs. Domain 6 carries it to them.
Take a pest control firm whose Claude agent answers customers, books visits and issues refunds. One row: the agent gives a wrong time to keep pets out of a treated room. That cannot be undone.
Anthropic's Responsible Scaling Policy has the same shape one layer down. It defines capability thresholds and commits to upgrading safeguards when one is reached: a register row with a threshold and a pre-agreed response, not a promise to be careful.
Confident Fabrication Does Not Fail Loudly
The characteristic failure of these systems is fluent, plausible and unflagged. It never shows in an error rate, because nothing errored.
Anthropic's hallucination guidance says its techniques significantly reduce hallucinations but do not eliminate them, and critical information must always be validated. So anything consequential, like the firm's re-entry time, needs a verifiable basis, not a plausible one. That is why "we tested it thoroughly and it worked" is not a risk assessment.
Non-Determinism, and the Assurances It Breaks
The same input can produce different outputs. Three consequences follow. One passing test proves nothing, and one clean re-run does not clear a hypothesis. Reproducing a decision for an audit months later needs the recorded trace, because re-running the prompt produces a fresh answer, not the original. A disputed re-entry time needs the stored conversation.
Injection, Restated as a Risk
Objective 5.1 treats untrusted input as a control problem. On the register it becomes a row whose blast radius is the agent's permission set. A compromised turn on an agent that can only read and summarise is a contained incident. On an agent holding a payment tool, like the firm's refund tool, it is a breach.
So the row names the permission set, which you control, not the injection technique, which will change.
Autonomy Compounds Error
In an agent loop, a modest per-step error rate compounds, and every additional autonomous action widens the blast radius. Anthropic says autonomy means higher costs and the potential for compounding errors, and recommends extensive testing in sandboxed environments with guardrails. It says agents suit tasks with clear success criteria and meaningful oversight, and can pause for feedback at checkpoints or when blocked.
So the levers are scope, step count, reversibility and checkpoints. Accuracy is not one of them. The firm's agent should pause before refunds.
The Three Rows Registers Usually Omit
Over-refusal. Every safety control is paid for in legitimate requests denied. A safety programme with no over-refusal metric optimises in one direction and calls it progress, which is why Domain 4's safety metric is two-sided.
Over-reliance downstream. A reviewer who approves everything is not a control. The ICO names automation bias: users rely routinely on a system's output and stop applying their own judgement. So rubber-stamping is the default unless the gate is designed against it. Objective 5.3 owns that.
Third-party surface. Every connector, MCP server, subprocessor and analytics vendor in the path can see data and sometimes act. Anthropic's retention documentation puts third-party integrations outside its arrangements entirely and tells customers to review each service's data handling. Their access is your risk posture. Their agreements are your compliance posture, which objective 5.4 picks up. The firm's booking connector gets a row.
Rank by Consequence and Detectability
Rank by consequence and detectability, not likelihood. A rare irreversible action outranks a frequent reversible one. A silent failure in an uninstrumented path outranks a loud one anybody would notice by lunchtime. The wrong re-entry time outranks a double booking.
The Column That Fails Most Registers
"How would we notice?" is a required field and the one teams skip. Any row whose honest detection signal is "a customer would complain" has no detection. It fires after the harm, through a channel that only catches the harms people report. Mark those rows. They are where the next incident comes from.
In the exam
A per-item accuracy figure quoted for a multi-step autonomous workflow tells you almost nothing.
Exam Traps
Accepting a high accuracy figure as the risk posture for a system that takes actions
An accuracy number measures one axis under one distribution. It carries no reversibility, no exposure, no recourse and no answer to how the failure would be noticed in production, which is four of the five fields a register row needs.
Extending the back-test to a larger historical sample before launch
More of the same evidence on the same axis. Ten times the sample still produces a number with nothing attached, and the option is written to look diligent precisely because it changes the size of the answer rather than the question.
Adding a disclaimer or a notice to an action that has already left the organisation
A cosmetic fix on the wrong side of the harm. The message has been sent or the charge applied; the wording neither prevents the error nor detects it, and it transfers no consequence away from the person who received it.
Recording a human review step as the owning control with no override rate behind it
Automation bias makes an unmeasured gate a rubber stamp by default. A control whose effectiveness has never been observed is an assumption sitting on the register, and the residual it is supposed to close is still open.
Practice Scenario
An agent will chase overdue invoices: it reads the ledger, drafts an email, sends it, and can apply a late-payment charge. The team's risk assessment reads, in full, tested on 200 historical invoices, 98% accuracy. The sponsor wants to know what a wrong email or charge would cost and how the team would notice one. What should the architect require before launch?
Build Exercise
Write the Risk Register for One Claude System
What you'll learn
- How to separate irreversible actions from reversible ones and name who bears each consequence
- How to work the durable limitation classes into concrete rows for a specific system
- How to give every row a mechanism, a blast radius, a detection signal, an owning control and a named accepter
- How to rank by consequence and detectability instead of likelihood
- How to test a register against the question of what would move in the telemetry first
- List the actions your system can take that cannot be undone, and write next to each who bears the consequence and what their recourse is
Why: Irreversibility and recourse decide the design. Starting here stops the register from becoming a list of engineering worries.
You should see: A short list of actions with a named bearer and a recourse route, including at least one row where the recourse is honestly none.
- Work the limitation classes one at a time and write a concrete row for each: non-determinism, confident fabrication, corpus and knowledge boundaries, untrusted input, over-refusal, compounding error under autonomy, over-reliance downstream, third-party access
Why: The classes are the recall part of this objective, and forcing a row for each is what turns recall into a design artefact.
You should see: Eight rows, or fewer with an explicit written reason why a class does not apply to this system.
- Give each row its five fields: mechanism, blast radius, detection signal, owning control with its 5.1 surface, and the name or role that accepted the residual
Why: A row missing the owner or the signal discharges nothing, and those are the two fields teams leave blank.
You should see: A complete table with no empty cells in the owner column.
- Rank the rows by consequence and detectability rather than likelihood, then mark every row whose real detection signal is that a user would complain
Why: The risks that hurt most fail quietly in paths nobody instrumented, and the ranking is where that becomes visible.
You should see: A reordered register with the silent, irreversible rows at the top and the complaint-driven rows flagged.
- Defend the register one row at a time against a single question: if this fired tonight, what would move in the telemetry before anyone told us?
Why: It is the fastest test of whether the detection column is real, and it usually sends two or three rows back to Domain 3 for instrumentation.
You should see: A named metric, log or alert per row, and a list of the rows that sent you back to instrument something.
Sources
- Reduce hallucinations — Anthropic
- Building effective agents — Anthropic
- Responsible Scaling Policy — Anthropic
- API and data retention — Anthropic
- How do we ensure individual rights in our AI systems? — Information Commissioner's Office
- Claude Certified Architect Professional Exam Guide (v1.0) — Domain 5 — Anthropic