# 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?

**Short answer:** Both, and they do different jobs. On Lithic, each purchase with an agentic token gets fresh payment credentials and a mandate naming the merchant, the maximum amount per purchase, the frequency and when the cardholder's approval ends, and Lithic's docs say the card network checks each purchase against the mandate and declines anything outside it. What the mandate can't do is decide whether a purchase is one your program should allow at all: it was written for that one purchase, mainly records what was authorized for disputes, and says nothing about how much this agent or account has spent today, which merchant categories or countries you refuse, or whether the pattern looks wrong. Those are issuer-side authorization rules: Lithic's conditional rules decline on merchant category, country, currency, amount or risk score, and velocity limits cap spend or count per card or account over a day, week, month, year or rolling window. Even then, Lithic says velocity limits are eventually consistent and can be exceeded in edge cases, and a check at authorization can't stop a merchant clearing for more than it authorized, so keep a running total of your own as well.

## Checklist
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.

## Ask Rightshold (free, no key)
Add the MCP server https://www.rightshold.com/mcp to Claude, Cursor, ChatGPT, Grok or VS Code (one-click setup: https://www.rightshold.com/start?ref=seo), then ask: "Before my shopping agent requests Lithic agentic-token credentials to pay 64 USD at grocer.example, check it against this agent's own spending policy and give me a signed allow or deny with the order number as the reference."

```json
{
  "tool": "authorize_spend",
  "arguments": {
    "credential_id": "<this agent's credential id>",
    "amount_minor": 6400,
    "currency": "USD",
    "merchant_domain": "grocer.example",
    "category": "groceries",
    "reference": "<order number>"
  }
}
```
- Set the policy first with set_spend_policy (owner account key, toolset=trust): per_tx_max_minor, daily_max_minor, allowed_domains and allowed_categories per agent credential. The daily total resets at 00:00 UTC, which is a different boundary from Lithic's 00:00 ET velocity windows.
- authorize_spend returns a signed allow or deny receipt with reasons such as over_per_transaction_cap, over_daily_cap or merchant_not_allowed and records it on Rightshold's ledger; anyone can check it with verify_spend_authorization. Use the same amount in the mandate so the two agree.
- It doesn't create tokens, mandates or cards, read your Lithic authorization rules or see authorizations and clearing. It only sees purchases the agent checks with it first, so keep Lithic's rules on as the issuer-side control.

_Rightshold records spending decisions your agent asks it for. It never holds or moves money, isn't a card issuer, processor or wallet and isn't affiliated with Lithic, Visa or Mastercard. Lithic behavior is as described in its November 10, 2026 Lithic Strata post and its Agentic Commerce, Create Agentic Tokens, Authorization Rules, Conditional Action Rules, Velocity Limit Rules, Authorization Rule Lifecycle and Spend Limits documentation, all read on November 11, 2026; agentic tokens need Lithic to configure tokenization for your program, some rule features need the Fraud Command add-on, and details may change, so check the linked pages before relying on them. Not financial or legal advice._

## Sources
- [Lithic: Meet Lithic Strata: Layered Controls for Agent Payments (November 10, 2026)](https://www.lithic.com/blog/lithic-strata-layered-controls-for-agent-payments)
- [Lithic docs: Agentic Commerce](https://docs.lithic.com/docs/agentic-commerce)
- [Lithic docs: Create Agentic Tokens (purchase types and mandates)](https://docs.lithic.com/docs/create-agentic-tokens)
- [Lithic docs: Authorization Rules](https://docs.lithic.com/docs/authorization-rules-v2)
- [Lithic docs: Conditional Action Rules](https://docs.lithic.com/docs/conditional-action-rules)
- [Lithic docs: Velocity Limit Rules](https://docs.lithic.com/docs/velocity-limit-rules)
- [Lithic docs: Authorization Rule Lifecycle (shadow mode, promotion, scoping by card tag)](https://docs.lithic.com/docs/auth-rule-lifecycle)
- [Lithic docs: Spend Limits (legacy; force-posted charges and clearing above authorization)](https://docs.lithic.com/docs/spend-limits)

## Related
- [How do Visa Intelligent Commerce mandates cap what an AI agent can charge to your card?](https://www.rightshold.com/answers/how-do-visa-intelligent-commerce-mandates-cap-what-an-ai-agent-can-charge-to-your-card)
- [How do Mastercard token spend controls cap what an AI agent can charge on an Agent Pay token?](https://www.rightshold.com/answers/how-do-mastercard-token-spend-controls-cap-what-an-ai-agent-can-charge-on-an-agent-pay-token)
- [How to give an AI agent a virtual card with a spending limit](https://www.rightshold.com/answers/how-to-give-an-ai-agent-a-virtual-card-with-a-spending-limit)
- [How to enforce AI agent payment caps at the execution boundary, not in the prompt](https://www.rightshold.com/answers/how-to-enforce-ai-agent-payment-caps-at-the-execution-boundary-not-in-the-prompt)
- [How to reconcile an AI agent's spend against the bank feed at month-end](https://www.rightshold.com/answers/how-to-reconcile-an-ai-agents-spend-against-the-bank-feed-at-month-end)
- [Can you dispute a purchase your AI agent made with your card?](https://www.rightshold.com/answers/can-you-dispute-a-purchase-your-ai-agent-made-with-your-card)

_Not legal advice. Updated 2026-11-11. JSON: https://www.rightshold.com/answers/do-card-network-mandates-stop-an-ai-agent-from-overspending-or-do-you-need-issuer-authorization-rules.json_