AnthropicClaude Certified Architect – Foundations2026-101.4 Implement multi-step workflows with enforcement and handoff patterns

Check every condition before issuing refunds

Completed by the knowledge check

Learning objective

Gate sensitive operations on verified identity, authorization, and business-policy state.

Core idea

A successful customer lookup does not authorize a refund. For a support architect, the execution decision has three independent parts: who the requester is, what that requester may do, and whether this particular transaction satisfies business policy. A correctly ordered workflow can still fail any of those checks.

Treat the requested tool input as a proposal to evaluate. A customer_id, a numeric amount, or a model-generated authorized: true field does not establish permission. A sensitive operation runs only when trusted application evidence satisfies every condition for that target and amount. If a condition is unresolved, keep the operation blocked and make the missing evidence explicit.

See 1.4.1 for where to insert prerequisite enforcement. This Bite focuses on the content of the decision and on why Agent SDK auto-approval is different from your customer’s transaction authorization.

How it works

Separate the three questions

In an illustrative refund service, the gate consumes three kinds of application-owned state:

Check	Question	Evidence used by the example service
Verified identity	Has the requester completed the required verification?	Verification result associated with the active case and customer ID
Authorization	Can that requester act on this customer and order?	Trusted relationship or delegated-authority result for the target order
Business policy	Is this refund allowed for this amount and transaction state?	Eligibility result, refundable balance, and any required approval

These are design fields for the example service, not Anthropic API properties. Anthropic supplies tool execution and interception mechanisms; your service supplies the identity and policy evidence. The distinction matters because a tool schema cannot define whether a real customer owns a real order.

Read the proposed target and amount from tool_input in an SDK PreToolUse hook, or from the Messages API tool_use.input in your dispatcher. Resolve the evidence through trusted service state. Compare the proposed customer and order with that evidence instead of accepting a verification flag supplied by Claude.

A missing identity result, an authorization denial, and an ineligible refund are different outcomes. Return a reason that distinguishes them. The next valid action might be verification, correction of the target, or escalation for an exception. None of those outcomes permits the refund tool to run unchanged.

Put mandatory checks before auto-approval

Agent SDK permission evaluation runs hooks before deny rules, ask rules, permission mode, allow rules, and the canUseTool callback. A PreToolUse denial blocks the operation even in bypassPermissions mode. The denial uses hookSpecificOutput.permissionDecision: "deny" and permissionDecisionReason.

By contrast, canUseTool in TypeScript, or can_use_tool in Python, handles calls that have not already been resolved by earlier permission steps. Auto-approved tools can skip that callback. If you put a mandatory refund-policy check only there and then pre-approve the tool, you can bypass your own check.

Use PreToolUse for conditions that must be evaluated on every matching call. Let ordinary permission controls decide any additional execution approval after the business gate passes. Returning {} from a hook makes no modification; it should not be interpreted as granting business authorization to every future call.

The SDK’s allowedTools option in TypeScript, or allowed_tools in Python, adds allow rules. It does not restrict Claude to only those tools. disallowedTools or disallowed_tools can remove a tool by its bare name. These controls determine tool availability and execution approval; neither computes customer ownership or refund eligibility.

Validate meaning as well as shape

For user-defined tools on supported models, strict: true constrains the tool_use.input to the tool’s input_schema. This helps prevent missing fields or incompatible types. It does not compare the requested refund with an order’s remaining refundable balance, because that fact belongs to your service state.

Keep the sensitive handler responsible for its domain checks as well as the agent-facing gate. In this example, process_refund validates the target, authority, eligibility, and amount when applying the transaction. The hook gives Claude an early, useful rejection; the handler evaluates the business operation at the point where it is performed. This is a proposed service contract, not an additional Anthropic permission mode.

Key distinctions and trade-offs

Identity and authorization are related but not interchangeable. A verified requester can be looking at another customer’s order. An authorized requester can ask for an amount that business policy forbids. An eligible order can still be presented by an unverified requester. The gate combines the conditions rather than treating any one as a substitute for the others.

Tool permission is also separate from domain permission. An allow rule answers whether the agent can invoke a tool without another execution prompt. It does not answer whether the tool should refund this customer. For a policy that requires human approval, store and check the approval for the proposed transaction; do not treat a natural-language recommendation as the approval itself.

The cost of a deterministic gate is that ambiguous cases cannot flow directly to payment. The benefit is that the application can distinguish a completed action from a proposal awaiting evidence. Give the agent a precise denial reason so it can pursue an allowed next step. A vague failure such as “something went wrong” makes a correct gate harder to recover from.

Architecture / decision scenario

A customer has completed identity verification and requests a $120 refund. In this example service, the authorized order has only $80 remaining refundable, and policy requires a supervisor to approve exceptions. The agent proposes process_refund with the verified customer ID and the larger amount.

The PreToolUse gate checks all three conditions. Identity passes. Authorization passes because trusted order data associates the requester with the order. Business policy fails because the proposed amount exceeds the remaining balance and no exception approval exists. The hook returns permissionDecision: "deny" with a reason identifying the missing exception approval. The payment handler is not invoked.

Suppose an operator configures allowedTools: ["mcp__support__process_refund"] in TypeScript to reduce repeated execution prompts. The business gate still runs because it is a PreToolUse hook. A design that relied only on canUseTool would lose its mandatory check when the tool is auto-approved. The agent can prepare a structured supervisor handoff, as taught in 1.4.4, but must describe $120 as the requested amount, $80 as the policy-eligible amount, and the payment as unexecuted.

Common exam traps

Treating a verified identity as permission to modify any customer’s order.
Treating valid tool arguments as proof of business-policy compliance.
Trusting authorized: true because Claude supplied it in a structured input.
Placing mandatory policy checks only in canUseTool for an auto-approved tool.
Reading allowedTools as an exclusive tool allowlist.
Describing a requested refund or human recommendation as an executed payment.

What to remember

Evaluate verified identity, target-specific authorization, and transaction-specific policy together. Use a blocking PreToolUse hook or client-tool dispatcher for the agent-facing gate, and trusted domain checks for the operation itself. Schema validity and SDK execution approval solve different problems.