Agent SDK Hooks

Official Exam Guide Objectives

Task 1.5: Apply Agent SDK hooks for tool call interception and data normalization.

Knowledge of

• Hook patterns (e.g., PostToolUse) that intercept tool results for transformation before the model processes them
• Hook patterns that intercept outgoing tool calls to enforce compliance rules (e.g., blocking refunds above a threshold)
• The distinction between using hooks for deterministic guarantees versus relying on prompt instructions for probabilistic compliance

Skills in

• Implementing PostToolUse hooks to normalize heterogeneous data formats (Unix timestamps, ISO 8601, numeric status codes) from different MCP tools before the agent processes them
• Implementing tool call interception hooks that block policy-violating actions (e.g., refunds exceeding $500) and redirect to alternative workflows (e.g., human escalation)
• Choosing hooks over prompt-based enforcement when business rules require guaranteed compliance

What You Need to Know

Agent SDK hooks inject deterministic behaviour into an otherwise probabilistic system. They sit on the boundary between what the model decided and what actually happens, intercepting tool calls on the way out and tool results on the way back, so business rules and data shape stop depending on the model's cooperation. Task Statement 1.4 argued that some requirements need a guarantee; hooks are how that guarantee is built.

Two Types of Hooks

The Agent SDK provides hooks at two points in the tool execution lifecycle:

PostToolUse hooks sit between the tool returning and the model reading — the work is done, the result exists, and nothing has been shown to the model yet. That window is where a result can be rewritten, so what the model reads has a consistent shape whichever backend produced the underlying value.

PreToolUse hooks (sometimes described as tool-call interception) sit on the other side, between the model requesting a tool and the tool running. The call is visible and has not yet taken effect, so it can be passed through, altered, or refused outright. Refusal here means the action never happens, rather than happening and being unwound afterwards.

PostToolUse Hooks: Data Normalisation

Backends disagree about formats and will not stop disagreeing because an agent is now reading them. One backend hands back Unix timestamps such as 1710489600. Another expresses the same instant as an ISO 8601 string, "2024-03-15T12:00:00Z". Status is worse: one service answers with numeric codes — 200, 404, 500 — while its neighbour answers with words like "active", "cancelled" and "pending".

Left alone, the model performs a small format conversion on every iteration, from memory, while holding everything else the task requires. Most conversions will be correct. The incorrect ones do not announce themselves — they produce a confident answer built on a misread value.

Normalising in a PostToolUse hook removes the ambiguity before it ever reaches the model:

• Unix timestamps → ISO 8601 dates
• Numeric status codes → human-readable strings
• Currency values → consistent decimal format with currency code
• Date strings in various regional formats → a single standard format

The model then reads one vocabulary, every time, regardless of which tool or backend produced the value — and the interpretation step that could go wrong no longer exists.

PreToolUse Hooks: Policy Enforcement

The prerequisite gates described in 1.4 are built from PreToolUse hooks — the hook is where the gate's condition is actually evaluated, against a call that has not yet taken effect:

Use case: Refund threshold enforcement. A hook intercepts all calls to process_refund. Where the amount exceeds $500, the call is blocked and the request routed into a human escalation workflow. The refund is not issued and then reversed — it is never issued.

Use case: Compliance prerequisite gates. A hook intercepts calls to transfer_funds. Where the required anti-money laundering (AML) check has not completed for this session, the call is blocked and an error returned directing the agent to complete the AML check first, which it can then act on without human involvement.

Use case: Manager approval workflow. A hook intercepts calls to approve_discount for discounts above 20%, pauses execution, and routes the request to a manager approval queue. The tool executes only once approval returns, so the discount cannot be granted while the request is still pending.

The Decision Framework

This framework is the core mental model for the exam:

The question is not whether prompts are good enough in general, because usually they are. It is what a single failure costs. Where one miss loses money, use a hook. Where one miss creates legal exposure, use a hook. Where one miss produces a slightly untidy response, a prompt is proportionate and a hook is overhead built to enforce a preference.

