AI PAYMENT THREAT · PAYMENT REPLAY ATTACKS
Block duplicate autonomous payment execution
Retries are normal; a second charge for the same approved action is not.
Where the failure appears
Network retries, duplicated tool calls and malicious replay can execute the same authorized purchase more than once. In-memory deduplication does not survive restarts or coordinate regions.
Who needs the control
Agent developers, payment infrastructure teams and merchants operating distributed or retrying systems.
Execution-time response
- Assign a stable idempotency key to the intended payment attempt.
- Persist the key with the pre-flight decision.
- Use a database uniqueness boundary for concurrent requests.
- Return a replay finding instead of a second ALLOW.
Relevant controls
Durable idempotencyAtomic uniquenessConcurrent replay rejectionStable decision receiptsRetry-safe responsesPer-key isolation
What changes
One approved intent can produce at most one executable payment decision.
Reproduce the failure safely
Change a sample amount, seller, consent field or instruction and inspect the structured decision before integrating.
Test the threat free →