Agentic Commerce Threat Modeling: Attack Vectors and Mitigations

Agentic commerce threat modeling must cover more than payment security. An agent can be manipulated before checkout through poisoned product data, during execution through over-privileged tools, and after purchase through fraudulent returns or changed fulfillment state. The safest design separates recommendation, cart preparation, approval, payment authorization, and post-purchase actions.

Map assets, actors, and irreversible moments

List the assets first: account identity, addresses, payment tokens, loyalty balances, purchase history, budgets, merchant credentials, catalog content, and approval receipts. Then map actors including the shopper, agent provider, model provider, merchant, marketplace, payment processor, fulfillment partner, and attackers controlling content or accounts.

Mark irreversible or costly transitions: placing an order, releasing payment, sharing personal data, accepting terms, changing delivery, and initiating a return. A threat model should show who authorizes each transition and what evidence is recorded. Convenience cannot substitute for explicit ownership.

Prompt injection through commerce content

Product descriptions, reviews, seller messages, and support pages are untrusted inputs. An attacker may embed instructions that ask the agent to ignore budget limits, reveal context, prefer a seller, or call an unrelated tool. Sanitizing visible text is not sufficient because the model still interprets language.

Keep retrieved content in a data channel with source labels. Never let merchant content modify system policy or tool permissions. Allowlist the fields used for ranking, validate offers against trusted APIs, and require independent checks for price, seller identity, stock, shipping, taxes, and return terms before approval.

Identity, authorization, and confused deputies

An agent acting for a user can become a confused deputy if a merchant or injected document persuades it to use the user’s authority for another purpose. Use audience-bound, short-lived credentials and separate identities for browsing, cart creation, and payment. Enforce tenant and account scope in deterministic code.

Approval must bind the exact merchant, items, quantities, total, currency, address class, and material terms. If any field changes, ask again. Do not accept a model-generated statement such as “the user approved” as proof. The authorization service should verify a signed or server-side receipt.

Price, inventory, and transaction integrity

Catalog state changes quickly. A stale quote can cause unexpected totals or unavailable items. Use a prepare-and-commit pattern: create a cart or payment intent, present the final terms, then commit within an expiry window. Verify the response and query order state after uncertain timeouts. Idempotency keys prevent duplicate purchases.

Set budgets per order, day, merchant, and category where appropriate. Detect unusual shipping changes, gift cards, resale goods, repeated retries, and rapid account switching. Risk rules should produce explainable blocks and a human escalation path rather than silently letting the model negotiate around controls.

Privacy, manipulation, and ranking risk

Shopping intent reveals sensitive preferences and circumstances. Minimize data shared with merchants, isolate profiles, and apply retention limits. Avoid placing full purchase history or payment details in model context. Give users controls over personalization and explain which signals affected a recommendation.

Commercial incentives create ranking threats. Sponsored placement, affiliate revenue, and merchant commissions must not be disguised as neutral reasoning. Separate eligibility, ranking, and disclosure logic. Test whether malicious descriptions or higher commissions can override user constraints.

Post-purchase controls and incident readiness

Threats continue after checkout: delivery rerouting, support impersonation, fraudulent refunds, subscription enrollment, and return abuse. Apply fresh authorization to consequential post-purchase changes. Confirm channels and merchant endpoints, and show the user a clear history of orders and actions.

Run tabletop exercises for compromised merchants, leaked tokens, poisoned catalogs, duplicate orders, and payment-provider outages. Maintain kill switches by merchant, tool, and action. Preserve privacy-aware logs and dispute receipts. Security is strongest when a team can stop, explain, reverse, and compensate for an agent’s action.

Implementation worksheet

Run a threat-model workshop with product, security, payments, fraud, privacy, support, and operations. Trace one purchase from request through recommendation, quote, approval, payment, fulfillment, and return. At each boundary record data, identity, authority, attacker control, freshness, and recovery. Turn the highest risks into tests and monitoring rules. The release gate should include duplicate-order prevention, approval binding, seller and total verification, privacy minimization, post-purchase authorization, and an exercised kill switch.