AI agents are close to doing something we’ve always kept for humans: buying things online. Whether an agent can click “Buy Now” is no longer the interesting question. What matters is whether we can give it payment authority without handing over an open wallet.
Agentcard just raised an $8 million seed round, led by Peak XV, Fin Capital, and Y Combinator. Its pitch is that AI agents can pay with a user’s own card without ever seeing the card number. Users approve purchases with a passkey, Face ID, or their voice, or they can set up automatic approvals.
The funding is the headline, but the real story is architectural. How do you let a non-deterministic piece of software spend money when it can misread instructions, get manipulated, or loop forever?
The answer is a financial guardrail layer: virtual cards, programmable limits, scoped credentials, and human checks that keep agent spending bounded by design.
When an Agent Has a Wallet
A payment credential isn’t just another API key.
A leaked API key might expose data or run up a cloud bill. A payment credential moves actual money. Give an agent a reusable card with a high limit, and every mistake it makes costs something real.
Picture an agent told to reorder printer paper for under $100. It finds a compatible product, reaches checkout, and hits a payment error. Retrying is the sensible thing to do. But if the checkout page has been tampered with, or the agent misidentifies the product, or it keeps misreading the failure, it may try the charge again and again.
With a standard card, the only thing stopping it is the card limit.
That’s the core problem. A credit card assumes a trustworthy human cardholder with a sensible spending ceiling. An autonomous agent needs a much tighter perimeter.
Why “Just Trust the Agent” Doesn’t Work
The tempting fix is a prompt: “Don’t spend more than $50.” It’s good guidance. It isn’t a control.
Agents are probabilistic. The same task can lead to different tool calls, different readings of the goal, and different paths through checkout. A prompt can be misunderstood, overridden by injected content, or dropped when the agent decides it has found a smarter way to finish the job.
Here’s how it tends to go wrong:
- Prompt injection: A malicious product page, email, or checkout flow talks the agent into changing its behavior.
- Retry loops: An ambiguous or failed checkout triggers repeated authorization attempts.
- Scope creep: An agent sent to buy office supplies decides a $2,000 monitor is “necessary.”
- Duplicate purchases: The agent can’t tell whether the earlier transaction actually went through.
- Credential exposure: A card number or token leaks through logs, browser context, or a sloppy integration.
- Approval fatigue: Users start approving everything on autopilot, and human review stops meaning anything.
The distinction worth remembering: a spending rule inside an agent is advice. A spending limit built into the payment instrument is enforcement.
So What Is Wallet Drift?
Runaway wallet drift is the slow or sudden growth of an agent’s effective spending power.
It rarely starts with a dramatic hack. It usually starts with an ordinary task and a credential that’s a little too broad.
Say an agent has permission to buy a $40 item. It retries a failed order. Then it switches merchants because the first is out of stock. Then it adds shipping, taxes, an upgrade, maybe a subscription. Each step looks fine on its own. Add them up and the agent has wandered far from what the user wanted.
Drift gets dangerous when three things come together:
- Autonomy: The agent can act without waiting for a person.
- Speed: It can do a lot in a few seconds.
- Broad financial access: Its payment method allows far more spending than the task needs.
A safe system has to break at least one of those.
The Financial Guardrail Layer
The answer isn’t to ban agents from paying. It’s to put a control plane between the agent and the money.
A good guardrail layer enforces four things:
| Property | What it means | Why it matters |
|---|---|---|
| Least privilege | The agent receives only the minimum capability needed | Reduces the blast radius of an error |
| Task scoping | A credential is tied to a merchant, cart, amount, and time window | Prevents repurposing across tasks |
| Hard ceilings | Limits are enforced outside the agent’s code | Blocks policy bypass |
| Human override | High-risk actions require separate human approval | Preserves accountability |
The agent can request a payment. It shouldn’t be the one who authorizes it.
Virtual Cards as Sandboxes
Virtual cards are the most practical way to build that perimeter.
Rather than handing an agent a reusable card tied to your full credit line, the guardrail layer can issue a narrow credential for a single task. A well-designed agent card should support:
- Single-use credentials: One card, one merchant, one approved transaction, then it closes automatically.
- Hard amount caps: The maximum charge is set before checkout, not just requested by the agent.
- Merchant locks: The card only works at an approved merchant or merchant category.
- Short lifespan: It expires after the task window or a successful authorization.
- Separate funding: The agent spends from a small dedicated balance, not your whole credit limit.
- Instant freeze: You can stop new authorizations immediately.
This changes the security picture. The agent isn’t holding “a card.” It’s holding a temporary, revocable permission to complete one bounded transaction.
Agentcard’s Issuing product, for instance, creates one-time and multi-use cards for agents, while its Vault product keeps the customer’s real card number hidden from the agent.
Verification Without the Friction
Human approval matters, but it can’t mean signing off on every tiny purchase.
If you have to confirm every $4.99 order, you’ll soon be tapping “approve” without reading. At that point the security control is just a rubber stamp.
Risk tiers work better:
- Low risk: Small, pre-authorized purchases within strict merchant and amount limits.
- Medium risk: A one-tap passkey or biometric confirmation.
- High risk: Explicit approval for unusual merchants, large amounts, subscriptions, travel, crypto, or changes to saved payment details.
- Anomalies: The agent is paused automatically until a human takes a look.
Agentcard follows a similar pattern. Approval can happen through passkey, Face ID, or voice, alongside automatic approvals, and its Voice product is meant to let you approve a purchase without looking at a screen.
The goal isn’t zero friction. It’s proportional friction, concentrated where the financial downside is biggest.
What an Agent Should Never Hold
The strongest guardrail is structural: some capabilities shouldn’t exist inside the agent at all. An agent shouldn’t have:
- The real card number or CVV.
- The ability to raise its own spending limit.
- A reusable credential that works across unrelated merchants.
- Authority to approve its own high-risk transaction.
- Ongoing access to a large pre-funded balance.
- The power to edit audit logs or approval rules.
What it should get is a capability token: permission to start a narrowly defined payment request, checked externally and enforced at the card level.
That’s the difference between giving an agent a credit card and giving it a limited, temporary ability to pay.
The Payment Perimeter
Here’s roughly how a safe flow could work:
- Task initiation: The user sets the goal, budget, merchant scope, and approval rules.
- Policy evaluation: The guardrail layer turns that intent into enforceable constraints.
- Credential issuance: A single-use or task-scoped virtual card is created with a fixed cap.
- Agent checkout: The agent completes the purchase without ever seeing the underlying card details.
- Authorization check: The issuer or card network validates merchant, amount, timing, and available balance.
- Human verification: Transactions that need it trigger passkey, Face ID, or voice approval.
- Credential retirement: The card closes after use, expiry, or task completion.
- Audit trail: Every request, approval, decline, and charge goes into a tamper-evident log.
One rule sits underneath all of it: the agent may initiate, but the guardrail layer decides.
Failures the Guardrail Has to Stop
The best test of this design is to throw realistic failures at it.
The infinite retry loop
An agent tries a $49 purchase, gets a vague error, and retries. Without per-merchant and per-task caps, it could rack up dozens of charges. With a hard cap, the first authorization might go through, but every attempt after that is declined.
The prompt-injected upsell
A compromised checkout page tells the agent a $2,000 item is required to finish the task. The agent tries to pay. The card’s amount cap blocks it before any money moves.
The leaked credential
A virtual card number turns up in a log, a browser context, or a third-party integration. If it’s single-use, merchant-locked, and short-lived, it’s close to worthless to an attacker.
The scope creep
An agent sent to buy printer paper tries to book travel or buy crypto. Merchant and category restrictions decline the transaction.
The approval bypass
The agent tries to raise its own limit or approve its own transaction. Approval rules and card controls live outside the agent, so the attempt fails.
Design Principles for Builders
If you’re building agentic commerce products, treat payment authority as a privileged capability, not a default tool.
- Issue one credential per task, not one reusable card per user.
- Set the limit below the maximum loss you could accept, not at the user’s card limit.
- Keep the policy engine separate from the agent runtime.
- Use biometric or passkey approval for high-risk actions.
- Keep immutable logs that connect intent, approval, card issuance, and settlement.
- Give users a visible kill switch they can hit without contacting support.
- Assume the agent will eventually be manipulated, confused, or stuck in a loop.
You don’t need agents to be perfectly reliable. You need their failures to be financially survivable.
The Market Is Moving
Agentcard’s raise suggests the industry is shifting from “Can an AI agent buy things?” to “What enforceable limits will it buy under?”
The company says its platform lets businesses enable agents to pay with users’ own cards, hides the card number from the agent, and supports approval through passkey, Face ID, or voice. It also offers Issuing for one-time and reusable agent cards, and OpenCommerce for searching, buying, and tracking orders across more than 5,000 online retailers.
That matters because agentic commerce won’t scale on autonomy alone. It will scale on programmable trust: systems that let people hand off tasks while keeping clear, enforceable limits.
Also Read: Why Generative AI Needs a Deterministic “Spine” to Survive High-Stakes Enterprises
The New Rule of Agent Payments
Autonomous agents don’t need unrestricted wallets.
They need guardrails built on the assumption that something will eventually go wrong, so that failure is cheap, visible, and reversible.
The next phase of AI commerce won’t be defined by whether an agent can check out. It will be defined by whether the payment layer can make sure a confused, manipulated, or looping agent never turns a small errand into a financial disaster.
Autonomy without a financial perimeter isn’t convenience. It’s unpriced risk.