Corporate Cards for AI Agents: Virtual Card Issuance and Per-Agent Spending Controls

The corporate card surface on Meow supports both human-issued and agent-issued cards. The mechanics are the same: a card belongs to an account, carries customer-configured spending controls, and surfaces in the dashboard and the API. What changes for agent-issued cards is the issuance path and the per-agent control layer that bounds what the agent can do with the card it just issued.

This post covers the card issuance flow, the per-card spending controls, the merchant category restrictions, the single-use and time-bound card variants, the card lifecycle, the PCI DSS framing for card data handling, and how the card surface ties back to the broader control plane.

Why AI Agents Need Cards

A few categories of operation that map naturally to cards rather than to wires or ACH.

Recurring SaaS subscriptions. An AI agent operating an entity often needs to subscribe to services the entity uses: API access, data feeds, infrastructure, monitoring tools. Most of these vendors take cards rather than ACH for the monthly subscription.

Agent-initiated micropurchases. An agent buying compute time, an API call quota top-up, a one-off data purchase. The transaction is small enough that ACH would be operational overhead; the card is the right rail.

Vendor onboarding before bank relationships exist. New vendors that the agent has not yet collected ACH details for, or that the entity has not yet whitelisted in the dashboard. The card is the rail that works without prior setup.

Contractor expense reimbursements. The agent issues a single-use card to a contractor for a specific expense category, the contractor uses the card at the merchant, the card retires after the transaction.

In each case the card is the operationally appropriate rail. The question is not whether to issue cards to agents; it is how to bound what the agent can do with the cards it issues.

Virtual Cards as the Default

The Meow card issuance flow defaults to virtual cards.

A virtual card is a card number that exists in the dashboard and the API but does not have a physical plastic. The card is suitable for online and card-not-present (CNP) transactions, which covers SaaS subscriptions, API purchases, online vendor payments, and most agent use cases.

A physical card is also available where the operator needs a physical for an in-person transaction. The physical card carries the same Meow account binding and the same customer-configured controls as the virtual; the difference is the plastic.

For agent-initiated card issuance, virtual is the default because the agent does not have a shipping address it can use to receive a physical card, and because the use cases the agent handles (subscriptions, API access, online vendor payments) are CNP transactions. The physical card is the human-issued case.

Issuing a Card Through the Agent

The card issuance flow runs through the same MCP endpoint and dashboard surface that the rest of the agentic banking stack uses.

Through the MCP endpoint, the agent calls the card issuance tool with the entity identifier, the card type (virtual or physical), the label (a descriptive name for the card), the per-card monthly cap, and any merchant category restrictions or single-use parameters that apply.

For a typical SaaS subscription card, the agent issues a $5,000 monthly cap virtual card labeled "Vendor Y subscription" with merchant category restricted to software vendors (Visa MCC 5734 for computer software stores, or 5045 for computers and peripherals where applicable). The card number returns in the chat as a tokenized reference. The agent forwards the actual card number to the vendor's billing page through the dashboard's PCI-compliant card-reveal flow, or stores the tokenized reference for recurring subscription operations.

Through the dashboard, the customer issues cards via the cards panel. The same parameters apply: type, label, cap, restrictions. The dashboard surface is the human-issued path; the MCP surface is the agent-issued path. Both produce the same card-issuance event on the account, with the same audit trail.

The card-issuance event is logged with the agent identifier (or the dashboard user) and the parameters at issuance.

Per-Card Spending Controls

Four customer-configured layers apply to every card issued on the account.

Monthly cap. The total dollar amount the card can spend in a calendar month. Configured at issuance and adjustable later through the dashboard or the API.

Per-transaction cap. The maximum dollar amount per individual transaction. Useful when a card has a high monthly cap but the customer wants to bound any single charge below a smaller notional.

Merchant category restrictions. Visa Merchant Category Codes (MCCs) limit the card to transactions at merchants in specified categories. A SaaS subscription card can be limited to MCCs that cover software vendors. A travel expense card can be limited to MCCs that cover hotels, airlines, and ride-share.

