Giving AI agents payment access introduces a class of security problems that most developer security models weren't designed for. The threat model is different: the "user" making purchasing decisions is non-deterministic software that can be prompted, manipulated, or broken in ways a human user cannot. The speed is different: an agent can exhaust a budget in seconds rather than days. And the accountability chain is different: when something goes wrong, you need to reconstruct what the agent did and why.

This checklist organizes the security requirements for AI agent spending into six categories: card issuance, credential storage, MCP access scoping, monitoring, revocation, and audit trails. Work through each section before putting agents in production with real payment access.

Why AI Agent Spending Is a Distinct Security Problem

Traditional payment security assumes a human in the decision loop. Fraud detection systems look for purchases that deviate from a human's behavior patterns. Authorization flows assume a human can be challenged with a verification step. Spending limits are set monthly because humans don't generally exhaust budgets in seconds.

AI agents break all three assumptions:

  • No behavioral baseline: An agent has no "normal" spending pattern to deviate from. A research agent that suddenly starts buying cloud GPU credits looks the same as it did yesterday.
  • Cannot be challenged: SMS verification, CAPTCHA, and "confirm this purchase" dialogs break autonomous agent flows. Security controls designed for humans often create gaps when humans aren't in the loop.
  • Speed is machine speed: A misconfigured agent in a retry loop can exhaust a budget in under a minute. Monthly limits don't help when the damage happens in seconds.

The security model for agent spending therefore has to be proactive rather than reactive. You can't rely on fraud detection after the fact. You have to build spend constraints into the system before the agent runs.

The Checklist

Card Issuance

  • ☐ Issue one card per task, not one card per agent. Cards should be scoped to a specific task context, not shared across tasks or sessions. Each task gets a fresh card with a fresh limit.
  • ☐ Set the load amount at issuance, not as a post-hoc limit. The authorized spend for a task should be loaded onto the card before the task begins. The card balance is the ceiling — when it's gone, all subsequent transactions are declined automatically.
  • ☐ Use single-use or task-scoped cards, not persistent cards. Cards should expire when the task is done. Do not create "agent cards" that persist across sessions with large balances.
  • ☐ Track card-to-task mapping at creation time. Record which card ID was issued for which task so you can attribute spend and audit usage later. Example: agent-cards cards create --amount 15.00 and log the returned card ID against the task.
  • ☐ Set conservative load amounts. Round up to the nearest dollar, not the nearest ten dollars. If a task should cost $2.50, load $3.00, not $10.00.
  • ☐ Never reuse card numbers across different agents or tasks. Even if a task completes with balance remaining, the card should not be reissued to a different task. Revoke it and create a new one.

For background on single-use card security properties, see Single-Use Virtual Cards for AI Security.

Credential Storage

  • ☐ Encrypt card credentials at rest with AES-256-GCM. This cipher provides authenticated encryption — both confidentiality and integrity verification. It's the appropriate standard for financial credential storage. AgentCard uses AES-256-GCM for all stored card data.
  • ☐ Never store card numbers in environment variables. Environment variables are frequently logged, inherited by child processes, and sometimes exported to observability platforms. CARD_NUMBER=4xxx... in your shell environment is a security incident waiting to happen.
  • ☐ Never log card numbers. If your logging configuration captures function arguments, API request bodies, or variable state, ensure card numbers are masked or excluded before they reach the log aggregator.
  • ☐ Never include card numbers in prompts. When you pass context to an agent, don't include the raw card number in the prompt text. Pass a card ID (opaque reference) and let the agent retrieve credentials through an authenticated tool call. This prevents card numbers from appearing in prompt logs, context exports, or model provider storage.
  • ☐ Rotate API keys used to access your card issuance API on a regular schedule. The API key that your agent uses to create cards should be treated as a high-value secret. Rotate it at least quarterly, immediately after any suspected compromise, and when team members leave.
  • ☐ Use JWT/RS256 for API authentication. Token-based auth with RS256 signing provides non-repudiation (you can verify which key signed the token) and supports short expiry times. AgentCard API authentication uses JWT/RS256.

