How to secure agentic commerce transactions

Visa's Payment Ecosystem Risk and Control (PERC) team reported a more than 450% increase in dark web posts mentioning "AI Agent" in the first half of 2026 compared to the prior six months. The posts aren't about building agents. They're about compromising them. Specifically, they're about hijacking the delegated payment credentials that agents hold on behalf of users and using them to complete transactions that appear legitimate in every way except intent.

This is the core problem with agentic commerce security: the fraud looks clean. When an attacker steals a credit card and uses it at checkout, fraud detection systems can flag the mismatched device fingerprint, the unfamiliar shipping address, the unusual purchase pattern. When an attacker compromises an AI agent that already holds the user's tokenized payment method, saved addresses, and purchase history, the resulting transactions look identical to the agent's normal behavior. The payment method is already trusted. The addresses are already on file. The purchase patterns fit within established bounds. As Signifyd's 2026 fraud analysis put it, agentic commerce fraud shows up as "clean, fast, and successful transactions" rather than the noisy, chaotic behavior that traditional fraud systems are trained to detect.

This isn't a future risk. Google's Universal Commerce Protocol (UCP) launched in January 2026 with Shopify, Etsy, Wayfair, Target, Walmart, Visa, Mastercard, and 20+ other partners. OpenAI's Agentic Commerce Protocol (ACP) enables purchases inside ChatGPT with Stripe processing payments, with Shopify enabling over a million merchants at launch. Chrome auto browse is rolling out to Android in late June 2026, letting Gemini complete multi-step purchasing flows in the browser the user is already logged into. Bain & Company estimates that agentic AI will handle 15 to 25% of all e-commerce volume by 2030. McKinsey puts the potential revenue at $3 to $5 trillion globally.

The scale is coming. The security model isn't ready.

The attack surface has moved

Traditional e-commerce fraud targets the human: phishing, social engineering, stolen credentials, checkout trickery. The attacker's job is to trick the person into revealing information or authorizing a transaction they didn't intend.

Agentic commerce fraud targets the agent. The human has already delegated authority: they've connected a payment method, set spending preferences, and told the agent to shop on their behalf. The attacker doesn't need to trick the user. They need to trick (or compromise) the agent.

The attack vectors that security researchers and fraud teams are tracking in 2026 include:

• ‍Agent credential theft. The agent holds delegated access tokens, payment tokens, and session credentials. If those credentials are stolen through a compromised device, a malicious browser extension, or a supply chain attack on the agent's dependencies, the attacker can act as the agent with all its authorized permissions.‍
• Agent impersonation. DataDome's AI Traffic Report found nearly 8 billion AI agent requests across their network in January and February 2026, with significant impersonation rates. PerplexityBot experienced a 2.4% impersonation rate, and Meta-ExternalAgent saw over 16 million spoofed requests in just two months. An attacker impersonating a legitimate agent can make requests that merchants treat as trusted.‍
• Counterfeit merchant attacks on agents. Visa's threat analysis describes fraudulent storefronts engineered specifically to exploit AI shopping agents. The fake store passes automated security checks and offers prices below market rate. The agent, optimized to find the best deal, completes the purchase using stored credentials. The malicious merchant harvests the payment data.‍
• Prompt injection leading to unauthorized purchases. An agent browsing product pages encounters hidden instructions that redirect it to a different merchant or cause it to add items the user didn't request. The agent completes the checkout because it has the credentials and the authorization to do so. Every tool call was "authorized." The intent was hijacked.‍
• Credential reuse and balance draining. Signifyd describes a pattern where a compromised agent makes back-to-back purchases using the customer's payment method until spending limits are hit, balances are drained, or the card is declined. Because the payment method is already tokenized and trusted, each transaction clears authorization and fraud checks with minimal friction.

What needs to change

The security model for agentic commerce needs to address three gaps that don't exist in traditional e-commerce: agent identity, scoped delegation, and transaction-level consent.

Agents need their own identity

When a human makes a purchase, they authenticate with the merchant directly: a login, a session cookie, a payment credential. The merchant knows who they're dealing with.

When an agent makes a purchase, the merchant sees a request with valid credentials. But whose credentials? The user's? The agent platform's? A compromised intermediary's? Without agent identity, the merchant can't distinguish a legitimate agent acting on behalf of an authorized user from an impersonator using stolen tokens.

Each agent needs its own authenticated identity, separate from the user. The agent authenticates as itself (via OAuth 2.1 client credentials), and the request carries both the agent's identity and proof that a specific user authorized this specific agent to act on their behalf. This is the same per-agent credential model described in the credentials guide, applied to commerce.

On the merchant side, this means verifying two things on every transaction: that the agent is who it claims to be, and that the user's delegation is current and valid. Token replay and impersonation attacks become harder when the agent has its own verifiable identity rather than just passing through the user's session.

Delegation needs to be scoped and time-bound

A user telling an agent "find me the best running shoes under $150" is not the same as telling it "spend up to $150 on anything you think I'd like." But most current agent delegation models treat them as equivalent: the agent has a payment method and a spending cap, and everything within that cap is authorized.

Delegation should be scoped along multiple dimensions:

• ‍Transaction type. What categories of purchases can the agent make? Running shoes, not electronics. Groceries from an approved list of stores, not from any merchant the agent discovers.‍
• Amount. Per-transaction limits, per-session limits, and daily aggregate limits. Not just a single spending cap.‍
• Merchant allow lists. Which merchants is the agent authorized to transact with? A user who wants an agent to reorder household supplies from their usual stores is not authorizing the agent to find a cheaper unknown merchant.‍
• Time windows. Delegation should expire. An agent authorized to shop during a weekend planning session shouldn't still hold that authorization three weeks later.

  
interface CommerceDelegation {
  userId: string;
  agentId: string;
  issuedAt: string;
  expiresAt: string;
  scope: {
    categories: string[];           // e.g., ["running_shoes", "athletic_apparel"]
    maxPerTransaction: number;      // e.g., 150.00
    maxPerSession: number;          // e.g., 300.00
    maxPerDay: number;              // e.g., 500.00
    allowedMerchants?: string[];    // e.g., ["nike.com", "zappos.com"]
    blockedMerchants?: string[];
  };
  requiresApproval: {
    aboveAmount: number;            // e.g., 100.00, require explicit user confirmation
    newMerchant: boolean;           // require confirmation for first purchase from a merchant
    recurringPurchase: boolean;     // require confirmation for subscriptions
  };
}
  

This is where RBAC and FGA from the identity layer meet commerce. The agent's role defines what categories of actions it can take. FGA defines which resources (merchants, product categories, spending tiers) the delegation covers. The authorization check on every transaction evaluates both.

High-stakes actions need explicit consent

Chrome auto browse already implements this pattern: the agent pauses and asks for user confirmation before completing a purchase or posting on social media. This isn't just a UX nicety. It's a security boundary.

The rule should be: any action that moves money, creates a binding commitment, or shares personal information requires a step-up interaction where the user explicitly confirms the specific action the agent is about to take. Not a blanket "I authorize this agent to act on my behalf." A specific "Confirm: purchase Nike Air Zoom Pegasus 41 from zappos.com for $129.99 on Visa ending 4242."

  
interface TransactionApprovalRequest {
  agentId: string;
  transactionId: string;
  action: 'purchase' | 'subscription' | 'refund_request';
  merchant: {
    name: string;
    domain: string;
    verified: boolean;
  };
  items: {
    description: string;
    amount: number;
    currency: string;
  }[];
  totalAmount: number;
  paymentMethod: string;      // e.g., "Visa ending 4242"
  delegationId: string;       // Links to the CommerceDelegation that authorized this
}
  

Step-up consent also serves as a defense against prompt injection. If a hidden instruction on a product page causes the agent to add an extra item to the cart, the user sees that item in the confirmation request and can reject it. The injection succeeded at the agent level but was caught at the consent boundary.

Audit everything

Every agentic commerce transaction needs an audit trail that captures the full chain from user delegation to agent action to merchant confirmation. When a disputed transaction arrives and the user says "I didn't authorize that," you need to answer:

• ‍Who delegated what? The specific delegation scope the user granted, when they granted it, and when it expires.‍
• Which agent acted? The authenticated agent identity, its client credentials, and the platform it operates on.‍
• What did the agent do? Every merchant interaction, product search, cart modification, and checkout step, with timestamps and the delegation ID that authorized each action.‍
• Did the user confirm? Whether a step-up consent was triggered, what the user was shown, and whether they approved or rejected.‍
• What did the merchant verify? Whether the merchant validated the agent's identity, checked the delegation scope, and confirmed the transaction was within bounds.

This audit trail needs to survive disputes. When a chargeback arrives three months later, you need the same forensic capability that the delegation article described for inter-agent communication: the ability to reconstruct the full chain from a single transaction ID.

The liability question

Hogan Lovells' February 2026 analysis of agentic payments raises a question the industry hasn't resolved: if an agent makes an unauthorized or erroneous purchase, where does responsibility sit?

With the user who delegated authority? With the agent platform that operated the agent? With the merchant who accepted the transaction? With the payment network that processed it?

The honest answer is that nobody knows yet. Chargeback models, fraud scoring, and dispute processes were all designed around human purchasing behavior. The legal and regulatory frameworks haven't caught up. The World Economic Forum estimated that by 2028, one in four data breaches could result from AI agent exploitation, which will force the question.

What you can do now is build the infrastructure that makes the answer traceable. If you have agent identity, scoped delegation, step-up consent, and a complete audit trail, you can prove exactly what was authorized, by whom, and when. You may not know yet who bears the liability, but you'll have the evidence to answer the question when the frameworks arrive.

Securing AI agents and MCP servers with WorkOS

WorkOS provides OAuth 2.1 for session-scoped per-agent credentials so agents authenticate as themselves rather than passing through user sessions. FGA enables resource-scoped delegation: which merchants, which transaction types, which spending tiers the agent is authorized for. Audit logging captures the full chain from delegation to transaction. And native MCP server authentication secures the tool layer that agents use to interact with commerce APIs. The delegation and consent patterns in this article sit on top of that foundation.