Giving an AI agent access to payment credentials is a solved problem in the same way that leaving your house key under the doormat is a solved problem: it works until it doesn't, and when it doesn't, the consequences are proportional to how much you left exposed.
The standard approach — sharing a real card number or a billing account credential with an agent — fails on several dimensions simultaneously. This post explains the threat model, how single-use virtual debit cards address it, and how AgentCard implements the security properties that matter.
The threat model: what goes wrong with open-ended payment access
Before discussing solutions, it's worth being precise about the failure modes. When an AI agent has access to a real card or a persistent payment credential, several things can go wrong.
Overspend by the agent itself
Language model agents make mistakes. An agent instructed to "buy the cheapest available option" might misinterpret "available" in a context where an expensive tier is technically available. An agent given a vague budget might interpret it differently than intended. Without a hard ceiling, these mistakes express themselves as charges — and the ceiling on a real card is your credit limit, not your intent.
Prompt injection and manipulation
An agent browsing the web, reading emails, or processing external data can be manipulated by adversarial content embedded in that data. A malicious website might include hidden instructions that redirect the agent's behavior, including its payment behavior. If the agent holds a persistent credential with uncapped access, a successful injection attack can result in unauthorized charges up to that limit. The OWASP LLM Top 10 (LLM08: Excessive Agency) identifies this as a critical risk when agents have access to sensitive tools without proper constraints.
Credential leakage
Real card numbers are sensitive. An agent operating across multiple services, APIs, and data stores has a larger surface area for credential exposure than a human manually entering a number into a single checkout form. The more places a credential is used or stored, the more places it can leak.
Long-lived access after task completion
If an agent's payment credential doesn't expire when the task ends, it remains a live attack surface. A credential issued for a one-time research task and never revoked is available for misuse indefinitely — by the agent, by any system the agent interacted with, or by anyone who obtains the credential later.
How single-use cards contain the blast radius
A single-use virtual debit card addresses each of these failure modes by construction, not by policy.
The core insight is that the card's loaded amount is its hard ceiling. There is no way for a charge to exceed the funded amount — not by agent error, not by manipulation, not by credential leakage. The worst-case outcome from any failure mode is bounded by the amount on the card, which you set when you issue it.
This is the concept of blast radius containment: when something goes wrong, the damage is limited to the resources that were explicitly allocated to that context. A single-use card issued for a $15 task has a blast radius of $15. A real card with a $10,000 limit has a blast radius of $10,000.
The math is straightforward. The question is whether you want to operate with a $15 blast radius or a $10,000 one.
How AgentCard implements single-use cards
One card per task
The design pattern AgentCard is built around is issuing one virtual debit card per task or per agent session. The card is created with an explicit loaded amount — the maximum the agent is permitted to spend on that task. The card number, CVV, and expiry are issued programmatically via agent-cards cards create --amount N and returned to the agent.
The agent uses those credentials for the task's purchases. When the task completes — or when the card's funds are exhausted — the card is no longer useful. It either expires or is explicitly revoked.
This is a structural limit, not a policy limit. There is no configuration the agent can change, no permission it can escalate, and no way to exceed the loaded amount. The limit is enforced at the payment network level.
Loaded amount equals spending ceiling
When you issue a card with --amount 25, you are funding that card with $25.00. That is the exact ceiling. If an agent attempts a charge of $30.00 against a card funded for $25.00, the charge declines. The agent cannot proceed. No configuration changes this behavior — it is a property of the card, not a setting.
This means the security guarantee is: no single compromised or misbehaving card can result in losses exceeding its funded amount. The guarantee holds regardless of what the agent does, what instructions it receives, or what manipulation it is subjected to.
For a walkthrough of how to set amounts and what happens when the limit is hit, see How to Set Spending Limits on AI Agents.
Card lifecycle: issued, used, expired, revoked
Every AgentCard virtual card moves through a defined lifecycle. Understanding it is useful for reasoning about the security properties at each stage.
Issued
The card is created via agent-cards cards create --amount N. A card ID, PAN, CVV, and expiry are generated. The PAN and CVV are encrypted at rest immediately (more on this below). The card is active and can be charged up to its loaded amount.
In use
The agent holds the card credentials and uses them for purchases. Each charge reduces the available balance. The card can be charged multiple times until the balance is zero, or it can be issued with a configuration that treats the first successful charge as the end of its life — true single-use behavior.
Expired
Cards have expiry dates. An expired card cannot be charged. If you are issuing cards for short-lived tasks, setting a short expiry is a good practice — it means that even if you forget to revoke a card after a task completes, it will become inert on its own.
Revoked
Any active card can be disabled instantly. A disabled card is immediately ineligible for new charges. This is the right action when a task completes, when an agent behaves unexpectedly, or when you want to terminate payment access for any reason without waiting for expiry.
Disabling is instantaneous — no billing cycle, no card replacement process, no delay. This matters for incident response: if you detect suspicious agent behavior, you can cut off its payment access in seconds.
Encryption: AES-256-GCM at rest, decrypted on demand
The PAN (primary account number) and CVV are the sensitive fields. AgentCard encrypts both at rest using AES-256-GCM.
Why AES-256-GCM
AES-256-GCM is an authenticated encryption scheme. It provides two guarantees simultaneously: confidentiality (the ciphertext reveals nothing about the plaintext without the key) and integrity (any tampering with the ciphertext is detectable). For payment credentials, both properties matter. You need to know the data is confidential, and you need to know it hasn't been modified. This aligns with PCI DSS v4.0 Requirement 3 for protecting stored account data.
Decryption on demand only
The PAN and CVV are not stored in plaintext anywhere in the AgentCard system. When you issue a card, the plaintext credentials are returned to you once — at issuance — and then stored only in encrypted form. If you call a tool or API endpoint that requires the PAN (for example, to pass to a checkout form), the system decrypts on demand for that specific request and does not persist the plaintext.
This means that the attack surface for plaintext credential exposure is limited to the moment of issuance and the moment of explicit retrieval. A database compromise, a log leak, or a backup exposure would yield ciphertext, not PANs.
What this means for agent workflows
From the agent's perspective, the PAN is available when it needs it (via the get_card_details tool) and not otherwise. The agent should not cache or store the PAN beyond the immediate use — it should retrieve it when needed, use it, and discard it. This keeps the agent's own memory footprint free of long-lived payment credentials.
Comparison: shared API key vs single-use card
To make the security difference concrete, consider two ways of giving an agent payment access.
Shared API key or real card number (the common pattern)
- Spending ceiling: credit limit or account balance — effectively uncapped from the agent's perspective
- Blast radius: full account exposure on compromise
- Revocation: requires changing or canceling the real card, which affects all systems using it
- Expiry: none — the credential remains valid until manually rotated
- Attribution: all charges appear on one account; no per-task isolation
- Prompt injection risk: any successful injection can spend up to the account limit
Single-use virtual debit card via AgentCard
- Spending ceiling: loaded amount — set by you at issuance, enforced by the payment network
- Blast radius: loaded amount only — $15 task, $15 maximum exposure
- Revocation: instant, per-card, does not affect other cards or accounts
- Expiry: configurable — cards expire and become inert automatically
- Attribution: one card per task; charges are isolated and traceable
- Prompt injection risk: any successful injection can spend at most the card balance
The single-use card model doesn't eliminate the possibility of agent misbehavior or adversarial manipulation. What it does is ensure that any such event is bounded. You can operate agents with payment access, at scale, without accepting unbounded financial risk — because the risk is capped at issuance.
Putting it together
The security model for AgentCard is not primarily about strong passwords or access controls, though those matter. It is about structural limits: making it architecturally impossible for a single compromised or misbehaving agent to exceed the resources allocated to its task.
One card per task. Loaded amount equals ceiling. AES-256-GCM at rest. Instant revocation. Automatic expiry. These properties compose into a security posture where the worst-case outcome from any single failure is bounded and manageable. This architecture follows NIST SP 800-207 zero trust principles: never trust, always verify, and limit blast radius.
For a practical checklist of security practices to build around these properties, see the AI agent spending security checklist. For how to set the amounts when issuing cards, see How to Set Spending Limits on AI Agents.
Frequently Asked Questions
What is "blast radius" in the context of AI agent payments?
Blast radius is the maximum financial damage possible from a single failure — whether that's an agent error, prompt injection attack, or credential leak. With a real credit card the blast radius is your credit limit. With a single-use virtual debit card loaded with $15, the blast radius is $15, regardless of what the agent does or what manipulation it is subjected to.
How does a single-use virtual card protect against prompt injection attacks?
Even if an adversarial instruction embedded in a webpage or email successfully manipulates the agent into attempting an unauthorized purchase, the card's loaded amount is a hard ceiling enforced at the payment network level. A successful injection attack can spend at most the card's balance — it cannot access any additional funds regardless of what instructions the agent receives.
How is card data encrypted in AgentCard?
The PAN (card number) and CVV are encrypted at rest using AES-256-GCM, an authenticated encryption scheme that provides both confidentiality and integrity verification. Plaintext credentials are returned once at issuance and then stored only in encrypted form.
How quickly can a card be revoked if an agent behaves unexpectedly?
Disabling a card is instantaneous — any subsequent transaction attempt is declined immediately. There is no delay, no billing cycle to wait for, and no support ticket to file.
What is the difference between a card expiring and a card being revoked?
Both result in a card that cannot be charged, but they operate differently. Expiry is automatic — a card with a short expiry date becomes inert on its own. Revocation is immediate and manual — you actively terminate the card before its expiry date, typically when a task completes or suspicious activity is detected.