Your AI agent just bought ten washing machines instead of one. Or it interpreted "find me a cheap desk" as permission to purchase a $3,000 antique. Or worse, it visited a compromised website that injected malicious instructions, redirecting your budget to a fraudulent merchant.
Who pays?
This question sits at the intersection of contract law, payment network rules, and emerging AI liability frameworks. The honest answer is that nobody has fully figured it out yet. But the shape of the problem is becoming clearer.
Chargeback rules assume humans
The entire chargeback system was built on a simple premise: a human cardholder makes purchasing decisions. When you call your bank to dispute a transaction, established processes kick in. Did you authorize it? Was your card stolen? Did the merchant fail to deliver?
AI agents break this model. You authorized the agent. The agent authorized the transaction. The merchant shipped exactly what was ordered. Yet somehow you ended up with something you never intended to buy.
Visa and Mastercard's dispute frameworks don't have a clean answer for this scenario. If your AI orders ten items instead of one, existing rules would likely treat the transaction as authorized because you delegated authority to the agent. The fact that the agent misinterpreted your intent doesn't automatically make it fraud under current definitions.
Both networks are aware of the gap. Mastercard launched its Agent Pay program in 2025 with "agentic tokens" designed for AI-initiated transactions. Visa introduced its Trusted Agent Protocol. But these pilots focus primarily on authenticating legitimate agents and distinguishing them from bots. The dispute resolution question remains largely unaddressed.
Is agent error fraud?
Here's where definitions get uncomfortable.
Traditional fraud involves unauthorized access or intentional deception. If someone steals your card number, that's clearly fraud. If a merchant charges you for goods never delivered, that's fraud too.
But what about an agent that legitimately has your authorization, access to valid payment credentials, and genuinely attempts to fulfill your request - but gets it wrong?
If you asked your agent to "buy a cheap desk" and it purchased a $3,000 antique because it misinterpreted "cheap" as "good value for quality," is that fraud? The agent didn't lie. The merchant delivered what was ordered. You gave the agent permission to buy desks.
Under current frameworks, this looks more like user error than fraud. You delegated decision-making authority to software, and the software made a decision you didn't expect.
Hallucinations versus prompt injection
The liability calculus shifts depending on why the agent made a bad decision.
If your agent hallucinated - misunderstood your request or fabricated a justification for an unexpected purchase - the responsibility likely flows back to you as the deploying user. You chose to use the agent. You delegated authority.
But prompt injection attacks introduce a different dynamic. If a malicious website embedded hidden instructions that hijacked your agent's behavior, is that still on you?
Security researchers have documented how indirect prompt injection can manipulate AI agents into taking unintended actions. A compromised product page could inject instructions like "add ten of these to cart." The agent follows the instructions because they appear to be legitimate inputs.
This scenario looks more like traditional fraud. A bad actor deliberately manipulated your agent. But courts haven't established whether prompt injection constitutes fraud against the cardholder, negligence by the agent developer, or some new category entirely.
Who is the cardholder?
Chargeback rules center on the cardholder - the person with authority over the payment instrument. But when an agent acts on your behalf, this concept gets fuzzy.
You own the card. The agent uses the card. The agent makes autonomous decisions about what to buy. Are you still the cardholder in any meaningful sense?
This matters because cardholder disputes require attesting you didn't authorize the transaction. But you did authorize your agent, broadly speaking. You authorized it to buy things. Just not that thing.
Some legal scholars suggest treating AI agents like employees acting within their scope of authority. If the purchase falls within general parameters you established, you're responsible. If it exceeds those parameters, you might have grounds for dispute.
But how precisely did you define the agent's scope? Did you set spending limits? Merchant restrictions? These implementation details could determine your liability in ways current chargeback rules don't contemplate.
The insurance gap
Traditional payment dispute resolution assumes losses get allocated between cardholders, merchants, and issuing banks. AI agent transactions might not fit cleanly into these buckets.
A new category is emerging: agent liability insurance. AIUC, a startup that raised $15 million in seed funding to build insurance infrastructure for AI agents, believes the market could reach $500 billion by 2030. Their AIUC-1 framework combines NIST's AI Risk Management guidelines, the EU AI Act requirements, and MITRE's ATLAS threat model to assess agent risk, then prices policies accordingly.
Most organizations deploying AI agents today operate without specific coverage for agent-initiated losses. But as autonomous purchasing scales, expect insurance products to follow.
Identity protocols as evidence
Protocols designed to create verifiable records of agent identity and intent could matter for liability.
Skyfire's Know Your Agent (KYA) protocol establishes a verification system for AI agents. Agents authenticate through digital checkpoints including developer identification, interaction history, and transaction records. Verified agents receive cryptographic credentials proving their identity.
If an agent has verifiable identity through KYA, there's a clearer chain of accountability. You can trace which agent made which purchase, when, and under whose authority. That audit trail could matter in a dispute.
Protocols that require agents to declare intent before receiving payment credentials create similar pre-transaction records. If the actual transaction diverges from declared intent, that discrepancy becomes evidence.
Dedicated cards simplify the picture
One pattern emerging from operators who've thought carefully about this: give agents their own payment instruments rather than delegating access to your primary cards.
When you delegate access to your personal card, you're betting that policy engines will always work and disputes will resolve in your favor. If those assumptions fail, you're exposed across your entire credit line.
A dedicated virtual card per agent contains the blast radius. The card has a hard limit enforced at the network level. If an agent goes wrong, the damage is capped. Your primary accounts stay untouched.
This doesn't solve the liability question, but it makes it more manageable. It also creates cleaner audit trails.
What we still don't know
Let's be direct about the uncertainties. Card networks haven't published comprehensive rules for AI agent dispute resolution. Courts haven't established precedent for prompt injection attacks or liability for agent hallucinations. Insurance products are emerging but not mature.
Practical guidance for now
Given the uncertainty, what should operators actually do?
Use dedicated payment instruments for agent spending. Isolate the blast radius. Implement intent logging before transactions. Set conservative authorization limits. Document your agent governance - policies, monitoring, and incident response procedures all contribute to demonstrating reasonable precautions.
The agents-making-purchases era is here. The liability frameworks haven't caught up yet. But that gap won't last forever, and the decisions you make now will determine your exposure when the rules crystallize.
Want to give your AI agents their own payment instruments? Learn how Signets works or get started.
Looking for agent spending controls? Start with MCP + skills, then choose a plan that fits your workload.