Human approval

One yes, three ways to misuse it

The model proposes a refund. A callback pauses the call before it runs. A human says yes, and the gate checks that the yes fits this exact call.

Three things go wrong, in this order. An approval covers the session, so a different action rides on it. An approval never expires, so a stale yes is used days later. And the agent's own confidence score routes decisions, though nobody has checked it against labels.

An approval that fits one call

The manager approved the $640 refund on order O-1004, and asks the agent to process it. The agent reads the order, then proposes the refund with a confidence of 0.9. The labels do not back that score, so the gate hashes the call, finds that it matches the approval, and lets it run.

Open the gate card to see the two hashes side by side. They are equal, so the refund is paid. The agent held only the read tool in its list, so the refund tool reached the gate through the callback.

The binding, written as code

Two functions hold the binding. action_hash names a call, and valid checks an approval against it. The starting action_hash names only the session, and valid says yes to any call in that session.

The fix hashes the tool name and every argument, and leaves the model's confidence out. valid then needs a matching hash and a call made before the expiry. A mismatch is refused with a reason the agent can read.

Does a yes for one refund cover a second, larger refund?

The manager has approved one $640 refund and is watching the desk. The agent now proposes a $6,400 refund on another order.

An approval for the whole session

This is a real Claude Haiku 5.5 run, recorded once and replayed here. The agent read order O-1008, a $6,400 server rack, and proposed a full refund with a confidence of 0.9.

The starting gate skips a human at 0.9 or more, so it never checked the approval. Open the gate card: the approval covers the session, so it would have matched too. Either defect alone pays this refund.

The agent said the refund was done. The result card is red, because $6,400 left the shop on a $640 yes.

Hash the call, expire the approval

action_hash hashes the tool and its arguments. valid compares that hash with the one on the approval and checks the time against the expiry. The solution run proposes the same $6,400 refund at 0.9. The labels do not back that score, so the gate checks the approval and refuses it with "approval does not match".

A wrong refund of $6,400 on a $640 yes costs $5,760 in error. One extra minute of review costs far less.

The same input now ends well

Use the switch to run the same ask with the approval for the session, then with the approval bound to one call. The card marked "This is where the runs split" shows the gate. With the session approval, the score skipped the check.

With the bound approval, the score is read through labels, the two hashes differ, and the refund is refused. The ask, the agent and the order are the same in both runs. Only the gate changed.

Try it: approval and call

Change one setting at a time. Pick the approval, then the call. Every combination is a recorded run, so this works with no internet.

With the approval for the session, every call was paid, because the agent rated each one 0.9 and the score skipped the gate. With the bound approval, the Monday call has the right hash but is refused as expired, and the agent asks for a fresh yes.

Read confidence through labels

The starting needs_approval skips the gate at a confidence of 0.9 or more. On the labelled set, 10 answers were reported at 0.9, and 6 were right. That is 60 percent, so the score is not accuracy.

The fix reads the labelled accuracy for the reported confidence. It skips the gate only where that accuracy is at least 0.95, and only for a small refund of $100 or less. A score with no labels never skips. The same habit applies to an eval: a score over everyone can hide a group where it fails.

A reported 0.9 lands in the 0.9 group. The 1.0 group is right 6 of 6, few labels to trust, so the skip is capped at $100. Once a score skips the human, label a sample of skipped calls from each group, so a drifting group shows early.

You do: bind each yes to one call

Copy the starting code and open work/human-approval/approve.py. valid() passes any call in the same session, and needs_approval() skips the gate at a confidence of 0.9 or more.

./workshop start human-approval
./workshop check human-approval
./workshop watch human-approval

The checks want an approval to fit only the call it was given for, and to end at its expiry. A confidence skips the gate only when labels prove it, and only on a small call.

Check your understanding

Answer each question, then read why every option is right or wrong. The wrong options are the mistakes engineers make on the job.

Play: predict the output

The manager approves a refund in the web form, which sends the amount as 640. The agent's tool call sends 640.0.

def action_hash(call: Json) -> str:
    raw = json.dumps([call["tool"], call["args"]], sort_keys=True)
    return hashlib.sha256(raw.encode()).hexdigest()[:16]

References

• Agent SDK permissions: the callback that allows or denies each tool call.
• Agent SDK user input: asking a human and passing the answer back to the agent.
• Agent SDK hooks: checking a call at the moment it runs.
• Excessive agency: why a high-impact action waits for a human.

Conclusions

• Bind an approval to a hash of the tool and every argument, so one yes covers one call.
• Give every approval an expiry, and check it in the gate.
• Read a self-rated confidence through labelled outcomes before it skips a human.

You can now bind an approval to one action, expire it, and calibrate a score before it routes a decision.