Assign treatment and authorize residual risk

Learning objective

Design risk treatment plans with accountable owners, mitigations such as fallbacks, budgets, and kill switches, and explicit acceptance of residual risk.

Core idea

For an architect moving from a ranked register to a release decision, each high-priority risk needs an executable treatment and someone authorized to own its remaining consequence. “Add monitoring” or “the team accepts it” leaves the implementation, response, and decision authority unspecified.

NIST AI RMF MANAGE 1.3 identifies mitigation, transfer, avoidance, and acceptance as response options. MANAGE 1.4 calls for documenting negative residual risks. GOVERN 2.1 requires clear roles and responsibilities, while MANAGE 2.4 covers assigned responsibility for superseding, disengaging, or deactivating systems. A treatment plan turns these activities into a reviewable operating decision.

How it works

Assign ownership of the risk and its controls

Give the risk one accountable owner with authority over the business exposure. Name separate implementers for controls when several systems are involved. A platform engineer can implement cancellation, but may lack authority to accept erroneous customer decisions. A sponsor may accept an operational delay, but cannot assume every compliance decision belongs to the sponsor.

Your plan should record the cause and consequence, present assessment, chosen response, implementation owner, completion criterion, monitoring and response owner, and residual assessment. These are example register fields, not a prescribed Anthropic schema. Name the person or role authorized to approve deployment within the organization’s risk tolerance.

Avoidance removes the risky use or capability; mitigation reduces its likelihood or impact. Transfer allocates specified consequences to another party through a defined arrangement, but the architecture review must still identify the operating failure that can occur. Acceptance deliberately retains a risk within authorized tolerance. A vendor contract alone is not evidence that an unsafe workflow has become safe.

Choose a fallback that preserves the requirement

A fallback is a preselected alternative when the primary path cannot satisfy its acceptance conditions. It might be an approved model, a deterministic lookup, a deferred queue, or a human-operated process. Name its activation condition, supported task scope, data access, expected capacity, and owner.

Use the dependency analysis from 5.2.2. A second model calling the same unavailable account service is not an independent availability fallback. An answer generated without the required source may look like recovery while changing the business promise. The plan must say whether the fallback returns a narrower result, defers the task, or requires review.

Distinguish this architectural fallback from the Messages API’s fallbacks: "default". Anthropic documents that facility as beta on the Claude API, using anthropic-beta: server-side-fallback-2026-07-01, for supported safety-classifier refusal paths. It is not a general dependency-outage switch. See 2.1.2 for the model-routing mechanism and its model-specific coverage. Here, the risk owner decides whether any alternative is approved for this use and whether a refusal should remain terminal under application policy.

Test the chosen fallback under the same business constraints as the primary. Preserve required authorization and result checks; making the fallback more permissive changes the risk rather than treating it. NIST MANAGE 2.1 explicitly includes viable non-AI alternatives when considering resources for risk management.

Budget the workflow, including interruption

Record limits for the work the organization is prepared to fund and operate. For an Agent SDK implementation, TypeScript maxTurns and maxBudgetUsd, or Python max_turns and max_budget_usd, provide turn and estimated-spend limits. They produce error_max_turns or error_max_budget_usd when reached. See 1.3.3 for the broader autonomy decision.

Assign an operational response to those outcomes: stop automatic scheduling, retain the partial outcome, and apply the named recovery policy. A retry that starts a fresh job with a fresh limit can defeat the treatment unless the application’s workflow ledger accounts for previous attempts. The ledger is your application artifact, distinct from an individual SDK query result. A retry with a fresh limit can defeat the treatment unless the workflow ledger accounts for previous attempts.

Leave spending headroom. The SDK checks spend after a model response arrives, and the response that reaches the cap completes. Running subagents can also spend before they stop; the documented subagent cap enforcement requires Claude Code v2.1.217 or later. Treat the remaining exposure as residual risk rather than promising that maxBudgetUsd is an exact invoice ceiling. Lower limits reduce financial exposure but can increase deferred or incomplete work; the business owner accepts that service trade-off explicitly.

Make the kill switch an operating capability

A kill switch needs a named operator, trigger, enforcement point, and recovery rule. NIST MANAGE 2.4 calls for the ability and responsibility to deactivate systems whose outcomes conflict with intended use. MANAGE 4.1 includes incident response, recovery, override, and decommissioning in post-deployment plans.

In an Agent SDK TypeScript host, Options.abortController supplies an AbortController for cancelling operations. In the Python Agent SDK, ClaudeSDKClient.interrupt() sends an interrupt signal and works only in streaming mode. These are runtime mechanisms, not the whole shutdown design. The host must also stop admitting affected jobs and prevent queued jobs from restarting the same activity. Those admission and queue controls belong to your application; name their actual deployment controls in the operating plan.

Cancellation cannot establish that an external write was undone. Identify which writes could already have committed, who reconciles their outcomes, and what remains safe to deliver. Test shutdown during execution, not only before the first call. Restoring service requires an authorized decision based on the incident and the verified treatment, rather than removing an alert because it is inconvenient.

Key distinctions and trade-offs

The following artifacts answer different approval questions:

A completed engineering ticket proves implementation work finished. Acceptance additionally needs the observed control behavior, remaining failure paths, authorized scope, and conditions for reconsideration. Record review dates and change triggers such as a model migration, tool-permission change, or incident. NIST MANAGE 3 and MANAGE 4 support ongoing monitoring; a one-time signature does not replace it.

Architecture / decision scenario

A healthcare operations service drafts appointment-rescheduling proposals for 2,000 requests each day. It has a 20-minute completion target and a staffed manual queue that can absorb 300 daily cases. The service does not make clinical decisions. During testing, a shared scheduling dependency fails and the proposed automatic retry policy repeatedly restarts agents. The sponsor suggests unlimited retries with a cheaper model as fallback.

The architect shows why this fails: the alternative shares the scheduling dependency, and fresh runs recreate the cost exposure. The platform lead implements bounded SDK execution and an application-level admission stop. The operations lead owns a deferred queue with explicit capacity; during a large outage it cannot promise the original completion target. The on-call operator can activate shutdown, cancel active queries through the SDK’s cancellation control (TypeScript abortController), and reconcile scheduling writes whose outcomes are uncertain.

The accountable service owner approves the residual delay only for this appointment workflow, with a daily queue-capacity review and a requirement to suspend automated writes when reconciliation fails. The plan records that spend may exceed the configured threshold and that cancellation cannot reverse committed writes. Release depends on the fallback-capacity and shutdown rehearsals passing, rather than the sponsor’s preference for uninterrupted automation.

Common exam traps

• Assigning a control implementer as risk acceptor without decision authority.
• Treating a fallback that shares the failed dependency as independent recovery.
• Using fallbacks as though it handled arbitrary tool outages.
• Calling an SDK spend threshold an exact financial ceiling.
• Providing cancellation without stopping admission or reconciling writes.
• Treating silence, a disclaimer, or a completed ticket as residual-risk acceptance.

What to remember

An owned treatment plan names what changes, how it is tested, who operates it, and who accepts the remaining risk. Fallbacks preserve the business requirement, budgets include interruption behavior, and shutdown includes admission control and reconciliation. Acceptance is explicit, scoped, and revisited when the operating assumptions change.

Knowledge check

References

• NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• Anthropic, Agent loop
• Anthropic, TypeScript SDK reference
• Anthropic, Refusals and fallback
• Anthropic, Python SDK reference