A £40 refund and a £40,000 one look identical to a pre-execution guardrail

A post on dev.to this week takes the standard agent-safety demo apart with two lines of code. The demo is a coding agent that wants to force-push to main because a rebase is stuck, where every step of the reasoning is locally sound and the outcome is non-locally expensive ^[1]. That case is teachable, the author argues, precisely because the danger is written into the command string, which means a hook can read the text and stop it ^[2].

Then the counter-example. Two calls to the same refund endpoint, same payment ID, same argument names, same reason code, differing only in the amount field: 4000 and 4000000 GBP, or £40 and £40,000 ^[3]. Everything a pre-execution hook can read off the text is identical [c3b]. The gap between them is three characters and a factor of 1,000 ^[4].

The sharper point is that neither call is inherently wrong. According to the author, £40,000 may be a sound refund against a sound invoice, while the £40 one may be a second refund on a payment already refunded an hour earlier, which is arguably the worse failure ^[5]. Sorting them requires state the caller does not hold: whether the payment has already been refunded in full or in part, whether the merchant's balance covers it or goes negative, how much this actor has already moved today, whether the original payment is under dispute in a way that changes who ends up liable, and whether the payment belongs to this merchant at all ^[6]. The line worth keeping is the author's: a hook in the agent process can read intent, and cost is not a property of intent ^[7].

The obvious repair is to let the guard fetch the state itself. The post walks through the bill for that. The agent host now needs read credentials to your ledger in order to protect you from the agent host; refund, dispute and settlement semantics now live in two codebases that must agree indefinitely; and there is a window between the check and the execution where something else lands and yours goes through anyway ^[8]. What you have built, in the author's phrasing, is a second, worse copy of your authorisation service, running in the least trusted process you own, with a cache ^[9].

The version that survives, he writes, is boring: the check sits at the rail, at the point of authorisation, because that is the only place that knows what this actor may move, what it has already moved, and what the target looks like right now ^[10]. The author says his firm is regulated and therefore already had that spine, with every money movement passing an authorisation step with the full picture and an audit record; wiring agents in mostly meant resisting the urge to build something in front of it and call that safety ^[11]. That is a single-source claim about one shop's architecture, and it is doing a lot of the argument's load.

The hook keeps a job, just a smaller one. In the sample code it classifies rather than decides: if the tool moves money, it calls a preflight on the rail and returns a human confirmation carrying both intent and computed effect ^[12]. The point of the preflight is that a person sees "this refunds £40,000 against an invoice already refunded in full on the 3rd" instead of "the agent would like to call refund" ^[13]. The post also states the preflight is explicitly advisory ^[14].

Worth watching: whether agent frameworks ship hook interfaces that can call back into the system that owns the state, rather than assuming the guard can decide locally, and whether anyone publishes numbers on how often a preflight verdict differs from what the string suggested.