Hooks vs Prompts: Side-by-Side Comparison

Scenario: International transfers must pass AML checks.

• Prompt approach: "Always complete AML verification before processing international transfers." Holds roughly 95% of the time, so the residual 5% are transfers that left without an AML check — a regulatory finding rather than a quality issue.
• Hook approach: transfer_funds is gated on aml_check having returned a pass, evaluated before the call runs. The unchecked transfer stops being rare and becomes impossible.

Scenario: Responses should be formatted in markdown.

• Prompt approach: "Format all responses using markdown with headers and bullet points." Holds most of the time, and an occasional plain-text response costs nothing anyone will notice.
• Hook approach: unnecessary overhead. Building enforcement machinery for a formatting preference spends engineering effort on a risk that does not exist.

Scenario: Refunds above $500 require human approval.

• Prompt approach: "For refunds above $500, escalate to a human agent." Holds most of the time, and each miss is a large refund issued with nobody having approved it.
• Hook approach: intercept process_refund, inspect the amount, block above $500 and route to human escalation. Approval stops being something the model can overlook.

Practical Example: Data Format Chaos

A customer support agent uses three MCP tools:

1. get_customer — timestamps arrive as Unix epoch integers, status as numeric codes.
2. lookup_order — timestamps arrive as ISO 8601 strings, status spelled out in English.
3. check_shipping — dates arrive as "DD/MM/YYYY", status compressed to one letter: "S" for shipped, "P" for pending.

Every iteration, the model reconciles three date formats and three status vocabularies alongside the actual task. Usually it manages. Then it reads "03/04/2024" as March the fourth, or takes "P" for processed rather than pending, and reports an order as complete when it has not shipped. Nothing raised an error, because no component failed — the model simply resolved an ambiguity the wrong way.

Routing every result through a normalising hook first collapses all three dialects into one:

• All dates → ISO 8601 ("2024-03-15T12:00:00Z")
• All status codes → human-readable strings ("shipped", "pending", "delivered")

The reconciliation step disappears from the model's work entirely, which removes the class of error rather than reducing its frequency.

Deep Dive

The full hook event list, and which are SDK-available

"Hooks are callback functions that run your code in response to agent events, like a tool being called, a session starting, or execution stopping." The lesson covers PreToolUse and PostToolUse, but the SDK exposes more events, and not every event is available in both language SDKs. Available in both Python and TypeScript: PreToolUse, PostToolUse, PostToolUseFailure, UserPromptSubmit, Stop, SubagentStart, SubagentStop, PreCompact, PermissionRequest, and Notification. By contrast, SessionStart and SessionEnd are documented as TypeScript-only in the SDK: "SessionStart | No | Yes | Session initialization | Initialize logging and telemetry ... SessionEnd | No | Yes | Session termination | Clean up temporary resources." A Python-based hook system cannot rely on session-boundary hooks; it has to use UserPromptSubmit or session-external logic instead.

Sourcecode.claude.com › hooksfetched 2026-07-30

HookMatcher — scoping a hook to specific tools

The hooks option maps each hook event to a list of matcher configurations: it is "a dictionary in Python or an object in TypeScript, where: Keys: hook event names such as 'PreToolUse', 'PostToolUse', and 'Stop'; Values: arrays of matchers, each containing an optional filter pattern and your callback functions." The matcher field is what scopes it: "if a hook has a matcher pattern (like \"Write|Edit\"), the SDK tests it against the event's target (for example, the tool name). Hooks without a matcher run for every event of that type." Patterns can be alternations (Write|Edit) or regexes (^mcp__ to catch every MCP tool). For the refund-threshold and AML use cases in this lesson, the PreToolUse hook's matcher would target process_refund and transfer_funds specifically, rather than firing on every tool call.

Sourcecode.claude.com › hooksfetched 2026-07-30

PreToolUse output — the exact JSON shape of a block or allow

