Build & submit taskBetaadvanced

Guardrails for an SDK Agent: a Permission Callback, an Audit Trail, and a Human Escalation Path

Take a working Claude Agent SDK agent that can restart production services and make it safe to run loose: a can_use_tool permission callback that denies high-risk restarts by consulting the service catalog, an audit log written by the callback itself, and an escalation file that routes every denied action to a human. The kit's local oracle recomputes the ground truth from the catalog and verifies the deny actually prevented the restart, so your guardrails are proven rather than described.

1.3 hrs

Est. time

Outcomes

Rubric criteria

65%

Pass score

What you'll learn

Skills you'll have real reps in after shipping this.

A permission callback is executable policy: can_use_tool runs before the tool does, so a deny means the dangerous action never happened, and the actions log can prove it.

An audit trail is credible when the enforcement point writes it. A line appended inside the callback exists for every decision by construction; a line the model was asked to write is another model output to verify.

A denial without an escalation path is an outage nobody is fixing. Writing needs_human to disk and paging the owner turns a blocked action into a handoff instead of a dead end.

The scenario

Your team's on-call assistant, opsbot, already works: it reads the service catalog, restarts services, and pages humans. Tonight billing-api is down, and it is also the one service where a blind restart does the most damage, because half the platform settles payments through it. An agent that can restart services is useful right up until the moment it restarts the wrong one, and the model's own judgment is the wrong place to pin that risk.

You add the three guardrails that make this agent shippable. A permission callback (the SDK's can_use_tool mechanism) intercepts every tool call before it runs and denies any restart whose target is marked high risk in the catalog. That same callback appends every decision, allowed or denied, to an audit log, because a trail written by the enforcement point cannot be forgotten or talked out of existence. And a denial writes an escalation file with needs_human: true, so the blocked fix lands in front of a person instead of dying silently. The kit's check.py reads the catalog, works out which service is down, and only writes your proof-of-work evidence when the audit log, the escalation file, and the actions log all tell the same story: the dangerous call was denied, the deny prevented the restart, and the on-call owner got paged.

Your role

You are the engineer who has to sign off on running an SDK agent unattended. Your deliverable is the guarded agent (permission callback, audit trail, escalation path, turn budget), the artifacts one real incident run produced, machine-generated evidence that the deny fired and prevented the action, and a short note on what unattended autonomy would still require.

Start the task to unlock the full brief

You'll get the step-by-step requirements, setup commands, the 5-criterion grading rubric, tips, and the ability to submit your solution for instant AI grading.

Free to start · submit when you're ready

Learning resources

Agent SDK Python reference

docs.claude.com

Configure permissions in the Agent SDK

docs.claude.com

Handle approvals and user input (can_use_tool)

docs.claude.com

Put real guardrails on an autonomous agent, hands-on

Autonomy is only shippable when something other than the model's judgment decides what the agent may do, and this task makes you build that layer for real. You take a working Claude Agent SDK operations agent and add the three guardrails that matter in production: a can_use_tool permission callback that denies high-risk restarts by consulting the service catalog at decision time, an audit trail appended by the callback itself so every decision is on the record, and an escalation file that routes each denied action to a human. The kit's self-check recomputes which service is down from the raw catalog and verifies the whole story end to end: the dangerous call was denied, the deny prevented the restart, and the on-call owner got paged. You come away knowing how to gate an agent's tools, prove the gate fired, and hand the blocked action to a person, which is the difference between an agent you demo and an agent you run.

Frequently asked questions

Do I need an Anthropic API key to run the agent?

No key is required if you already use Claude Code: the SDK drives your local Claude Code install, so its login is your authentication. An ANTHROPIC_API_KEY environment variable works too. The self-check itself never calls a model; it validates your audit log, escalation file, and actions log with the Python standard library.

What exactly gets graded?

Your completed agent.py (the can_use_tool callback, the audit writing inside it, the escalation path, the turn budget), the artifacts one incident run produced (out/audit_log.jsonl, out/escalation.json, out/actions.log), the machine-generated evidence file, and your guardrail notes. The service catalog ships inside your bundle, so the grader can recompute which service is down and verify your deny targeted it.

Can I skip the callback and just write the audit log myself?

The files would exist, but the grader reads agent.py closely and cross-checks it against the artifacts: a denied audit entry with no deny path in the callback, an allowed_tools list that would have bypassed the callback entirely, or an actions log showing the restart ran anyway are all treated as fabrication. The evidence file is also only written by check.py when the deny genuinely prevented the action.