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
3
Outcomes
5
Rubric criteria
65%
Pass score
What you'll learn
Skills you'll have real reps in after shipping this.
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
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.