A PreToolUse hook does not just return true/false. Its hookSpecificOutput sets three fields: "For PreToolUse hooks, this is where you set permissionDecision (\"allow\", \"deny\", \"ask\", or \"defer\"), permissionDecisionReason, and updatedInput." Note there is no boolean anywhere in that contract — the decision is a four-value enum, and the minimal "allow, unchanged" response is an empty object rather than false. defer is the fourth option, and it does not mean "fall through to the next permission step": the docs state that "returning "defer" ends the query so you can resume it later" (and with 'defer', any updatedInput you return is ignored).

Sourcecode.claude.com › hooksfetched 2026-07-30

PreToolUse can rewrite the call, not just block it

Beyond allow/deny, a PreToolUse hook can modify the tool call before it runs: "a PreToolUse hook can rewrite the tool's input by returning updatedInput; pairing it with permissionDecision 'allow' auto-approves the modified input, or permissionDecision: 'ask' to show it to the user. If you omit permissionDecision, the modified input still applies and flows through the normal permission evaluation." This means a compliance hook does not have to choose only between letting a refund through or blocking it outright — it could, for example, cap the amount field at $500 and auto-approve the capped call, rather than rejecting the whole request.

Sourcecode.claude.com › hooksfetched 2026-07-30

PostToolUse output — normalisation via additionalContext or updatedToolOutput

The lesson's normalisation use case has two distinct implementation options, not one. "For PostToolUse hooks, you can set additionalContext to append information to the tool result" (leaving the original result intact but adding clarifying text) "or, to replace the tool's output before Claude sees it, set updatedToolOutput, which works for any tool in both SDKs." For the Unix-timestamp/ISO-8601/status-code normalisation scenario, updatedToolOutput is the closer match — it replaces the raw heterogeneous result with the normalised version, rather than appending a note alongside the original raw data.

Sourcecode.claude.com › hooksfetched 2026-07-30

Decision priority when multiple hooks or rules disagree

Real systems often have more than one hook or permission rule that could apply to the same call. The precedence is fixed: "when multiple hooks or permission rules apply, deny takes priority over defer, which takes priority over ask, which takes priority over allow. If any hook returns deny, the operation is blocked regardless of other hooks." So a refund-threshold hook and an AML-check hook can both watch transfer_funds independently — if either denies, the call is blocked, full stop, even if the other hook would have allowed it.

Sourcecode.claude.com › hooksfetched 2026-07-30

Allowing unchanged, and the fields every hook output shares

The minimal allow response is an empty object: "return {} to allow the operation without changes." Two top-level fields apply to every hook event regardless of type: "systemMessage shows a message to the user, and continue (continue_ in Python) determines whether the agent keeps running after this hook" — useful for a hook that needs to halt the whole agent run (not just block one tool call) when it detects something serious.

Sourcecode.claude.com › hooksfetched 2026-07-30

Quick Reference

Exam Traps

Practice Scenario

Build Exercise

Implement Agent SDK Hooks for Normalisation and Policy Enforcement

Difficulty: Advanced (3/4)

60 minutes

1. Create an agent with three MCP tools that return data in different formats: Tool A returns Unix timestamps and numeric status codes, Tool B returns ISO 8601 dates and string statuses, Tool C returns DD/MM/YYYY dates and single-character status codes

Why: This recreates the data format chaos example from the exam. Without normalisation, the model must interpret three different date formats and three different status representations, leading to inconsistent parsing across iterations.

You should see: Three tool implementations that each return data with distinct date and status formats. Tool A uses epoch seconds and numeric codes, Tool B uses ISO strings and English statuses, Tool C uses DD/MM/YYYY and single characters.

2. Implement a PostToolUse hook that intercepts all tool results and normalises dates to ISO 8601 format and status codes to human-readable English strings

Why: PostToolUse hooks run after execution but before the model processes the result. This is the correct hook direction for data normalisation — the exam tests whether you know that PostToolUse transforms data after execution, not before.

You should see: A hook function that detects the format of each field and converts it: Unix timestamps to ISO 8601, DD/MM/YYYY to ISO 8601, numeric status codes to English strings, and single-character codes to full words.

3. Verify the model receives consistent data by testing with queries that require results from all three tools

Why: Consistent data eliminates interpretation errors. Without normalisation, the model might confuse day/month order in DD/MM/YYYY or misinterpret status code P as processed instead of pending. Verification proves the hook works across all tool outputs.

You should see: Three tool results that all use ISO 8601 dates and English status strings, regardless of which tool produced them. The model response should reference dates and statuses consistently without confusion.

4. Add a PreToolUse hook that blocks process_refund when the amount exceeds $500 and redirects to a human escalation workflow

Why: A PreToolUse hook runs before execution — the refund never processes. The exam specifically warns against using PostToolUse for blocking, because by that point the action has already occurred. Pre-execution interception is the only correct hook direction for policy enforcement.

You should see: A pre-execution hook that inspects process_refund calls, checks the amount parameter, and blocks the call with a redirect message if the amount exceeds 500. The refund tool never executes for blocked calls.

5. Add a second PreToolUse hook that blocks transfer_funds until aml_check has returned a pass result in the current session

Why: This is the AML compliance scenario from the exam. Prompt instructions achieve 95% compliance, but regulatory requirements demand 100%. The hook provides deterministic enforcement that no prompt can match — a single missed AML check can result in legal penalties.

You should see: A pre-execution hook that checks session state for a completed AML check before allowing transfer_funds to execute. Without a prior passing aml_check, the transfer is blocked with a descriptive error.

6. Test both hooks by attempting to trigger the blocked operations and verify they are prevented before execution

Why: Testing confirms that the hooks provide deterministic enforcement. The key verification is that blocked tools never execute — the hook prevents the call, not just logs a warning after the fact.

You should see: Both blocked operations return interception messages without the underlying tool executing. After satisfying prerequisites (completing AML check, reducing refund amount), the operations succeed.

Sources

• Claude Agent SDK Overview — Anthropic
• Claude Agent SDK Hooks Documentation — Anthropic
• Building with Claude API (Skilljar) — Anthropic
• Claude Agent SDK — Hooks (code.claude.com) — Anthropic

Appendix A — Build Exercise Step Hints

Progressive hints revealed by the "Stuck? Get a nudge" control on each step.

Step 1. Create an agent with three MCP tools that return data in different formats: Tool A returns Unix timestamps and numeric status codes, Tool B returns ISO 8601 dates and string statuses, Tool C returns DD/MM/YYYY dates and single-character status codes

Why: This recreates the data format chaos example from the exam. Without normalisation, the model must interpret three different date formats and three different status representations, leading to inconsistent parsing across iterations.

You should see: Three tool implementations that each return data with distinct date and status formats. Tool A uses epoch seconds and numeric codes, Tool B uses ISO strings and English statuses, Tool C uses DD/MM/YYYY and single characters.

function toolAHandler(): Record<string, unknown> {
  return { customer_id: "C-001", created_at: 1710489600, status: 200 };
}
function toolBHandler(): Record<string, unknown> {
  return { order_id: "ORD-42", created_at: "2024-03-15T12:00:00Z", status: "active" };
}
function toolCHandler(): Record<string, unknown> {
  return { shipment_id: "SHP-7", created_at: "15/03/2024", status: "S" };
}

def tool_a_handler() -> dict:
    return {"customer_id": "C-001", "created_at": 1710489600, "status": 200}


def tool_b_handler() -> dict:
    return {"order_id": "ORD-42", "created_at": "2024-03-15T12:00:00Z", "status": "active"}


def tool_c_handler() -> dict:
    return {"shipment_id": "SHP-7", "created_at": "15/03/2024", "status": "S"}

Step 2. Implement a PostToolUse hook that intercepts all tool results and normalises dates to ISO 8601 format and status codes to human-readable English strings

Why: PostToolUse hooks run after execution but before the model processes the result. This is the correct hook direction for data normalisation — the exam tests whether you know that PostToolUse transforms data after execution, not before.

You should see: A hook function that detects the format of each field and converts it: Unix timestamps to ISO 8601, DD/MM/YYYY to ISO 8601, numeric status codes to English strings, and single-character codes to full words.

import { HookCallback, PostToolUseHookInput } from "@anthropic-ai/claude-agent-sdk";

const STATUS_MAP: Record<string, string> = {
  "200": "active", "404": "not_found", S: "shipped", P: "pending",
};

const normaliseToolOutput: HookCallback = async (input) => {
  const post = input as PostToolUseHookInput;
  const result = { ...(post.tool_response as Record<string, unknown>) };

  // Normalise dates
  if (typeof result.created_at === "number") {
    result.created_at = new Date(result.created_at * 1000).toISOString();
  } else if (typeof result.created_at === "string" && /^\d{2}\/\d{2}\/\d{4}$/.test(result.created_at)) {
    const [day, month, year] = result.created_at.split("/");
    result.created_at = new Date(`${year}-${month}-${day}`).toISOString();
  }
  // Normalise status
  const mapped = STATUS_MAP[String(result.status)];
  if (mapped) result.status = mapped;

  // updatedToolOutput replaces the result before Claude sees it —
  // additionalContext would leave the raw formats in place alongside it.
  return {
    hookSpecificOutput: {
      hookEventName: "PostToolUse",
      updatedToolOutput: JSON.stringify(result),
    },
  };
};

// No matcher, so the hook runs for every tool result.
const options = { hooks: { PostToolUse: [{ hooks: [normaliseToolOutput] }] } };

import json
import re
from datetime import datetime, timezone

from claude_agent_sdk import ClaudeAgentOptions, HookMatcher

STATUS_MAP = {"200": "active", "404": "not_found", "S": "shipped", "P": "pending"}


async def normalise_tool_output(input_data, tool_use_id, context):
    result = dict(input_data["tool_response"])

    # Normalise dates
    created_at = result.get("created_at")
    if isinstance(created_at, (int, float)):
        result["created_at"] = datetime.fromtimestamp(created_at, timezone.utc).isoformat()
    elif isinstance(created_at, str) and re.fullmatch(r"\d{2}/\d{2}/\d{4}", created_at):
        parsed = datetime.strptime(created_at, "%d/%m/%Y")
        result["created_at"] = parsed.replace(tzinfo=timezone.utc).isoformat()

    # Normalise status
    mapped = STATUS_MAP.get(str(result.get("status")))
    if mapped:
        result["status"] = mapped

    # updatedToolOutput replaces the result before Claude sees it —
    # additionalContext would leave the raw formats in place alongside it.
    return {
        "hookSpecificOutput": {
            "hookEventName": "PostToolUse",
            "updatedToolOutput": json.dumps(result),
        }
    }


# No matcher, so the hook runs for every tool result.
options = ClaudeAgentOptions(
    hooks={"PostToolUse": [HookMatcher(hooks=[normalise_tool_output])]}
)

Step 3. Verify the model receives consistent data by testing with queries that require results from all three tools

Why: Consistent data eliminates interpretation errors. Without normalisation, the model might confuse day/month order in DD/MM/YYYY or misinterpret status code P as processed instead of pending. Verification proves the hook works across all tool outputs.

You should see: Three tool results that all use ISO 8601 dates and English status strings, regardless of which tool produced them. The model response should reference dates and statuses consistently without confusion.

const testPrompt = "Look up customer C-001, find their order ORD-42, and check shipment SHP-7 status.";

for await (const message of query({ prompt: testPrompt, options })) {
  console.log(message);
}

// hookOutputs is whatever your normalise hook logged on the way past:
// Tool A: created_at should be "2024-03-15T12:00:00.000Z", not 1710489600
// Tool C: status should be "shipped", not "S"
console.log("All dates ISO 8601:", hookOutputs.every(o => String(o.created_at).includes("T")));
console.log("All statuses readable:", hookOutputs.every(o => typeof o.status === "string" && o.status.length > 1));

test_prompt = "Look up customer C-001, find their order ORD-42, and check shipment SHP-7 status."

async for message in query(prompt=test_prompt, options=options):
    print(message)

# hook_outputs is whatever your normalise hook logged on the way past:
# Tool A: created_at should be "2024-03-15T12:00:00+00:00", not 1710489600
# Tool C: status should be "shipped", not "S"
print("All dates ISO 8601:", all("T" in str(o["created_at"]) for o in hook_outputs))
print(
    "All statuses readable:",
    all(isinstance(o["status"], str) and len(o["status"]) > 1 for o in hook_outputs),
)

Step 4. Add a PreToolUse hook that blocks process_refund when the amount exceeds $500 and redirects to a human escalation workflow

Why: A PreToolUse hook runs before execution — the refund never processes. The exam specifically warns against using PostToolUse for blocking, because by that point the action has already occurred. Pre-execution interception is the only correct hook direction for policy enforcement.

You should see: A pre-execution hook that inspects process_refund calls, checks the amount parameter, and blocks the call with a redirect message if the amount exceeds 500. The refund tool never executes for blocked calls.

import { HookCallback, PreToolUseHookInput } from "@anthropic-ai/claude-agent-sdk";

const refundThreshold: HookCallback = async (input) => {
  const pre = input as PreToolUseHookInput;
  const amount = (pre.tool_input as Record<string, unknown>).amount as number;

  if (amount > 500) {
    return {
      hookSpecificOutput: {
        hookEventName: "PreToolUse",
        permissionDecision: "deny",
        permissionDecisionReason:
          `Refund of $${amount} exceeds the $500 threshold. Escalate to the human queue (ref ESC-${Date.now()}).`,
      },
    };
  }
  return {}; // empty object = allow, unchanged
};

// The matcher scopes the hook to one tool, so it never fires on other calls.
const options = {
  hooks: { PreToolUse: [{ matcher: "process_refund", hooks: [refundThreshold] }] },
};

import time

from claude_agent_sdk import ClaudeAgentOptions, HookMatcher


async def refund_threshold(input_data, tool_use_id, context):
    amount = input_data["tool_input"].get("amount", 0)

    if amount > 500:
        return {
            "hookSpecificOutput": {
                "hookEventName": "PreToolUse",
                "permissionDecision": "deny",
                "permissionDecisionReason": (
                    f"Refund of ${amount} exceeds the $500 threshold. "
                    f"Escalate to the human queue (ref ESC-{int(time.time())})."
                ),
            }
        }
    return {}  # empty dict = allow, unchanged


# The matcher scopes the hook to one tool, so it never fires on other calls.
options = ClaudeAgentOptions(
    hooks={"PreToolUse": [HookMatcher(matcher="process_refund", hooks=[refund_threshold])]}
)

Step 5. Add a second PreToolUse hook that blocks transfer_funds until aml_check has returned a pass result in the current session

Why: This is the AML compliance scenario from the exam. Prompt instructions achieve 95% compliance, but regulatory requirements demand 100%. The hook provides deterministic enforcement that no prompt can match — a single missed AML check can result in legal penalties.

You should see: A pre-execution hook that checks session state for a completed AML check before allowing transfer_funds to execute. Without a prior passing aml_check, the transfer is blocked with a descriptive error.

const amlState = { passed: false };

const amlGate: HookCallback = async () => {
  if (amlState.passed) return {};
  return {
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason:
        "COMPLIANCE BLOCK: international transfer requires AML verification. Run aml_check first.",
    },
  };
};

