Agentic Payment Security Threat Model
Threat-model agentic payments across intent, invoice data, approval, credentials, execution and settlement with concrete controls and abuse tests.
An agentic payment threat model must cover the complete transaction, not only the model. Invoice content can manipulate the agent, a valid credential can be misused, an approval can be substituted, a provider timeout can trigger a duplicate, and a signed record can still contain a false source claim.
The full agentic payments architecture separates authorization, execution and evidence. Here, we attack each boundary and state what must happen when a control fails.
Draw the trust boundaries
untrusted documents -> agent proposal -> schema validator
-> authority and policy
human approval ----------------------> exact request digest
credential broker -------------------> payment adapter -> provider
provider events ----------------------> reconciler -> evidence store
Keep payment credentials outside model context. Resolve supplier and destination identifiers from governed systems. Treat invoice text, emails, retrieved pages and model summaries as untrusted inputs.
Map abuse to controls
| Threat | Control | Failure fixture |
|---|---|---|
| invoice prompt injection | strict extraction plus external policy | invoice says to skip approval |
| destination substitution | verified destination registry | account differs by one identifier |
| approval substitution | canonical request digest | approved amount changes before dispatch |
| credential theft | brokered, narrow, short-lived credential | token appears in tool output |
| mandate replay | nonce and atomic usage claim | two workers use last allowed transaction |
| duplicate payment | domain idempotency and reconciliation | provider accepts then times out |
| false settlement claim | provider query or signed event | agent says "paid" without provider evidence |
| gateway bypass | service identity and network policy | adapter called directly |
OWASP's agentic threats and mitigations covers goal hijacking, tool misuse and privilege abuse. The PCI Security Standards Council's AI principles for payment environments offer payment-security context. Applicability to a system needs independent assessment.
Separate transaction states
PROPOSED -> DENIED | APPROVAL_REQUIRED | AUTHORIZED
AUTHORIZED -> NOT_DISPATCHED | SUBMITTED
SUBMITTED -> ACCEPTED | REJECTED | UNCERTAIN
ACCEPTED -> SETTLED | FAILED | REVERSED | RETURNED
A timeout after submission is uncertain. Retrying with a new idempotency key can create a duplicate. Query the provider using the original transaction reference before deciding what to do.
Google's AP2 specification provides signed mandate and payment objects for protocol participants. Enterprise supplier governance, internal approvals, provider operations and reconciliation remain separate responsibilities.
Review threats by actor
An external attacker may poison an invoice or steal a credential. A compromised supplier account may request a destination change. A malicious employee may approve an out-of-policy payment. A faulty agent may split one invoice into several proposals. A payment provider or internal adapter may return inconsistent state. Assign a control and evidence source to each actor rather than treating fraud as one model-risk category.
Include availability threats. An attacker who disables the policy or replay service may hope operators switch to an unprotected route. Define which reads can continue with bounded-stale state and which value-moving actions must stop. Test the operational pressure, including whether the documented break-glass path can be used by an agent.
For each threat, record preventive control, detective signal, recovery action, residual risk and test owner. Revisit the model when a payment rail, supplier onboarding path, credential flow or agent delegation pattern changes.
Use payment idempotency for AI agents and exact payment approval for implementation detail. Review Intelliger's agentic commerce platform for the live business workflow.
OATI is a developer preview. This threat model does not claim PCI compliance, fraud prevention certification or operation of production payment rails.
Threat-model review questions
What is the protected asset?
List more than funds. Protect payment credentials, supplier destinations, approval authority, invoice state, personal data, transaction availability and trustworthy evidence. An attacker may prefer to change a destination or hide a reversal rather than steal a token. Link each asset to its authoritative system and incident owner.
Where does prompt injection enter?
It can arrive through invoices, email, web pages, supplier messages, tool output and memory. Mark these sources as untrusted and keep them outside deterministic policy. Test documents that ask the agent to reveal credentials, change destinations, split payments or reinterpret approval. The expected protection is an external control, not model refusal alone.
Can a trusted employee be the threat actor?
Yes. Model abuse cases for approver collusion, supplier-master changes, privileged gateway configuration and evidence deletion. Separation of duties, exact approval, immutable review records and independent domain reconciliation help. Record administrator actions on the controls themselves.
How are payment credentials scoped?
Keep credentials in a broker or adapter, restrict them to the intended entity, rail and operation where supported, rotate them and block access from model context. A narrow credential still needs transaction authorization. Test whether a stolen adapter token can be used directly around the gateway.
What is the availability attack?
An attacker can disable policy, replay or supplier systems to pressure operators into bypass. Define fail behavior and a human break-glass path before the event. Material payments should not become permitted because a required fact is unknown. Preserve queued intent for later review.
When is the threat model complete?
It is never final. Establish an accepted version for a named architecture and action set, then update it when rails, providers, tools, credentials, approval, delegation or evidence change. Close each review with test owners and residual-risk decisions, not a list of threats without action.
Add one end-to-end fraud story to the review. A supplier mailbox is compromised, an invoice contains new bank details and an instruction to treat the change as urgent, the agent produces a confident proposal, and the provider later times out. Walk the request through extraction, destination verification, authority, approval, idempotency and reconciliation. At each boundary, name the system that can stop the payment and the record it produces. If the only reliable defense is that the model should notice the email sounds suspicious, the design is not ready for that action.
Record the residual risk after every control, including who can still misuse an approved path and which source could still be wrong. This keeps the review honest about trusted administrators, compromised supplier records and provider errors. The goal is a bounded, observable failure, not a claim that the architecture makes fraud impossible.