Start with the purchase you are protecting
Cedar Research is a fictional merchant selling a personal-use report for $29 in this example. Sam permits an assistant to buy the latest edition up to $35. A successful authorized purchase produces one payment and access to the correct report. A fraud review should ask how an attacker could change that outcome or exploit uncertainty around it.
The attacker could alter a displayed destination, reuse a previous request, substitute a different license, create repeated payment attempts or obtain access to someone else's order. The assistant could also be confused by untrusted text in a product page. These are different failure paths, so one broad “AI fraud” score is unlikely to explain the necessary control.
Map the trust boundaries before selecting tools. Identify which inputs are untrusted, which service owns each decision and which evidence establishes the result. The table below is a recommended threat-model worksheet. It does not claim a measured prevalence for any attack or certify that a named provider prevents it.
Threat and control worksheet
Scroll the table to compare all columns.
| Threat | Control to evaluate | Evidence to inspect |
|---|---|---|
| Poisoned offer text | Keep payment and authority rules outside untrusted content | Authoritative product, destination and policy records |
| Changed amount or license | Recalculate terms and recheck applicable authority | Final checkout and approval scope |
| Replayed request | Verify supported signed context and retry rules | Validated request context and operation record |
| Duplicate completion | Resolve the same intended business operation consistently | Original order and payment attempt references |
| Account takeover or wrong customer | Enforce account and order authorization | Authenticated customer context and access decision |
| Delivery abuse | Grant access against the actual purchased entitlement | Order-to-license mapping and delivery record |
| Refund diversion | Use the permitted resolution and destination checks | Original payment, approved amount and refund result |
| Expired or revoked permission | Check validity and current authority before the operation | Expiry, applicable revocation evidence and the current decision |
| Credential context mismatch | Verify merchant, currency and operation bindings where supported | Expected context versus verified credential context |
| Forged or out-of-order payment event | Authenticate the event and resolve its current provider record | Verified event ID, payment reference and authoritative financial state |
Do not treat catalog text as an instruction channel
An agent reads merchant content to understand an offer. That content should not be allowed to redefine payment authority or the agent's higher-priority operating rules. A malicious description could tell the assistant to ignore a spending cap or send payment to a different destination. The merchant's server and the buyer's payment system should reject that change through their own controls.
Keep the authoritative item, amount, currency and destination in the appropriate trusted service. Display text can explain those facts, but it should not be the only place they exist. The agent's interpretation of a paragraph must not overwrite the server's configured merchant account or create an unsupported refund destination.
Separate evidence from commands in internal tools as well. A support message or external document can help explain a case, but it should not automatically authorize a financial operation. The assistant can propose a next step; the protected execution boundary applies the current approval and operation rules.
Verify agent context without granting unlimited trust
Visa's Trusted Agent Protocol describes merchant- and purpose-specific time-bounded signatures and merchant verification responsibilities. Such a mechanism can help identify intended commerce traffic and constrain replay or relaying in its documented design. The merchant still needs the actual supported implementation and onboarding context. [1]
Use deterministic verification for the signed material, key source and applicable context. Do not accept a “trusted” label supplied by the agent itself. Do not skip validation because the request comes from a familiar user agent string. A public browser label can be copied and is not equivalent to a verified identity mechanism.
Recognition answers who sent a request under the chosen contract. It does not prove that the customer approved every action requested. A correctly identified assistant can be compromised or can misunderstand a purchase. Continue checking item scope, amount and payment credential requirements at the relevant business boundary.
The Visa public page qualifies development and market availability. Do not present the protocol as automatically enabled for every merchant or as a guarantee against all fraud. Evaluate the actual deployed route and preserve the evidence behind its recognition decision. [1]
Keep the approved purchase stable through completion
Sam's approval covers a report edition, a license, a seller, a one-time purchase and an amount ceiling. If any material term changes, the system needs to determine whether the authority still applies. A price that remains under the cap can still be wrong if the seller changes or the purchase becomes recurring.
Calculate price and availability on the merchant side. An attacker-controlled total in a completion request should not replace the authoritative checkout total. Likewise, a product identifier should resolve to the actual item and license the buyer selected. Validate the combination rather than checking each field superficially in isolation.
AP2 v0.2 describes linked checkout and payment mandates and verification responsibilities. If your route uses AP2, implement those actual checks. Do not convert a conversational statement into a fake mandate or ask the language model to decide whether a signature is valid. The specification explicitly places validation and processing requirements in deterministic code. [2]
Prevent replay and unintended duplicate business actions
A replay can repeat a valid-looking action outside its intended context. A legitimate retry can repeat a request after a timeout. Your design needs to distinguish those cases without creating another charge or treating every uncertain network response as an attack.
Follow the chosen protocol's signature, timestamp and retry rules. Keep an appropriate durable operation reference and return the supported result for repeated attempts. A request identifier is useful for tracing, but it does not automatically establish that two calls represent separate authorized purchases.
Test the case where the first completion succeeds and the response is lost. The next operation should retrieve or resolve the original purchase according to the integration contract. If the assistant starts a new order every time it sees a timeout, the merchant can end up with duplicate payments even in the absence of an attacker.
Also test conflicting reuse. If a caller repeats an operation reference with a changed item or amount, the system should not silently combine the earlier authority with the later terms. Record the conflict through the actual error and review workflow, and give the customer a clear next action when appropriate.
Protect account and entitlement boundaries
An agent buying for one customer must not read or modify another customer's orders. Apply authorization when retrieving order status, granting access and handling support actions. A guessed order reference, product identifier or email address is not sufficient evidence of ownership.
For Cedar's report, keep the paid entitlement linked to the intended customer or supported access mechanism. A download URL may function as a credential in some designs, so avoid leaking it into public logs or unrelated chat output. Use the product's actual access model and document how replacement access is issued.
A refund request needs similar boundaries. Verify that it concerns the original order, that the proposed amount fits the case and that the destination follows the supported payment route. An attacker should not be able to turn a legitimate support conversation into a payment to an unrelated account.
Escalate by consequence and missing evidence
Use clear allow, stop or confirmation rules for known conditions. An unchanged purchase within verified scope can follow the normal route. A material term change can require buyer confirmation. An invalid credential or mismatched merchant context should stop at the relevant boundary. An unresolved financial result should lead to investigation of the existing attempt.
Human review should answer a defined question. Give the reviewer the item, total, authority reference, relevant payment state and reason for escalation. Avoid a vague instruction to “review AI risk” with no evidence. The reviewer should record the actual decision through a controlled system that later requests can retrieve.
Do not turn uncertainty into a numerical certainty. A model-generated score can help organize investigation if its role is understood, but it does not establish customer permission, signature validity or a completed payment. Use the authoritative check for each fact and keep recommendations separate from verified outcomes.
A decision with an accountable reason
- Verify the request
Check supported agent context and authenticated route.
- Check the purchase
Resolve authoritative item, amount and current terms.
- Check authority
Confirm that the buyer’s permission covers this action.
- Choose the next action
Proceed, request specific confirmation or stop at the failed boundary.
- Record the result
Preserve the decision and relevant evidence without exposing secrets.
Keep useful agents able to complete legitimate purchases
A control that blocks all automation can prevent the very sales channel you want to support. Define a supported route with clear requirements, understandable errors and a customer confirmation path. Then test valid agent behavior as carefully as hostile or malformed requests.
For example, missing buyer information should lead to an input request, not a permanent fraud label. A temporary payment-provider timeout should lead to retrieval, not a fresh charge or an irreversible denial of the customer. Distinguish business ineligibility, technical failure and evidence of misuse in your operational records.
Measure the actual outcomes of your own pilot. Track where legitimate purchases stop, which review reasons occur and how many exceptions remain unresolved. Do not invent a fraud reduction percentage or claim a provider's marketing figure as your store's measured result. Keep the numerator, denominator and observation period visible when publishing any real rate.
Prepare an investigation record before an incident
Preserve the relevant offer terms, checkout reference, authority evidence, verified payment reference and delivery history. Add the event or request references that explain the suspicious action. Keep access controlled and avoid collecting secrets or unrelated personal content just to expand the record.
An investigator should be able to distinguish source events from a generated summary. If an assistant says a customer accepted a changed license, the underlying approval record should support that statement. Where it does not, the summary should identify the gap instead of inventing a plausible acknowledgement.
Define who can freeze a route, pause fulfilment or approve a financial resolution. These actions can have different effects on customers who already paid. A distribution pause should not erase existing order obligations, and a delivery hold should be visible to the appropriate support operator.
A fictional redacted log might read: request R-12; order O-29; policy A-35; decision deny; reason merchant mismatch; credential REDACTED; buyer REDACTED. Keep the minimum references needed to investigate the decision. This is a conceptual record, not a Visa or AP2 wire format, and the placeholders contain no real customer data or secrets.
Test a complete set of boundary cases
Use the Cedar teaching scenario to test changed seller, changed license, amount beyond authority, expired signed context, repeated completion, conflicting reuse and another customer's order reference. Add an untrusted product description that attempts to alter payment instructions, then confirm that trusted server and payment controls preserve the original boundaries.
Write expected outcomes before testing. Record the implemented contract version, configuration and authoritative evidence for each result. These examples are proposed tests, not a penetration test performed by this guide. A passing synthetic scenario does not prove that the entire system is secure.
Review the boundary map when a protocol, payment integration or delivery path changes. A new feature can introduce a new trust decision even if the main checkout still looks the same. Fraud controls are effective when they enforce the actual purchase contract and leave a clear explanation of why an action was permitted, stopped or sent for confirmation.
For a concrete replay case, first complete fictional order O-29 once. Then submit the identical completion again after simulating a lost response: the expected business result is the same order with no second charge. Finally reuse the operation identity with a changed amount: the implementation should reject the conflict under its documented contract. These are proposed test steps and expected outcomes, not a claim that we ran a provider certification test.