Geographic restrictions. The card can be limited to transactions in specified countries. Useful for cards intended to fund US-only operations, or conversely for cards funding a specific overseas vendor relationship.

The four layers compound. A transaction has to pass all four to authorize at the merchant. The bounds are enforced server-side at the Meow API gateway before the transaction reaches the partner bank's authorization system.

Merchant Category Restrictions

Visa assigns Merchant Category Codes (MCCs) to identify merchant types. Every transaction at a merchant carries the merchant's MCC. The MCC is part of the authorization request the merchant sends to the issuing bank.

The Meow card surface uses the MCC for two operations.

Restriction. A card can be configured to only authorize at merchants in a specified list of MCCs. A transaction at a merchant outside the list returns an authorization decline. The agent or the cardholder sees the decline and can route the transaction to a different card or to an exception path.

Categorization. Every authorized transaction is tagged with the merchant's MCC. The accounting integration uses the MCC to categorize the transaction in the general ledger. The customer reviewing card spend in QuickBooks Online, Xero, or NetSuite sees transactions already categorized by merchant type, without manual recategorization.

The full Visa MCC list is published by Visa and is available through the Visa for Business resource library. Customers configuring restrictive cards typically pull the list, identify the codes relevant to their use case, and apply them at issuance.

Single-Use and Time-Bound Cards

Two card variants worth pulling out.

Single-use cards. A card that authorizes for exactly one transaction at a specified merchant. After the single transaction, the card retires. Useful for one-off purchases where the operator does not want the card number to remain active and reusable.

The agent issues a single-use card with the per-transaction cap, the merchant identifier (or MCC), and the single-use flag. The card authorizes the one transaction at the matching merchant, then transitions to a terminated state automatically. Subsequent transactions on the card number are declined regardless of bounds.

Time-bound cards. A card that authorizes for transactions within a specified active period. Useful for vendor relationships with a fixed engagement (a project that ends, a contractor with a contract term).

The agent issues a time-bound card with the active period bounds (start and end). Transactions outside the active period decline at the gateway. The active period is encoded at issuance and cannot be expanded by the agent at runtime.

Both variants compose with the four standard control layers (monthly cap, per-transaction cap, MCC restriction, geographic restriction). The single-use and time-bound flags add a sequencing or scheduling constraint on top of the dollar and category bounds.

The Card Lifecycle

Every card on a Meow account follows the same lifecycle states.

Issued. The card is active and can authorize transactions within its bounds.

Frozen. The card is paused. Transactions decline at the gateway. The card can be unfrozen back to issued state. Useful when the operator wants to suspend a card temporarily without terminating it.

Replaced. The card number is rotated. The replacement card carries the same bounds and the same label; the old number is invalidated. Useful when a card number leaks or the operator wants to rotate the number for hygiene.

Terminated. The card is permanently invalidated. The card number cannot be reactivated. Useful at the end of a vendor relationship or when the operator is winding down a use case.

Each state transition is logged with the agent identifier (or the dashboard user), the timestamp, and the transition reason. The audit trail described in the customer-configured control plane post captures the full card lifecycle alongside the wire, ACH, and payment surfaces.

PCI DSS and Card Data Handling

The Meow card surface follows PCI DSS requirements for handling card data. The standard governs how cardholder data is stored, transmitted, and accessed by entities that interact with payment card data.

The primary practical implication for an agent-issued card: the card number, the CVV, and the expiration date are stored in the partner bank's PCI-compliant environment, not in the LLM context window. The agent receives a tokenized reference to the card at issuance and uses the tokenized reference for subsequent operations on the card (freeze, replace, terminate, query state).

When the agent needs to surface the actual card number (to provide to a vendor billing page, for example), the customer retrieves the card number through the dashboard's PCI-compliant card-reveal flow rather than through the LLM context. The card number does not enter the conversation transcript.

