How to give an AI agent a credit card (without losing your job).

TL;DR

Per-agent virtual card, hard cap, MCC lock, signed mandate, kill switch.

• • Don't give the agent the company Amex. Issue one virtual card per agent, scoped to the merchants and dollars it actually needs.
• • Cap is enforced by the card network at authorization time, not by your application code. A prompt-injected agent cannot exceed the network-side cap.
• • Every charge is bound to a signed AP2 mandate; the audit trail proves which human principal authorized which agent for what.
• • Kill switch is one POST away; freeze takes effect within 1 second across all card-network paths.
• • Provisioning one agent + one card + one starter policy takes about 4 minutes end-to-end.

The real question isn't "can you."

You can give an AI agent a credit card today. You can do it the bad way — drop the company Amex into the agent's prompt context and pray — and you can do it the good way. Both are technically possible. Only one is defensible in front of a regulator, a board, or the legal team that finds out an LLM bought $40k of compute at 3 AM because someone successfully prompt-injected a hostile booking confirmation page.

The real question is which controls actually hold when the agent misbehaves — and the corollary, what your audit trail looks like when finance asks "who authorized this." This guide answers both, with the patterns we've seen work in production across coding agents, recruiting agents, concierge agents, and treasury agents over the last 18 months.

Three ways to give an agent a card.

Option 1: Share the company card. Drop the corporate Visa into a vault, expose it as a tool to the agent. Works on day one. Breaks on day two — when one platform double-bills, you can't tell which; when a recruiter leaves, rotating the PAN breaks every downstream integration; when the agent is prompt-injected, the entire credit line is exposed. Don't do this.

Option 2: Per-user / per-agent prepaid card. Issue a prepaid card per agent (Privacy.com, Ramp employee cards, Brex limit cards). Better. The blast radius is bounded by the card's balance. But: no MCC-level merchant locks on most prepaid issuers, no real-time kill switch with sub-second latency, no AP2 mandate trail, and the audit story is "this agent spent it" rather than "this principal authorized this agent for this purpose."

Option 3: Per-agent network-enforced virtual card with a mandate chain. What AgentWallet ships. One Visa per agent, MCC-locked, merchant-locked, network-enforced daily/monthly caps, sub-second kill switch, signed AP2 mandate per charge linking the agent's spend back to a verified human principal. Defensible to a regulator. Defensible in court. Cheap to provision (412ms per agent).

Why per-agent virtual cards win.

A per-agent virtual card has four properties no other approach matches:

• 1. Bounded blast radius. The card's cap is the worst case for any single incident. If your agents have $500/day caps and one gets compromised, the maximum loss is $500 (minus whatever's already in flight, typically $0–$50).
• 2. Network-level enforcement. Caps are enforced at Visa/Mastercard's authorization path. The agent literally cannot exceed them, regardless of what its prompt says or what application bug it triggers.
• 3. Merchant-locked scope. The card is MCC-locked (e.g. only MCC 7372 software charges) and merchant-locked (e.g. only the specific AWS billing entity). A compromised agent cannot redirect spend to an attacker-controlled merchant.
• 4. Mandate-bound audit. Every charge carries a signed AP2 mandate hash linking it to the human principal who authorized it. Regulator, auditor, and CFO all see the same truth: who, when, for what, up to what cap.

Controls that actually hold.

There's a lot of theater in this space. Here's what holds in production and what doesn't:

Holds: Network-enforced caps (Visa-side, not application-side). MCC merchant locks (network refuses out-of-scope merchants). Charge-rate caps (e.g. max 12 charges/hour catches runaway auto-renew loops). Real-time charge notifications under 2 seconds (lets human catch surprise spend before it compounds). Kill switch with sub-second propagation. Signed mandate trail (AP2) tying every charge to a human-attributable authorization.

Doesn't hold: "We tell the LLM not to spend over $X" (the LLM lies). Application-level caps not enforced at the network (race conditions and bugs). Approval workflows that depend on the LLM honestly requesting them (it won't, if injected). Daily emails with spend summaries (catches problems 24 hours after they matter). Behavioral anomaly detection without hard caps underneath (false positives flood the queue; real attacks slip through).

