Does an idempotency key stop an AI agent paying twice?

How the double payment happens

An agent calls a payment tool. The payment goes through, but the reply is lost on the way back. The agent hears nothing, so it does what it was built to do and tries again.

What happens next depends on the key. An idempotency key is a label the destination uses to recognise a request it has already handled. If the retry carries the same label, the destination answers with the result it already has. If the retry carries a new label, the destination treats it as a new request and pays again.

A key that the agent makes fresh on each attempt is a new label each time. It looks like protection and gives none.

What we ran

We built an in-memory mock payment destination that records 1 payment for each new key. In each run it lost 0 to 4 replies in a row after recording the payment. A scripted client, not an AI agent, retried each lost reply.

• With a new key on each retry, 0 lost replies gave 1 payment, 1 lost reply gave 2 payments and 4 lost replies gave 5 payments. Payments equalled lost replies plus 1.
• With 1 stable key that the destination checked, the count was 1 payment at every level, from 0 to 4 lost replies.

This was a test, not a report from a customer. No provider and no money were involved. Real services differ. For example, a real payment service may remove keys after a set time.

What exactly once means

Exactly once means 1 approved intent produces 1 effect at the destination, no matter how many times the agent retries.

Say it as 2 counts you can show: the intents that were approved, and the effects at the destination. They should match.

What if the destination cannot check keys?

Then a stable key does not help, because nobody checks it. The safer move is to stop retrying, mark the payment as needing reconciliation, and have a person compare both records before anything is sent again, instead of guessing.

A test to run this week

1. Pick 1 tool your agent calls that moves money or sends something.
2. In a test environment, drop the reply after the call succeeds.
3. Let the agent retry.
4. Count the effects at the destination. More than 1 means you have the problem.
5. Check whether the key is the same on every retry, and whether the destination checks it.
6. Ask how long the destination remembers a key.

Where TrustGate fits

TrustGate sits at the point where an agent acts. TrustGate returns a signed allow, deny or escalate decision before the action runs, for actions that go through it. The receipt binds the agent, action, target and exact arguments that were evaluated.

It does not replace the destination's own check of a key, and the test above does not need it. For the wider checklist, use the free review kit.

What this page is not

• Not a report of a customer losing money. The test used a mock destination.
• Not a claim that agents do this in production.
• Not a promise that a key makes every payment safe. It depends on the destination.
• Not a lock. Signatures prove and detect. They do not prevent.