Merchant Whitelisting for AI Agents: Control Where Agents Spend

TL;DR

A merchant whitelist constrains an AI agent to spend at a specific list of approved merchants. Any charge to a merchant not on the list gets declined in the auth path. It's the strictest of the three main spending controls (whitelist, MCC, policy) and the right choice when the agent's job is well-defined.

What is a merchant whitelist?

A list of merchant identifiers — Merchant IDs (MIDs), domains, or specific named merchants — that an agent is allowed to transact with. Anything not on the list gets declined.

Concretely, in Shatale's policy:

``json

{

"merchant_whitelist": [

"MID_AIRLINE_123",

"MID_HOTEL_CHAIN_456",

"MID_CAR_RENTAL_789"

]

}

`

A travel agent under this policy can pay those three merchants. Any attempt to pay anyone else: declined with reason merchant_not_whitelisted.

When should you use whitelisting?

Three cases:

1. Narrow-purpose agents. An agent that only needs to interact with a small set of merchants. Travel agents booking through 3-5 partners. Procurement agents buying from 5-10 approved vendors. Subscription agents managing a fixed set of SaaS tools.

2. High-trust user delegation. When the user wants strict guardrails. "Spend on travel, but only at these airlines and these hotels." Whitelisting expresses that exactly.

3. Pilot launches. Early in production, before you trust the agent's behavior at scale, restrict to a known-good merchant set. Expand the whitelist as confidence grows.

When should you NOT use whitelisting?

Two cases:

Open-ended shopping agents. An agent that needs to comparison-shop across an unknown merchant set can't be whitelisted — the whole point is discovering merchants. Use MCC controls + policy thresholds instead.

Agents in fast-moving merchant ecosystems. If new merchants legitimately appear in the agent's flow weekly, maintaining the whitelist becomes operational toil. Use MCC + reputation-based controls instead.

How does whitelisting compare to MCC blocks?

| Dimension | Merchant whitelist | MCC block |

|-----------|---------------------|------------|

| Granularity | Specific merchant | Whole category |

| Predictability | Very high | Medium (depends on MCC accuracy) |

| Operational cost | Maintain the list | Set once |

| Best for | Known merchant set | Unknown set, known categories |

| False positives | Very rare | Possible (MCC mis-coded merchants) |

Use both together for layered control. Whitelist is the strict outer boundary; MCC blocks add categorical filters within the whitelisted merchants.

How does whitelisting integrate with delegation?

The whitelist is part of the policy attached to the delegation. When a user delegates spending to an agent, the delegation includes the whitelist. The agent inherits it.

Updating the whitelist mid-delegation: creates a new policy version. Existing delegations evaluate against the version they were issued under. New delegations use the new version. (Same rule as all policy updates — see [How We Built a 100ms Policy Engine](/blog/building-spending-controls-for-ai-agents).)

What about chargebacks and disputes?

Whitelisted merchants you've vetted are unlikely to be fraud sources. But they can still over-charge or charge for things the agent didn't authorize. Standard chargeback flow applies; the whitelist just narrows the merchant set, doesn't change dispute rights.

What does the whitelist look like in production?

Three patterns from publishers:

Pattern A: Static whitelist per agent type.

"All travel agents can spend at these 12 merchants." One whitelist for the whole agent class. Simple, easy to reason about, doesn't scale to per-user customization.

Pattern B: Dynamic whitelist per user.

"This user's travel agent can spend at these 5 merchants the user pre-approved." Per-user whitelist managed via the user-consent enrollment flow.

Pattern C: Tiered whitelist.

"Standard merchants always allowed; new merchants require user approval." The agent can request to add a merchant; the user gets a notification and can approve/deny. Best UX, most engineering investment.

How do you build the whitelist initially?

Three sources:

  • Use case research. What merchants does an agent of this type need to interact with? Survey 5-10 production users.
  • Existing partnerships. If your platform has merchant partnerships, those are the safe starting points.
  • Iteration in pilot. Launch with a tight whitelist, expand based on actual user-requested adds.

    • FAQ

    What's the difference between MID-based and domain-based whitelisting?

    MID-based works at network level — every Visa/Mastercard merchant has a unique MID. Domain-based is platform-level — applies to e-commerce checkouts where the merchant URL is detectable. MID-based is more reliable for in-store + online; domain-based is e-commerce-only.

    Can the whitelist include patterns or wildcards?

    Limited. MIDs are exact-match. Domain whitelists support subdomain wildcards (*.airline.com`). Country-based filters are separate (geo allow list). Most of the time, exact-match is what you want.

    What happens if a whitelisted merchant changes their MID?

    Network rules give merchants stable MIDs across most lifecycle changes. Genuine MID changes (e.g. acquisition + re-onboarding) require a whitelist update. Rare in practice.

    Can I have a whitelist AND a blocklist?

    Yes. Whitelist is "only these." Blocklist is "never these." Combined: the agent must be on the whitelist AND not on the blocklist. Rare to need both, but supported.

    What's the difference between this and a closed-loop card?

    Closed-loop is network-level (the card itself is restricted to a single merchant or merchant chain — gift cards, store cards). Whitelisting is platform-level (the card is open-loop but the agent's policy restricts it). Whitelisting is more flexible (one card, many merchants). Closed-loop is more secure (network rules enforce it).

    Related reading

    External references

    ---

    By Vlad K.. Last updated 2026-04-29.