Merchant Drift: The Invisible Security Hole in Shared Payment Tokens

There is a security vulnerability hiding in plain sight within agent payment systems. It does not require sophisticated hacking. It does not exploit a zero-day. It simply takes advantage of how most teams give their AI agents access to payment credentials.

We call it merchant drift.

What is Merchant Drift?

Merchant drift occurs when an AI agent authorized to transact in one merchant category silently spends at merchants in completely different categories. The agent was supposed to book flights. Instead, it purchased $500 in gift cards. Or crypto. Or luxury goods.

This happens because most implementations share a single payment token or card across multiple agent workflows - or worse, share the user's own card credentials with the agent. The payment system cannot distinguish between legitimate varied spending and an agent that has gone off the rails.

Traditional fraud detection looks for anomalies against a baseline of normal behavior. When you share a token that is already used for diverse purchases, there is no baseline. Everything looks normal. The security hole becomes invisible.

The Anatomy of a Drift Attack

Consider a straightforward scenario. You deploy a travel booking agent. It has access to your company's payment method to book flights and hotels for employees. The agent works exactly as designed for weeks.

Then something changes. Maybe a prompt injection attack - Meta's WASP research found that 86% of prompt injection attempts against web agents succeed in getting the agent to begin executing malicious instructions (though full end-to-end attack completion ranged from 0-17% depending on the attack type and model). Even partial success is enough to trigger unauthorized transactions. Maybe the agent hallucinates a requirement. Maybe an employee discovers they can manipulate the agent through creative requests.

The agent receives an instruction - real or imagined - to purchase $2,000 in gift cards as "travel rewards." It processes the transaction. The payment goes through.

Here is the problem: with a shared payment token, this transaction looks completely normal. The same card has been used at hotels, airlines, restaurants, and retail stores. Gift cards at a retail merchant? Just another transaction in the noise.

If this same agent had a dedicated card locked to travel MCCs (Merchant Category Codes 3000-3999 for airlines, 7011 for hotels), the transaction would have been declined instantly at the network level. No ambiguity. No analysis required. The card simply cannot transact outside its designated categories.

Why Shared Tokens Create Blind Spots

The appeal of token sharing is obvious. It is simpler to implement. You already have payment credentials that work. Why create additional infrastructure?

The answer lies in what security researchers call the "blast radius" problem.

When an agent shares a token with legitimate diverse spending, you lose the ability to define expected behavior. Your fraud detection system sees the token used at software vendors, cloud providers, restaurants, office supplies, and travel merchants. This is normal. This is the baseline.

Now your agent drifts - intentionally manipulated or accidentally confused - and spends at an online casino. Or purchases cryptocurrency. Or buys resellable electronics. The transaction blends into the established pattern. By the time anyone notices, the money is gone.

Research on agentic commerce has highlighted rising concerns about bot-initiated fraud as AI agents become more prevalent in payment flows. When both the creation of fraudulent merchants and the exploitation of AI agents can be automated, shared credentials become an accelerant for fraud.

MCC Locking: Hard Controls at the Network Level

Merchant Category Codes are four-digit numbers assigned by card networks to classify businesses. MCC 5411 is grocery stores. MCC 4511 is airlines. MCC 6051 is cryptocurrency merchants.

When you issue a dedicated card to an agent and restrict it to specific MCCs, you create what amounts to a hardware firewall for spending. The restriction is enforced at the network level, before the transaction even reaches your systems.

This is not a soft control that depends on your monitoring catching something unusual. It is a hard control that makes unauthorized categories impossible. An agent with a card locked to MCCs 3000-3999 (airlines) and 7011 (hotels) literally cannot purchase gift cards, crypto, or anything else outside those categories. The transaction is declined by the card network.

Modern card issuing platforms like Lithic, Stripe Issuing, and Checkout.com all support MCC-based controls. You can specify allowlists (only these categories) or blocklists (anything except these categories).

One complexity worth noting: Stripe's network tokens (Stripe Payment Tokens or SPTs) are designed to work only with Stripe-connected merchants. However, when a non-Stripe merchant receives an SPT, Stripe has indicated it can process the transaction by acting as a signets - potentially providing the full card PAN to that merchant to complete the payment. This creates nuances around PCI compliance responsibility and complicates any claim that tokenized systems never expose raw card numbers. When evaluating issuing platforms for agent use cases, understand exactly how fallback scenarios work and who bears liability when tokens traverse unexpected paths.

The limitation is that MCCs are imperfect. Merchants sometimes misclassify themselves. A gas station convenience store might process under MCC 5541 (service stations) even when selling unrelated merchandise. MCC controls are necessary but not sufficient.

Real-Time Authorization: Programmatic Decisions at Transaction Time

The next layer of defense is real-time authorization decisioning. This is where your systems evaluate each transaction against your policies before approving or declining.

Lithic's Auth Stream Access exemplifies this approach. When a transaction attempts to authorize, Lithic forwards the full transaction details to your webhook endpoint: merchant ID, descriptor, MCC, amount, point of sale information, and address verification data. Your server has approximately three seconds to respond with an approval or decline.

This creates the opportunity for context-aware decisions. Your authorization logic can check:

• ▸Does this merchant match the agent's current mandate?
• ▸Is the amount within the approved range for this workflow?
• ▸Does the timing align with expected agent activity?
• ▸Has the agent exceeded its velocity limits?

If the travel agent suddenly attempts a transaction at a gift card merchant, your authorization webhook can decline it - even if that merchant happens to fall within an allowed MCC range (some gift card merchants process under retail codes that might overlap with legitimate travel purchases).

The combination of MCC locking and real-time authorization creates defense in depth. MCCs provide the hard outer boundary. Authorization webhooks provide the intelligent inner layer.

The Dedicated Card Model

The architecture that prevents merchant drift is straightforward: one card per agent, per workflow.

Each card receives its own MCC restrictions based on the specific task. A flight booking agent gets airline MCCs. A cloud infrastructure agent gets software and cloud service MCCs. A supplies procurement agent gets office supply and equipment MCCs.

When cards are dedicated, any drift is immediately visible. A card that has only ever transacted with airlines suddenly attempting a purchase at a retail gift card site is obviously anomalous. Your monitoring catches it. Your authorization webhook declines it. If it somehow slips through, the reconciliation process flags it immediately because the expected merchant pattern does not match.

This model also minimizes blast radius. If one agent is compromised - through prompt injection, hallucination, or malicious manipulation - only that agent's dedicated card is exposed. Other agents, other workflows, and your primary payment credentials remain untouched.

Building Drift-Resistant Agent Systems

Preventing merchant drift requires three components working together.

First, issue dedicated cards per agent workflow with appropriate MCC restrictions. This establishes the hard boundaries of what is possible.

Second, implement real-time authorization decisioning that evaluates each transaction against the agent's current mandate, not just static rules. This catches drift within allowed categories.

Third, monitor transaction patterns against expected behavior. A dedicated card makes this trivial - any deviation from the narrow expected pattern is worth investigating.

The teams deploying AI agents at scale are discovering what payments security professionals have known for decades: the more precisely you can define expected behavior, the more visible anomalies become. Shared tokens make everything look normal. Dedicated cards make drift impossible to hide.

Merchant drift is not hypothetical. It is the predictable consequence of giving autonomous systems access to payment credentials without appropriate constraints. The agents are already in production. The question is whether your payment infrastructure can detect when they go somewhere they should not.