Alchemy’s AgentCard is not just another virtual card. It is a Visa payment instrument issued to a piece of software—an AI agent—that can authorize transactions, manage its own balance, and stay within spending limits defined by code, not by a human tapping a phone. The product, announced this week, connects an agent’s operational logic directly to Visa’s global acceptance network through a single API. The agent gets a card number, a set of tokenized payment rails, and a policy engine that decides what it can and cannot buy. The surface-level story is “AI agents can now pay for things with Visa.” The deeper story is about who controls the spending, how those controls are enforced, and what happens when they fail.
How AgentCard Works Under the Hood
AgentCard is a virtual Visa card issued through Alchemy’s platform, but the issuance model is fundamentally different from a consumer or business card. A human developer provisions the card via an API call, defining a set of spending policies—maximum transaction amounts, allowed merchant categories, daily velocity limits, and geographic restrictions. The agent then receives a tokenized card number that it can use wherever Visa is accepted online. Settlement happens on crypto rails: the developer funds the card with USDC or another supported token, and Alchemy handles the conversion and settlement with Visa’s network. The agent never holds the underlying fiat; it only sees the tokenized instrument and the policy envelope around it.
The architecture splits into three layers. The top layer is the agent’s decision logic—the code that determines when to make a purchase. The middle layer is Alchemy’s policy engine, which intercepts every transaction attempt and checks it against the developer-defined rules before it ever hits Visa’s network. The bottom layer is Visa’s existing authorization and settlement infrastructure, which processes the transaction like any other Visa card payment. This means the agent’s spending is constrained at the API level, not at the bank level, which is a departure from how corporate cards typically enforce controls.
Programmable Controls Are the Real Product
The card number itself is a commodity. What makes AgentCard interesting is the programmable control plane that sits between the agent and the Visa network. A developer can set per-transaction caps, block entire merchant category codes, enforce time-of-day restrictions, and set velocity limits that prevent an agent from draining its balance in a loop. These controls are enforced in software before the transaction is submitted for authorization, which means a misbehaving agent—or a compromised API key—cannot exceed its bounds even if it tries.
This is a different security model from giving an agent a standard debit card or a shared corporate card. With a traditional card, spending controls are typically set at the issuer level and are coarse: a monthly limit, a set of blocked MCCs, maybe a geographic restriction. AgentCard’s controls are fine-grained and dynamic. A developer could, for example, allow an agent to spend up to $50 per transaction on cloud compute but only $5 on data feeds, and only between 9 AM and 5 PM UTC. If the agent tries to exceed those limits, the transaction is rejected before it reaches Visa, and the developer gets an alert. The policy engine is the moat, not the card.
The Liability Question Nobody Is Asking
When a human’s credit card is stolen and used fraudulently, Visa’s zero-liability policy typically protects the cardholder. When an AI agent’s virtual card is compromised—say, an attacker steals the API key that controls the agent—who is liable? The agent is not a person. It cannot file a dispute or swear an affidavit. The developer who provisioned the card is the legal entity behind it, but the card was issued to the agent, not to the developer’s personal identity. Visa’s existing fraud rules were not written for a world where the cardholder is a piece of code that can be tricked into authorizing payments through prompt injection or API manipulation.
Alchemy has not publicly detailed its fraud liability model for AgentCard. The policy engine reduces the blast radius of a compromise by capping what an agent can spend, but it does not eliminate the risk. If an attacker gains control of the agent and stays within the policy limits, the transactions will be authorized. The question then becomes whether Visa treats those transactions as authorized by the cardholder—the agent—or as fraudulent. The answer will likely depend on the specific terms Alchemy has negotiated with its issuing bank, and those terms are not public. This is the open wound in the agentic payments story that few are talking about.
Where This Fits in the Agent Payments Landscape
AgentCard enters a market that is rapidly segmenting. On one side, there are crypto-native protocols like x402, which let agents pay for API access in USDC over HTTP without touching the traditional card networks. On the other side, there are the card networks themselves—Visa and Mastercard—which are building agentic commerce tools that embed payments into AI-driven shopping flows. AgentCard sits in the middle: it uses Visa’s rails for acceptance but adds a crypto-native funding and control layer on top. This is the same two-layer architecture we have seen from Mastercard’s agentic commerce rollout: stablecoins for settlement, legacy rails for authorization and acceptance.
The difference is that Alchemy is not a card network. It is a developer platform that abstracts the complexity of issuing and managing virtual cards for agents. The bet is that developers do not want to become payments experts; they want an API that gives their agent a card number and a set of spending rules. If that bet pays off, AgentCard could become the default way AI agents spend money online—not because it is revolutionary technology, but because it is a familiar form factor with a developer-friendly interface.