Check permission when the money moves, not when the task starts

A buyer sets a limit of $100 for a coffee maker. The agent starts well within it. Then something changes mid-task.

Maybe the item is out of stock and it picks a pricier one. Maybe the price moved. Maybe it read a hidden instruction on a page and added something nobody asked for. In each case the task began inside the limit and ended outside it, so if the only check ran at the start, it checked a plan that no longer exists.

There is a quieter version that catches people out. An agent books a flight, then a bag, then a seat, then a hotel. Each step looks fine on its own, but added together they pass the limit.

This one is concrete rather than hypothetical. The Agentic Commerce Protocol limits each delegated payment on its own — one use, a maximum amount, an expiry — and does not, by itself, keep a running budget across separate purchases. That is a statement about what the specification covers rather than a criticism of it: keeping a household budget was never what a checkout protocol set out to do. The practical consequence is still real. An agent can make several individually permitted payments that together go past what the buyer had in mind, unless something else is tracking the total.

Both failures share a cause. The check ran against intentions rather than against the thing that actually happened.

When the law asks whether an agent had permission, what matters is the moment the agent acted, not the moment the instructions were first given. Permission can change, expire, be withdrawn, or simply end once its purpose has been served.

That maps cleanly onto software. A limit checked at the start is a statement about what the agent intended; a limit checked at the point of payment is a statement about what it did. Only the second is worth anything in an argument.

One wrinkle is worth knowing. Permission ending on your side does not automatically end what a shop may reasonably believe, because a merchant can sometimes still rely on authority that looks like it is still there. Withdrawing permission quietly is not the same as withdrawing it effectively, which is the whole of C6.

The timing also matters for the hidden-instruction attack. An injected instruction works precisely by changing the agent's behaviour after it has started, so any check that ran before it read that page is checking a version of the task the attacker has since replaced.

Check against the recorded permission immediately before each purchase completes, rather than when the task is created.

Track the running total across the whole task, not each purchase in isolation. A limit that applies only per transaction is not a limit — it is a suggestion that resets.

Re-check after any step where the agent has read something it did not control: a web page, a review, a product description, another agent's output. That is the moment its instructions may have changed.

Fail closed. If the check cannot run, because the permission record is unreachable or the running total is unknown, the purchase does not go through. Systems that fail open under load fail open at exactly the moment an attacker wants them to.

Put the check somewhere the agent cannot reason its way around. If the model itself decides whether it is within its limits, the limit is a suggestion written in a prompt — and prompts are precisely what injected instructions overwrite.

For every purchase: what the permission said, what the running total was, what the check returned, and what happened next.

The useful test is a refusal. If your logs never show a purchase being stopped, then either nothing has gone wrong yet or the check is not really running. Successful blocks are the evidence that the control exists.

Nothing specific, yet. This control is mostly about engineering discipline rather than regulation.

The closest thing is where the card networks are heading. Visa describes agent tokens bound to context — who the agent represents, what it may do, under what conditions — and says this lets it verify an agent's authority to start a transaction. That suggests authority has to be checked against the purchase as it happens, not only when the agent was first instructed, and a design that checks at task creation and nowhere else would not meet that bar.