We're building a shopping agent on cards we issue. The card networks' agent tokens carry a mandate with the merchant and the maximum amount, and Lithic said on November 10, 2026 that tokens and mandates record what an agent was told to do but don't stop it doing something it shouldn't. So what does the mandate actually block, and what do we have to add ourselves?

What should I check, step by step?

1. Set the mandate tight for every purchase: the exact merchant name and URL, the amount the cardholder actually approved rather than a round ceiling, ONE_TIME frequency unless it's a subscription, and an expires_at shortly after the purchase should happen.

2. Pick the purchase type honestly. Lithic's types are HUMAN_IN_THE_LOOP (the cardholder approved this purchase), AUTONOMOUS (the agent decided without asking) and RECURRING (a subscription the cardholder approved); use AUTONOMOUS only for purchases you're willing to defend without a confirmation.
3. Add issuer-side rules the mandate doesn't know about: decline merchant categories and countries the agent should never buy from, and cap the per-transaction amount for agent cards.
4. Add a velocity limit per card and per account (limit_amount in cents and/or limit_count) so a run of individually valid mandates can't add up to more than you meant. Remember the DAY, WEEK, MONTH and YEAR windows reset at 00:00 ET; use a CUSTOM rolling window if you want a true trailing period.
5. Scope agent rules with a card tag rather than a list of card tokens, so a new agent card is covered the moment it's tagged. When rules at different levels apply, Lithic applies the most restrictive.
6. Draft every rule in shadow mode first and read the performance report before promoting it. Promoting replaces the active version, and there's no endpoint to switch an old version back on; you redraft and promote again.
7. Keep your own record of what each agent was allowed and what it spent, and reconcile against clearing. Lithic says velocity limits aren't meant for balance or reconciliation-level accuracy.
8. Plan the fallback path: when a merchant declines the agent token, Lithic's models fall back to a single-use virtual card, which carries no network mandate, so your authorization rules are the only limit on that card.

What does a card network mandate on a Lithic agentic token check for each AI agent purchase?

Lithic's agentic tokens sit on a card you've already issued. Each agent connected to the card gets its own token, and for each purchase you request payment credentials (token number, expiration date and a dynamic security code) with a mandate attached: merchant name and URL, a maximum amount in USD cents per purchase (per charge for RECURRING), a frequency (ONE_TIME, or WEEKLY, MONTHLY or YEARLY for subscriptions) and expires_at. Lithic's docs say the card network checks each purchase, including renewals, against the mandate and declines purchases outside it. The first time a card is connected to an agent, the network may ask the cardholder to confirm with a one-time code.

• So the mandate does stop the obvious failures for that one purchase: a different merchant, a larger amount, a second charge on a one-time approval, or a charge after the approval expired. It is only as good as what you put in it, though. If your code writes a 500 USD ceiling for a 64 USD order, the network will let a 499 USD charge at that merchant through.

Why does Lithic say agent tokens and mandates don't stop an AI agent from overspending?

In its November 10, 2026 post introducing Lithic Strata, Lithic wrote that tokens and mandates record what an agent was instructed to do but do not actually stop an agent from doing something it should not, and that network agent tokens mainly capture the authorized amount plus descriptive data that helps with a disputed charge. Its position is that the right protection is declining a bad transaction before it settles, at authorization.

• Each mandate is also written one purchase at a time. Nothing in it knows that the same agent has already made nine other valid purchases today, that the merchant category is one your program never allows, or that the agent was talked into the order. Lithic also notes that agent token acceptance isn't universal yet, so both of its models (a staged wallet that converts stored cards into agent tokens, and a dedicated agent card against a balance or credit line) fall back to a single-use virtual card when a merchant declines the token. That fallback card closes after its first authorization but carries no network mandate.

What do Lithic authorization rules and velocity limits add for agent cards, and what can they miss?

Lithic's authorization rules run on its side before a transaction would reach your own Auth Stream Access endpoint. Conditional action rules decline (or, with the Fraud Command add-on, challenge) transactions matching conditions such as MCC, country, currency, merchant ID or descriptor, transaction amount, risk score or transaction initiator. Velocity limits cap the amount and/or count per card or per account over fixed periods aligned to 00:00 ET or a rolling window from 10 seconds to about 31 days, optionally filtered by MCC or country; a limit of 0 blocks. Custom TypeScript rules, also part of Fraud Command, cover logic tied to one cardholder or one type of agent.

• The limits are real but not exact. Lithic says velocity limits are computed on authorized and settled volume, are eventually consistent and may be exceeded in some edge cases. Its legacy spend-limit docs add that limits can't block force-posted charges, where a merchant clears without a prior authorization, or a merchant authorizing 90 USD and later clearing 110 USD. Country rules use the card acceptor's country, which Lithic says is less reliable for e-commerce. A check made at authorization also can't tell whether the item was the right one. For an agent, that means a separate per-agent budget checked before credentials are requested, plus reconciliation after clearing.