MCP Access Scoping

  • ☐ Grant agents only the MCP tools they need. If an agent's task doesn't require full card credentials, don't expose the get_card_details tool to it. MCP tool access should be scoped to the minimum required for the task.
  • ☐ Do not expose raw card data through MCP tools. MCP tools should return card IDs and balance information, not full card numbers. The agent should never need to see the raw card number to use it — the purchase flow should handle credential resolution server-side.
  • ☐ Audit MCP tool invocations in your logs. Every time an agent calls a payment-related MCP tool, log it. You want a complete record of which tools were invoked, with what parameters, and what was returned.
  • ☐ Separate issuance and spending permissions if your architecture supports it. In multi-agent systems, the agent that decides to spend and the agent that issues the card can be separated. This creates an authorization checkpoint between "this agent wants to spend money" and "a card has been issued."
  • ☐ Test that your MCP configuration doesn't expose unintended tools. Ask the agent to call list_cards after setup to confirm which tools are accessible in your configuration. Verify this list matches your intent.

Monitoring

  • ☐ Set up balance check monitoring for active cards. Poll active card balances at regular intervals during task execution. Alert if a card's balance drops faster than expected for the task type.
  • ☐ Log all spend events with task context. Every transaction against an agent card should be logged with: card ID, task label, merchant, amount, timestamp, and whether the transaction succeeded or was declined.
  • ☐ Alert on declined transactions. A declined transaction may mean a task tried to spend more than authorized. This is useful signal — it might mean a task is misbehaving, or it might mean your load amounts are too conservative for a legitimate task.
  • ☐ Monitor for rapid successive transactions. Multiple transactions in a short window (say, more than 3 transactions in 60 seconds on a single card) should trigger an alert. This pattern often indicates a loop or retry bug.
  • ☐ Set up spend velocity alerts at the account level. Beyond individual card monitoring, watch total spend across all agent cards per hour and per day. Anomalies at the account level can indicate systemic issues not visible at the individual card level.
  • ☐ Review spend logs weekly during initial deployment. For the first 30 days of production agent spending, manually review spend logs weekly. You'll catch patterns and anomalies that automated alerting misses.

For a comprehensive approach to tracking agent expenses, see AI Agent Expense Tracking.

Revocation

  • ☐ Know how to disable a card immediately. Every person with access to your agent infrastructure should know how to disable a card and be able to do so in under 30 seconds.
  • ☐ Revocation is instant — use it aggressively. If you suspect a card is being misused, revoke first and investigate second. Revocation is instant. Subsequent transactions are declined immediately. There is no cost to revoking a card unnecessarily beyond the small operational overhead of issuing a new one.
  • ☐ Automate revocation when tasks complete. In your task orchestration system, add a cleanup step that revokes the task card when the task finishes — whether it succeeds, fails, or times out. Don't leave cards active after their task is done.
  • ☐ Test your revocation flow before production deployment. Issue a test card, attempt a small transaction, revoke it, then confirm subsequent transactions are declined. Know that the flow works before you need it in an emergency.
  • ☐ Revoke all agent cards as part of incident response. If you have a security incident affecting your agent infrastructure, revoke all active agent cards immediately as part of your incident response checklist. This is a precautionary step that costs almost nothing but closes a potential vector.

Audit Trail

  • ☐ Log card creation with task context. When a card is issued, log: card ID, creation time, load amount, task ID, task label, and the agent or workflow that requested it.
  • ☐ Log all transactions against agent cards. The minimum fields: card ID, transaction time, merchant name, transaction amount, success/decline status.
  • ☐ Log card revocations with reason. When a card is revoked, log: card ID, revocation time, revocation reason (task complete, suspicious activity, manual revocation), and who or what triggered the revocation.
  • ☐ Retain spend logs for at least 12 months. Finance reconciliation, security incident review, and compliance audits all need historical data. 12 months covers most audit requirements; consult your compliance team for your specific retention requirements.
  • ☐ Make audit logs immutable. Spend logs should be write-once. An audit trail that can be modified after the fact provides no assurance. Use an append-only log store for agent spend records.
  • ☐ Implement HMAC-SHA256 for webhook verification. If you're consuming spend event webhooks, verify the HMAC-SHA256 signature on each webhook before processing it. This ensures you're not ingesting forged or replayed events. AgentCard webhooks include an X-Agent-Cards-Signature header containing the HMAC-SHA256 signature.

