Summary

  • A 27 October revision of an individual IETF draft gives each intended agent operation a stable key, separating a genuine retry from a second instruction with identical content.
  • In the draft’s £500 example, a £120 permit is already held against £300 spent. Retrying that permit stays within the limit; a fresh £120 payment would exceed it.

Picture a finance manager giving an AI assistant £500 to buy a paid tool. It makes a £120 payment, but the confirmation disappears. The assistant tries again; the manager expects one purchase, with £120 held while its fate is settled. Later the manager orders a second, identical purchase. This time the very same instruction should claim another £120. The two messages match; the two promises do not. If the audit record identifies an operation by a hash of the message, the second purchase can slip into the ledger disguised as a retry.

The 27 October revision of an individual Internet-Draft gives the intended operation its own name: decision.operationKey. The agent assigns a key to one planned operation and carries it in its signed request. Retries keep that key. A separate purchase gets a different key even if the payment instruction’s bytes are identical. The new text ties the key to the digest of the delegated limit, so the audit can follow the right purse as well as the right payment.

The draft does the arithmetic in pence. The delegated ceiling is 50,000. Earlier settled calls have used 30,000; one permitted call for 12,000 is still held because its response was lost. A repeat with the same operation key is counted once, leaving 42,000 committed or reserved. A new call for 12,000, despite having the same request digest, would take the total to 54,000. The 4,000-pence overrun is real even if the software smiles politely and labels the second charge “already counted.”

In revision -01, the request digest identified a retry. The revision history now says that two identical intended payments could therefore be mistaken for one operation. The -02 format puts each unsettled permit in a held list with its operation key, request digest and amount. The list must add up to the reserved total; a verifier derives whether the proposed permit fits under the limit.

A lost reply stays a live question. The draft keeps a permit held until a record for that same operation says the effect occurred, moving its amount to consumed, or says none, releasing it. A retaining party can then compare successive state revisions to catch a later decision that omitted an unsettled permit. The record supplies an audit trail for a bad decision as readily as for a good one; a permit above the limit remains visible as a permit above the limit.

The document remains an individual proposal, currently listed as I-D Exists. For the manager, the test is less exotic than the syntax: can the assistant show whether a repeated instruction was one purchase asking twice, or two purchases that happened to look the same? The money leaves the same budget either way. The audit must remember which promise used it.