Incident response in 60 seconds.

Agent leak detected. Your runbook:

1. POST /api/agents/:id/freeze — agent's MCP endpoint refuses all new requests within 1 second.
2. POST /api/agents/:id/cards/:card/freeze — every card on the agent stops authorizing within 1 second.
3. Export the agent's ledger from the last 24 hours; review every charge with finance.
4. Rotate the agent's MCP token; rotate the principal's WebAuthn key if compromise extended to the human side.
5. Issue a new agent + fresh cards if the agent itself is to be retired.

Total time from detection to containment: under 60 seconds if you have the freeze endpoint wired to your monitoring. Total worst-case loss: whatever's in flight at freeze time, typically under $50.

The legal posture (and AP2).

The question regulators care about is not "did an AI spend money" — they don't care. The question is "did a human authorize this spend, and can you produce that authorization." AP2 (the Agent Payments Protocol from Google + Coinbase) is the cryptographic answer.

Every AgentWallet card charge is bound to an AP2 mandate chain: IntentMandate (signed by the human principal, says "agent X may spend up to $Y on category Z"), CartMandate (signed by the merchant), PaymentMandate (signed by the agent, refers to the cart). The chain is cryptographically verifiable; the signatures are bound to did:web identities resolvable independently. Any auditor, regulator, or counterparty can verify the chain without trusting AgentWallet's database.

The legal posture this produces: the human principal authorized the spend (with WebAuthn-bound signatures we can prove). The agent acted within scope (we have the mandate). The charge happened within cap (network-enforced). If the agent went out of scope, the network refused the charge before money moved. This is a stronger audit posture than what most humans-with-corporate-cards produce.

Step-by-step: provision one today.

1. Sign up at agentwallet.ai. Verify your business via Payouts.com's lightweight KYB (driver's license + EIN; 2–4 minutes).
2. Create a principal. Register a WebAuthn key (your laptop's Touch ID or a YubiKey). This is the human-side signing identity.
3. Provision an agent. One click in the dashboard or POST /api/agents. Takes 412ms; returns an agent_id and an MCP endpoint URL.
4. Attach a starter policy. Pick from the template library (Coding / Recruiting / Treasury / etc.) or define one — daily cap, allowed merchants, allowed rails.
5. Issue a card. POST /api/agents/:id/cards with a merchant + cap. PAN, CVV, exp returned via the VGS-protected reveal endpoint. Cleartext is never persisted.
6. Wire MCP to Claude / Cursor / GPT. Paste the agent's MCP URL into your LLM client's MCP config. The agent has full access to its tools: charge_card, refund, send_payout, send_email, send_sms, etc.
7. Test with a $5 charge. Ask the agent to buy something cheap. The charge fires, the receipt notification lands, the ledger row appears. Verify the audit trail end-to-end.

Total time from signup to first verified agent charge: about 4 minutes.

Five common failure modes.

1. Caps that aren't network-enforced. Application-level "spending limits" are advisory; an agent that bypasses your tool wrapper bypasses the cap. Demand network-side enforcement.

2. Shared cards across multiple agents. Loses attribution, multiplies blast radius. One agent's incident contaminates every other agent on the card.

3. No real-time notifications. Catching a runaway agent 24 hours later means watching $20k of compute burn overnight. Receipts under 2 seconds are not negotiable.

4. Kill switch with 30-second propagation. Anything slower than 5 seconds gives a determined attacker time to drain the card. Test your provider's freeze latency; if they won't tell you, assume it's bad.

5. No mandate trail. If your audit story is "the agent decided to spend this," you have no audit story. The mandate trail (AP2 or equivalent) tying the spend to a human principal is what makes the posture defensible.

What not to do.

Don't put the company Amex in the agent's context window. Don't share one card across multiple agents. Don't rely on the LLM to respect your spending limits. Don't skip the mandate trail because "we'll add it later." Don't use a card provider whose kill switch latency is over 5 seconds. Don't let the agent transact on any-merchant cards when you can scope to a curated allowlist.

Most of these mistakes look fine in the demo. They become career-ending the first time something goes wrong in production. The patterns in this guide are what make the demo and the production case look the same.