I would not use that token to execute a different economic effect. The human approved a particular preview under particular conditions. The agent needs to know what was approved, which source versions the preview used, what tolerance was disclosed, and whether the approver still has authority at use time. A token that merely says “subscription change approved” is too broad for this scenario.

Bind approval to a canonical action: customer and account IDs, plan, price or maximum charge, credit treatment, effective date, tool version, and relevant policy revision. Keep a fingerprint of that exact action and the source resource versions used to calculate the preview. Immediately before committing, reauthorize the principal and compare the current action and preconditions. If the price is now $120 or the credit changes the amount, the old approval does not cover the new effect unless the displayed approval explicitly allowed that range and treatment. Show a fresh preview and ask for a new decision.

There is a race even after re-reading. Another operator can modify the subscription between the final check and the write. If the provider supports conditional updates, send the observed version in the write itself, for example an If-Match validator or a provider-specific compare-and-set, and handle a failed precondition as a new preview. RFC 9110's conditional request rules describe If-Match as a way to prevent a method from applying when the selected representation has changed. This is only useful if the provider actually enforces the condition over the fields that matter. A price list version and a subscription version may both need binding.

What if the price changed but a published rule says the approved price is held for thirty minutes? Then the tool must express that price lock in a provider-enforced quote ID or transaction. A UI message promising a lock is not enough. If a human approved a maximum of $130 and the credit change cannot increase the actual charge, the product might allow execution within that explicit envelope, but only if the approval screen, policy, and canonical action all agree. That is a business rule to design deliberately, not an assumption made by the agent.

The hard follow-up removes conditional writes from the provider. A read just before a write narrows the race but does not close it. Ask the system owner for a reservation, transaction, or versioned commit API. Without one, I would not claim atomic enforcement of the preview. For a high-impact action, pause or use a human-operated process that acknowledges the residual race. An idempotency key stops some duplicate submissions, but it does not freeze the price or credit state.

Record the proposal, displayed preview, approver, decision time, resource versions, exact submitted command, and confirmed effect. If execution is rejected because a precondition changed, the agent should explain what changed and prepare a new preview. It should not keep retrying the old approval until something goes through. This is a time-of-check to time-of-use problem in the business state, separate from whether the workflow code or tool schema changed while the run was paused.