Common Mistakes

Mistake: Using a shared card with a large balance "for convenience"

One of the most common configurations in early-stage agent deployments is loading $500 onto a single card and giving it to every agent task. This is convenient right up until a retry loop spends $480 in four minutes. Use per-task cards with conservative load amounts. The issuance overhead is negligible (under 2 seconds), and the safety benefit is significant.

Mistake: Storing the card number in an environment variable

A developer runs export AGENT_CARD_NUMBER=4xxx... in their shell, starts the agent process, and the card number immediately enters the environment of every subprocess, gets captured by process inspection tools, and is potentially logged by the agent framework's startup logging. Card numbers should be retrieved at runtime through authenticated API calls, not stored in the shell environment.

Mistake: Passing full card credentials in the agent prompt

Including "use card number 4xxx xxxx xxxx 7842, CVV 123, expiry 04/2026" in a system prompt means that text appears in every context window the agent processes, potentially gets stored in conversation logs, and gets transmitted to any model provider the agent uses. Pass a card ID and let the agent retrieve credentials through a scoped tool call.

Mistake: Not testing revocation before production

Revocation is a safety control that needs to work under pressure. If you've never run the revocation command against a real card and confirmed that subsequent transactions are declined, you don't actually know if your revocation flow works. Test it before you need it.

Mistake: Giving agents more MCP tool access than they need

If you expose all AgentCard MCP tools (list_cards, get_card_details, check_balance) to every agent, a compromised or misbehaving agent can access full card credentials unnecessarily. Scope tool access to what each agent type actually needs — an agent that only needs to check balances doesn't need get_card_details.

The Security Architecture in One Diagram

The secure agent spending architecture looks like this:

  1. Task is scheduled with an authorized budget
  2. Orchestrator issues a task-scoped virtual debit card via the AgentCard API (balance = authorized budget, label = task ID)
  3. Card ID (not card number) is passed to the agent as a tool parameter
  4. Agent retrieves card credentials at runtime via authenticated MCP tool call
  5. Agent completes task, spending from the card
  6. Orchestrator revokes the card when the task completes (or it expires naturally)
  7. Spend log is written to immutable audit store with task context

At no point does the card number appear in a prompt, an environment variable, or a log file. At no point does an agent have access to more money than its specific task is authorized to spend. At every point, the spend record is attributable to a specific task.

Frequently Asked Questions

What encryption should be used for storing AI agent card credentials?

Card credentials should be encrypted at rest using AES-256-GCM. This cipher provides both confidentiality and integrity verification (authenticated encryption), making it appropriate for financial credential storage. AgentCard uses AES-256-GCM for all stored card data.

How quickly can an AgentCard virtual card be disabled?

Disabling a card is instant. Any subsequent transaction attempts will be declined immediately with no delay.

Should AI agents share virtual cards across tasks?

No. Each task should receive its own card with a defined load amount. Shared cards mean shared blast radius — a misbehaving agent can spend the full shared balance. Per-task cards limit the maximum possible damage to the amount loaded for that specific task.

What should be logged for AI agent spending audit trails?

Log: card ID, creation timestamp, load amount, associated task ID or label, all transaction attempts (successful and declined), transaction amounts and merchants, revocation timestamp if revoked, and whether the card expired naturally or was actively revoked.

Is it safe to pass card numbers in environment variables for AI agents?

No. Environment variables are frequently logged, exported to child processes, and sometimes included in error reports or observability tooling. Card numbers should never appear in plaintext in env vars, logs, or prompts. Use encrypted credential storage with runtime decryption, and prefer card IDs (references) over card numbers wherever possible.

For the full picture of how AI agents interact with payment systems, see How AI Agents Make Payments.