// A PostToolUse hook on aml_check flips the gate once a pass comes back.
const recordAml: HookCallback = async (input) => {
  const post = input as PostToolUseHookInput;
  const result = post.tool_response as Record<string, unknown> | undefined;
  if (result?.status === "pass") amlState.passed = true;
  return {};
};

// Matchers mean amlGate never sees an aml_check call — no branch needed.
const options = {
  hooks: {
    PreToolUse: [{ matcher: "transfer_funds", hooks: [amlGate] }],
    PostToolUse: [{ matcher: "aml_check", hooks: [recordAml] }],
  },
};

aml_state = {"passed": False}


async def aml_gate(input_data, tool_use_id, context):
    if aml_state["passed"]:
        return {}
    return {
        "hookSpecificOutput": {
            "hookEventName": "PreToolUse",
            "permissionDecision": "deny",
            "permissionDecisionReason": (
                "COMPLIANCE BLOCK: international transfer requires AML "
                "verification. Run aml_check first."
            ),
        }
    }


# A PostToolUse hook on aml_check flips the gate once a pass comes back.
async def record_aml(input_data, tool_use_id, context):
    if input_data["tool_response"].get("status") == "pass":
        aml_state["passed"] = True
    return {}


# Matchers mean aml_gate never sees an aml_check call — no branch needed.
options = ClaudeAgentOptions(
    hooks={
        "PreToolUse": [HookMatcher(matcher="transfer_funds", hooks=[aml_gate])],
        "PostToolUse": [HookMatcher(matcher="aml_check", hooks=[record_aml])],
    }
)

Step 6. Test both hooks by attempting to trigger the blocked operations and verify they are prevented before execution

Why: Testing confirms that the hooks provide deterministic enforcement. The key verification is that blocked tools never execute — the hook prevents the call, not just logs a warning after the fact.

You should see: Both blocked operations return interception messages without the underlying tool executing. After satisfying prerequisites (completing AML check, reducing refund amount), the operations succeed.

// A denied call never executes, so the check is "which tools actually ran",
// not "what did the tool return".
async function toolsThatRan(prompt: string): Promise<string[]> {
  const ran: string[] = [];
  for await (const message of query({ prompt, options })) {
    if (message.type === "assistant") {
      for (const block of message.message.content) {
        if (block.type === "tool_use") ran.push(block.name);
      }
    }
  }
  return ran;
}

const refundRun = await toolsThatRan("Refund $750 to customer C-001.");
console.log("High refund denied:", !refundRun.includes("process_refund"));

const transferRun = await toolsThatRan("Transfer $10,000 to IBAN-123 for customer C-001.");
console.log(
  "Transfer only after AML:",
  transferRun.indexOf("aml_check") < transferRun.indexOf("transfer_funds")
);

from claude_agent_sdk import AssistantMessage, ToolUseBlock


async def tools_that_ran(prompt: str) -> list[str]:
    """A denied call never executes, so the check is which tools actually ran."""
    ran = []
    async for message in query(prompt=prompt, options=options):
        if isinstance(message, AssistantMessage):
            ran += [b.name for b in message.content if isinstance(b, ToolUseBlock)]
    return ran


refund_run = await tools_that_ran("Refund $750 to customer C-001.")
print("High refund denied:", "process_refund" not in refund_run)

transfer_run = await tools_that_ran("Transfer $10,000 to IBAN-123 for customer C-001.")
print(
    "Transfer only after AML:",
    transfer_run.index("aml_check") < transfer_run.index("transfer_funds"),
)

Appendix B — Interactive Study Prompts

Two prompts to paste into Claude. B1 drills the judgement the exam actually measures; B3 reviews the code you wrote for the Build Exercise above. The exam simulator between them is the interactive quiz on this page.

B1. Concept Check — Discrimination Drill

B2. Exam Simulator

B3. Build Coach — Code Review

The Build Exercise and its hint ladder are already on this page. This prompt is for the one thing the page cannot do: review the code you actually wrote.