Use Cases/E-commerce Agents

Runtime authorization for e-commerce AI agents.

A merchandising agent with Shopify Admin API, ERP, and Stripe keys can mis-list a SKU at $1, refund the entire order book overnight, or push inventory out of sync between the storefront and warehouse before a human notices. OAuth scopes show the agent can call the API. Veto decides whether the specific price change, discount, refund, or inventory write is allowed under your merchandising and fraud policies.

PCI-DSS 4.0SOX (public retailers)FTC Section 5

What can go wrong

E-commerce automations operate at the intersection of price, inventory, and payment. A bug or hallucination in any one of those surfaces produces immediate, public, and refundable damage.

The $1 listing bug

A pricing agent normalizes "1899" (cents) as "1.899" (dollars) and writes a premium product below cost. Public pricing errors show why price floors belong in policy, not prompt instructions.

Inventory desync

A fulfillment agent reconciles Shopify to NetSuite and inverts the deltas, oversells by 12,000 units across two SKUs, and forces manual cancellation emails to customers, each one a chargeback risk.

Refund fraud before it spreads

A support agent is socially engineered into refunding the entire order plus shipping plus a "goodwill credit." Multiply by hundreds of conversations a day and a $50 average ticket becomes a six-figure month of leakage.

PCI-scope expansion

An LLM is given raw PAN data so it can "help with chargeback emails." The agent now sits inside cardholder data environment scope and every conversation log is suddenly PCI evidence.

What Veto enforces

Policies wrap your catalog, inventory, order, and refund tools. Argument-level rules block out-of-policy values before the API call leaves your application.

veto/policies/ecommerce-agents.yaml
policies:
  - name: "Price-floor protection"
    match:
      tool: ["shopify.product_update","bigcommerce.product_update","catalog.set_price"]
    rules:
      - condition: "args.price < sku.cost"
        action: deny
        reason: "Price below COGS"
      - condition: "args.price < sku.reference_price * 0.5"
        action: require_approval
        approvers: ["merch-lead@approved.example"]
        reason: "Steep discount on a single SKU update"
      - condition: "args.price < 1.00"
        action: deny
        reason: "Hard floor: no SKU is ever priced below $1.00"

  - name: "Inventory write maker-checker"
    match:
      tool: ["shopify.inventory_set","netsuite.adjust_stock"]
    rules:
      - condition: "abs(args.delta) > 500 && args.reason != 'cycle_count'"
        action: require_approval
        approvers: ["ops@approved.example"]
      - condition: "args.delta < 0 && sku.on_hand + args.delta < 0"
        action: deny
        reason: "Inventory would go negative"

  - name: "Refund and credit ceilings"
    match:
      tool: ["stripe.refund","shopify.refund_order"]
    rules:
      - condition: "args.amount > order.captured_total"
        action: deny
        reason: "Refund cannot exceed captured amount"
      - condition: "args.amount > 250 || args.includes_shipping == true"
        action: require_approval
        approvers: ["cs-lead@approved.example"]
      - condition: "customer.refund_velocity_30d > 5"
        action: require_approval
        reason: "Refund velocity threshold tripped"

  - name: "Coupon stack limits"
    match:
      tool: ["shopify.discount_apply","cart.add_discount"]
    rules:
      - condition: "cart.discounts.length >= 2 && args.discount.stackable == false"
        action: deny
      - condition: "(cart.total_discount + args.discount.amount) / cart.subtotal > 0.5"
        action: require_approval
        approvers: ["merch@approved.example"]

Evidence hooks

PCI-DSS 4.0

Requirement 7 (need-to-know access) and Requirement 10 (logging). Veto evaluates with tokenized PAN references only, keeping the agent out of cardholder-data scope.

SOX (for public retailers)

Inventory adjustments and revenue-affecting refunds need approval evidence. Veto's logs are the SOX 404 control evidence auditors ask for.

FTC Section 5 (deceptive pricing)

An agent that lists at an unintended price still represents a price the FTC may require you to honor. A deny rule is the durable prevention point on the governed path.

Visa & Mastercard chargeback rules

Card-network rules limit issuer chargebacks and require a documented refund decision record. Veto's per-transaction decision record is that trail.

Where policy pays

A dealership chatbot incident showed the failure mode: a model made a pricing promise it had no authority to make. A price-floor policy catches that before the message reaches a buyer.

Refund and policy abuse become margin leakage when agents can issue credits without maker-checker gates. Veto keeps refund authority explicit by amount, channel, account risk, and approval state.

Frequently asked questions

How does Veto stop the '$1 listing' bug?
Catalog and price-update tools are wrapped with a policy that compares the new price to the SKU's reference price, cost, and historical range. Any update that drops price below cost, below a fixed percentage of the reference, or below a hard-floor cents value is denied or routed to a merchant. Because the SDK runs in-process and the catalog API is reachable through the wrapped client, policy executes before the update dispatches.
Can the agent still issue legitimate refunds without a human in every loop?
Yes. Policies define amount tiers: refunds under the median order value auto-approve with a decision record, refunds within 1.5x the original transaction auto-approve, and anything above triggers approval. Refunds that exceed the original captured amount are denied unconditionally. The agent gets a fast yes or no path for routine cases.
How does this affect PCI-DSS scope?
Veto evaluates policies in-process and only receives sanitized tool arguments. Full PANs should stay out of Veto's evaluation context; pass tokenized references instead. The decision record can be kept out of cardholder-data scope when you pass tokenized references and redact sensitive fields. The decision records help with Requirement 10 (logging and monitoring) and Requirement 7 (need-to-know access).
What about coupon and discount abuse?
A common failure mode is an agent stacking discounts beyond their intended use (welcome + loyalty + holiday on one order). Veto policies enforce stack rules, per-customer redemption limits, and total discount as a percentage of order value. Any deviation routes to a merchant ops queue with decision context.

Related use cases

Stop one mis-listed SKU. Pay for years of Veto.

Pick one catalog, inventory, refund, or discount policy.