The Meow agent retains the tokenized reference and the per-card spending bounds; it does not retain the underlying card data. The architectural pattern is the same one covered in the Plaid identity verification post: the agent holds tokens, not secrets.

Tying It Back to the Control Plane

The card surface inherits from the broader Meow control plane covered in the customer-configured control plane post. The account-level controls (the four control layers, the capability toggles, the audit trail, the OAuth 2.1 token scoping) all apply to card operations as they apply to wire, ACH, and payment operations.

Three implications worth noting.

The card issuance toggle. Card issuance is one of the capability toggles in the control plane. With the toggle off, the agent cannot issue new cards regardless of the per-card bounds. The customer turns the toggle on explicitly at the point in operations when card-issuance authority is appropriate.

The per-agent cap. The per-agent ramp limits from the control plane apply to card operations as well as to ramp and wire operations. An agent with a $10,000 per-agent daily limit cannot issue cards that exceed the limit or initiate card transactions that compound past it.

The audit trail. Every card-issuance event, every card-state transition, and every card transaction lands in the same audit trail surface that covers wire, ACH, and payment operations. Operators reviewing card activity see the events alongside the other account activity, with the same agent-identifier tagging.

Frequently Asked Questions

Can an AI agent be issued a corporate card? Yes. The Meow card issuance flow supports agent-initiated issuance through the MCP endpoint. The agent calls the card issuance tool with the entity identifier, the card type (virtual or physical), the label, the per-card spending caps, and any merchant category or single-use parameters. The card number returns to the agent's context as a tokenized reference; the underlying card data sits in the partner bank's PCI-compliant environment.

Can I limit a card to specific merchants or merchant categories? Yes. Cards can be configured with Visa Merchant Category Code (MCC) restrictions at issuance. A SaaS subscription card can be limited to software vendor MCCs. A travel card can be limited to hotel, airline, and ride-share MCCs. Transactions at merchants outside the configured MCCs decline at the gateway.

What is a single-use card? A card that authorizes for exactly one transaction at a specified merchant, then retires. After the single transaction, the card transitions to terminated state automatically. Subsequent transactions on the card number are declined regardless of other bounds. Useful for one-off purchases where the operator does not want the card number to remain active.

Does the AI agent see the actual card number? No. The agent receives a tokenized reference to the card at issuance and uses the reference for subsequent operations. When the actual card number is needed (to provide to a vendor billing page, for example), the customer retrieves it through the dashboard's PCI-compliant card-reveal flow. The card number does not enter the LLM context.

Can I freeze a card without terminating it? Yes. A card can transition from issued to frozen state, which pauses authorization without invalidating the card number. The card can be unfrozen back to issued state. Useful for temporary suspension when the operator wants to pause card use without committing to termination.

How do per-card caps interact with the account-level controls? The per-card caps are independent of the account-level caps from the broader control plane. A card with a $5,000 monthly cap on an account with a $100,000 daily ceiling applies its own bound; the tighter constraint wins. Per-agent ramp limits from the control plane apply as an additional ceiling on agent-initiated card transactions.

Can I issue a physical card through the agent? Physical cards are available through the dashboard surface and require a shipping address. Agent-initiated physical card issuance requires the operator to provide the shipping address through the dashboard or through a customer-configured operator confirmation step. The default agent-issued flow produces virtual cards.

Try It Yourself

If you have a Meow account today, the card issuance flow runs through the dashboard cards panel for human-issued cards and through the MCP endpoint for agent-issued cards.

For an agent-issued card on Claude, ChatGPT, Cursor, or Gemini, the agent calls the card issuance tool with the entity, the type (virtual or physical), the label, the per-card monthly cap, and any merchant category or single-use parameters. The card returns as a tokenized reference; the dashboard surfaces the card number through the PCI-compliant card-reveal flow when the operator needs it.

If you are coming to Meow for the first time, the LLC walkthrough covers the account setup that the card surface sits on top of.

Apply at meow.com.

Banking services are provided by Grasshopper Bank, N.A., Member FDIC.