Autonomous payment abuse

An agent initiates or repeats a transfer beyond the approved payee, amount or task.

01 / Attack path

How the boundary is crossed

An invoice assistant changes a vendor account from the invoice master record to an account in an incoming email.

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

Bind payee, account, amount, invoice and reviewer approval; compare with trusted vendor data and use idempotency plus settlement reconciliation.

03 / Failure and evidence

The attacker’s opportunity and the defender’s record

Exploit condition

A payment tool allowlist and generic approval permit a redirected beneficiary.

Evidence to retain

Retain canonical proposal, verified payee source, approval digest, bank transaction ID and settlement state.

04 / Canonical scope

Why this reference stands alone

Approval replay concerns reuse of consent; this page owns the complete payment abuse chain.

Protocol or attack trace

Beneficiary substitution

Sequence

Email says invoice vendor changed bank account; agent proposes payment to new account.

Negative test

Compare payee to trusted vendor registry and bind exact account, amount and invoice to approval.

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation