Summary

  • Revision 05 of an individual Internet-Draft moves an agent capability’s budget from reserved to consumed in the same atomic transaction that records provider entry, before an external effect adapter is invoked.
  • A timeout after that boundary is an unknown outcome, not proof of non-entry; restoring the budget could authorize a duplicate purchase, transfer or other consequence.
  • Revocation and an emergency freeze can stop an operation only if they serialize before provider entry. Once entry wins, later control can prevent new actions but cannot erase possible past effect.

The dangerous kindness of an automatic refund

Consider an agent allowed to place up to $2,500 of approved supply orders. It reserves $800, submits an order and receives no reply. A conventional workflow may return the reservation after a network timeout so work can continue. That choice looks available because the local record says “failed”. The supplier’s record may say “accepted”. A second operation can then use the restored $800 while the first order still arrives.

This is the central problem addressed by revision 05 of Bounded Capability Receipts and Durable Spend Control for Agent Actions. The proposal is an active individual Internet-Draft. Anyone may submit one; it has no IETF endorsement or formal standards standing. Its draft text says Experimental, while the Datatracker summary currently lists no intended RFC status. The significance is therefore the proposed state machine and its newly explicit cutoff, not institutional adoption.

The draft separates a signed capability from the state that conserves it. The receipt binds an issuer, subject, authorization artifact, closed scope, integer budget with unit and scale, holder proof, validity interval and any parent capability. A signature makes those fields inspectable. It cannot, by itself, stop two replicas from spending the same remaining balance. The proposal requires one relying-party-pinned atomic store for every executor able to exercise the same capability.

Its arithmetic is deliberately plain: remaining authority equals total minus consumed minus reserved. The invariant is that reserved plus consumed never exceeds total. The hard question is when a reservation becomes consumption.

Revision 05 moves the debit to the effect boundary

Revision 04 used a reserve-execute-commit sequence. The store created a reservation, recorded that provider entry had begun immediately before invoking the external adapter, and later moved the amount from reserved to consumed when an outcome was committed. It already required uncertain operations to be charged. Yet the authority transition and the provider-entry record were described as separate moments.

Revision 05 renames the sequence reserve-admit-reconcile and couples those moments. Immediately before provider entry, one atomic transaction must authenticate the reservation owner, enforce its deadline, recheck the capability and current allowance, revisit applicable direct and inherited revocation, and—when enabled—confirm that the admission domain remains active at the captured epoch. The same transaction records provider_entered, reduces reserved and increases consumed. Only then may the adapter run.

The later outcome commit no longer spends anything. It verifies the operation in provider_entered and closes it as executed or indeterminate. This ordering matters because the budget record now agrees with the earliest instant at which the organisation can no longer prove that no external effect happened. There is no interval in which the provider may have been entered while the same amount still looks merely reserved and refundable.

The draft treats delegation differently. Transferring authority to a child capability has no external provider call; its cutoff is the atomic parent funding commitment bound to child registration. That distinction prevents “effect boundary” from becoming a vague label applied to every state change.

Unknown is not the same as not entered

The proposal’s most consequential vocabulary is the difference between indeterminate and not_entered.

An indeterminate operation may have crossed the effect boundary, but the executor can prove neither the expected result nor its absence. The amount remains consumed. A caller timeout does not permit a new operation ID. The caller must query or reconcile the original attempt.

Budget restoration requires stronger evidence. The authoritative store must show that the operation is still reserved and that provider entry did not occur. The authenticated reservation owner may then reduce reserved without increasing consumed and close the attempt as not_entered. Even then, the operation key and action binding survive as a replay tombstone. A refund restores unused capacity; it does not make the same request new again.

This is a deliberately asymmetric policy. False consumption reduces availability. False restoration can duplicate a real-world consequence. For consequential automation, the second error is often less reversible. A duplicate cloud deletion, securities instruction, shipment or credential rotation cannot be repaired merely by correcting a counter.

Freeze has a race, not magic

Revision 05 also adds an optional admission-control domain. A reservation captures a monotonically increasing epoch. Provider entry rechecks the current epoch and active status in the same atomic transaction as the debit. A freeze that commits first prevents entry and can support authenticated non-entry. Provider entry that commits first consumes the authority; a later freeze blocks new admissions but cannot reclassify what may already have happened.

Revocation follows the same ordering. A reservation is not immunity from later revocation. Direct revocation of the exercised capability and applicable cascade revocation of ancestors must be rechecked at entry. But revocation after entry does not refund the action or prove that the external system ignored it.

The scope of this claim is narrow. The draft does not stop computation, undo provider effects or establish instant control across disconnected state domains. It trusts the adapter to place the effect boundary honestly. It also says a capability receipt is machine authority evidence, not proof that a human reviewed each action, that the action was lawful or safe, or that it succeeded.

What the evidence can actually establish

Several standards support the receipt’s encoding mechanics. JSON Canonicalization supplies deterministic bytes; Ed25519 supplies a signature algorithm; Internet date-time syntax supplies canonical timestamps; BCP 14 defines how uppercase requirements language is read. These can make a proposed record reproducible. They do not prove that the chosen boundary corresponds to the provider’s actual irreversible step.

That last join belongs to operations. A payment gateway may have a durable idempotency key. A procurement portal may accept an order before returning its identifier. A cloud API may queue work before the response connection breaks. Each adapter needs a documented boundary and authenticated reconciliation evidence. One generic “request sent” log cannot settle all three.

Sources