Use Cases/Supply Chain Agents

Runtime authorization for supply chain AI agents.

A procurement or logistics agent with SAP, Coupa, Ariba, NetSuite, and freight-portal credentials can spin up a new vendor, issue an out-of-policy PO, redirect a shipment to an unscreened consignee, or commit a UFLPA or OFAC violation in a single tool loop. SSO confirms identity. Veto decides whether this specific PO, vendor write, address change, or customs filing is allowed under your trade-compliance and procurement policies.

OFAC sanctionsUFLPACTPATSOX (procurement)

What can go wrong

Procurement and logistics agents touch money, identity, and physical movement of goods. Failures land on the OFAC sanctions list, in a Customs and Border Protection detention notice, on the SOX deficiency log, or in the morning's BEC-fraud report.

Rogue vendor creation

An agent creates a vendor master record from an inbound "quote request" email, assigns the vendor's preferred bank, and pays an invoice within the same week. Internal audit finds the vendor never existed. This is AP fraud compressed into an automated workflow.

Unauthorized POs

A planning agent cuts a $1.4M PO to a non-approved supplier to fix a stockout, bypassing vendor qualification and the SOX three-bid rule. The payment leaves before qualification catches up.

Ship-to manipulation

A logistics agent reroutes a container to a different consignee port based on a forged "expedite" email. The shipment lands at an unscreened address. CBP holds the cargo and asks who authorized the change.

Sanctions and UFLPA bypass

A sourcing agent finds a "lower-cost supplier" whose owner is on the OFAC SDN list, or whose factory is on the UFLPA UYG List. The purchase order should stop until sanctions, forced-labor, and supplier-risk checks pass.

What Veto enforces

Wrap ERP, P2P, and freight tools. Policies check the approved-vendor list, the active sanctions feeds, and the segregation-of-duties matrix before each action.

veto/policies/supply-chain-agents.yaml
policies:
  - name: "Vendor master maker-checker"
    match:
      tool: ["sap.create_vendor","sap.update_vendor","coupa.vendor_upsert"]
    rules:
      - condition: "args.field in ['bank_account','iban','swift','tax_id','legal_name']"
        action: require_approval
        approvers: ["procurement-controls@approved.example"]
        cooloff_hours: 48
      - condition: "context.agent_role == 'requester' && tool == 'sap.create_vendor'"
        action: deny
        reason: "Requester cannot also create vendor"

  - name: "Sanctions and UFLPA screening"
    match:
      tool: ["sap.create_po","sap.update_po","sap.create_vendor","logistics.update_ship_to"]
    rules:
      - condition: "vendor.sdn_hit == true || consignee.sdn_hit == true"
        action: deny
        reason: "OFAC SDN hit"
      - condition: "vendor.entity_list_hit == true || vendor.uflpa_hit == true"
        action: deny
        reason: "BIS Entity List or UFLPA hit"
      - condition: "vendor.sanctions_screening.last_run > 7.days_ago"
        action: deny
        reason: "Sanctions screening stale"

  - name: "PO ceilings and three-bid"
    match:
      tool: ["sap.create_po","ariba.submit_po"]
    rules:
      - condition: "args.total > 250000 && args.bids_received < 3"
        action: deny
        reason: "SOX three-bid requirement"
      - condition: "args.total > 100000"
        action: require_approval
        approvers: ["procurement-director@approved.example"]
      - condition: "args.supplier.qualification != 'approved' && args.total > 25000"
        action: deny
        reason: "Non-approved supplier above auto-allow ceiling"

  - name: "Ship-to and customs guard"
    match:
      tool: ["logistics.update_ship_to","customs.file_entry"]
    rules:
      - condition: "args.country in restricted_country_list"
        action: deny
      - condition: "args.hts_code matches uflpa_high_risk_hts"
        action: require_approval
        approvers: ["trade-compliance@approved.example"]
      - condition: "tool == 'logistics.update_ship_to' && shipment.in_transit == true"
        action: require_approval
        approvers: ["logistics-manager@approved.example"]

Evidence hooks

OFAC (50 USC 1701)

Strict-liability sanctions enforcement. Veto's per-call screening is a practical defense for an agent operating at API speed.

UFLPA (22 USC 6901a)

Rebuttable presumption against goods from XUAR. Veto blocks POs and customs filings that hit the UYG List.

CTPAT & AEO

Trusted-trader programs require documented security and personnel controls. Veto's role-of-record enforcement is the artifact the CBP supply-chain security specialist asks for.

SOX Section 404 (procurement)

Segregation of duties for vendor master, PO, receipt, and payment. Veto's maker-checker rules are the SOX evidence for AI-driven procurement.

Where controls matter

Sanctions, vendor-master, and shipment-screening failures often turn on intermediate suppliers, shipping addresses, and bank details nobody rechecked at execution time.

Vendor impersonation works because bank-account changes and urgent invoices look ordinary inside AP systems. Veto makes vendor-master maker-checker, cool-off windows, and payment approval explicit at the tool boundary.

Frequently asked questions

How does Veto block sanctions or UFLPA bypass attempts?
Wrap PO, vendor-create, and ship-to update tool calls. The policy can resolve the vendor and consignee against the OFAC SDN list, BIS Entity List, UFLPA UYG List, and your internal denied-party list, then deny the action on configured hits. The check uses the operator's current data, not a list snapshot the agent might have cached. Decision records can show list version, hit reason, and approval history for directed review evidence.
Can an agent still cut routine purchase orders without a human in every loop?
Yes. POs to approved-vendor SKUs at standard prices and below per-PO and per-vendor monthly ceilings auto-approve. Increases beyond a configured percentage, vendor changes, payment-term changes, and ship-to overrides require approval. The policy makes the routine case fast and the unusual case auditable.
What about vendor-impersonation fraud (the 'I changed my bank account' email)?
Veto policies require that any vendor master data change (bank account, address, legal name, tax ID) be approved by a separate role from the one that initiated it, and never by the agent itself. The vendor-master change is also frozen for a configurable cool-off (commonly 24-72 hours) after which a verification call must be logged. This pattern aligns with the FBI's BEC fraud guidance.
Does this scale to global trade and multi-ERP environments?
Yes. Veto policies are tool-name based, so the same policy shape can cover SAP, Oracle, NetSuite, Coupa, Ariba, and HTS-classification tools your agent uses. For multi-region deployments the SDK can run in each region's process; records can aggregate centrally without sending PII or trade-secret payloads when configured that way.

Related use cases

One blocked OFAC hit is evidence the control exists before the PO leaves.

SAP, Coupa, Ariba, and freight policies in a single sprint.