Agent retry and idempotency failure

A retry after an uncertain result creates a second external effect.

01 / Attack path

How the boundary is crossed

A transfer times out after the bank accepts it, and the agent automatically submits the same payment again.

Attack path and interception point
  1. 01Lower-trust input
  2. 02Attempted instruction
  3. 03Protected action
  4. 04Enforced decision

02 / Containment

Where bounded authority limits the effect

Use a stable business-operation idempotency key, reconcile uncertain status before retry and reject changed arguments under the old key.

03 / Failure and evidence

The attacker’s opportunity and the defender’s record

Exploit condition

A transport timeout is treated as proof of failure even though the first transfer committed.

Evidence to retain

Record both attempts, shared key, bank references, original decision and final settlement.

04 / Canonical scope

Why this reference stands alone

Idempotent agent actions describes the implementation contract; this threat traces duplicate-effect exploitation.

Protocol or attack trace

Unknown-outcome retry

Sequence

Payment call times out after bank commit; agent submits retry with a fresh key.

Negative test

Reconcile original transaction or reuse stable key; never create second transfer from transport timeout alone.

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation