Blog: Art-Kubed

Stop Dollar Exfiltration: Operant Agent Protector Now Defends Agentic Commerce

New protocols define how agents prove authority and move money. They do not determine whether a particular payment makes sense for the task the agent is performing right now. That's where Operant comes in.

Stop Dollar Exfiltration: Operant Agent Protector Now Defends Agentic Commerce

The payments industry spent 2026 building something it never needed before: rails that let software spend money with no human at the checkout.

Visa, Mastercard, American Express, Stripe, Google, AWS, and Shopify are all premier members of the new x402 Foundation. Stripe and Tempo launched the Machine Payments Protocol, and Visa extended it to cards. Google handed AP2 to the FIDO Alliance and shipped “Human Not Present” payments, so an agent can complete a purchase while nobody is watching. x402, MPP, and AP2 are all new industry protocols for agentic commerce that are already spending money without human oversight.

This is shaping up to be the next trillion-dollar economy. Gartner predicts AI agents will intermediate more than $15 trillion in B2B purchases by 2028. McKinsey projects agentic commerce could orchestrate $3 to $5 trillion in global revenue by 2030. These timeframes for widespread adoption at such scale are unprecedented. Are you ready?

Where the protocols stop

x402, governed by the Linux Foundation, lets an agent pay for an API or MCP tool inside a standard request. MPP, co-authored by Stripe and Tempo, works across cards, stablecoins, and Lightning, and on Tempo adds sessions that let an agent stream micropayments against a pre-authorized limit. AP2, created by Google and now stewarded by the FIDO Alliance, uses signed mandates to record what a user authorized an agent to purchase.

These protocols define how agents prove authority and move money. They do not determine whether a particular payment makes sense for the task the agent is performing right now.

That decision must happen transaction by transaction, before money moves.

Two ways to get agent payments wrong

The first is letting too much through.

Imagine an agent researching suppliers with an approved budget. A malicious MCP server injects an instruction, causing the agent to call a paid attacker-controlled service. The payment credentials are valid and the amount is below the agent’s budget, so protocol-level checks alone see nothing wrong.

We call this dollar exfiltration: the unauthorized diversion of money through an otherwise valid agent payment. Instead of stealing a wallet key, an attacker manipulates the agent’s instructions or tool path so the agent signs and submits the payment itself.

It is the financial analog of data exfiltration. Data exfiltration uses legitimate access or compromised workflows to move information to an unauthorized destination; dollar exfiltration uses those same techniques to move value. In both cases, credentials and transport may be valid. The security failure is that the destination or purpose falls outside what the user intended.

The same damage can occur without an attacker. An agent might loop on a paid API, repeatedly purchase the same data, or invoke services its task never required.

The second failure is blocking too much.

If an agent must wait for human approval every time it spends $0.40 on a data call, the autonomy benefit disappears. Blanket approval gates, coarse spending caps, and policies that block every unfamiliar interaction encourage teams to disable security entirely.

Agentic commerce needs both at once: agents that can pay freely within their task, and purse strings that tighten the moment they stray outside it.

Operant Agentic Commerce Defense protects x402, MPP and AP2 transactions in real-time

Protection at the time of transaction

Operant Agent Protector’s Agentic Commerce Defense evaluates each agent payment attempt before it is forwarded.

The decision combines the agent’s task, the paid tool call, the MCP server, the payment destination, the amount, and the organization’s commercial policy.

Task-aware payment gating

Operant evaluates the paid tool call and its arguments against the task the user gave the agent. A research agent purchasing an approved data feed can continue without interruption. If that same agent suddenly attempts an unrelated administrative action or calls a service outside the task, Operant can block the payment before it is submitted.

Commercial scope

Organizations define which MCP servers, payment networks, assets, and wallet destinations an agent may use. A payment to an unapproved destination is blocked even when the credentials are valid and the amount remains within budget.

Purse strings

Atomic spending limits can be applied by agent or service, MCP server, user, team, network, and asset, with hourly, daily, weekly, or monthly windows. Operant reserves budget before forwarding the payment. Concurrent agents and gateway replicas therefore cannot independently consume the same remaining allowance. Destination policy and spend budgets work together: one controls where the agent may pay, while the other controls how much it may spend.

Intent checks

Operant's Semantic Firewall evaluates paid tool activity against the session's original task. It can flag behavior consistent with prompt injection, task drift, or a runaway loop—even when the payment itself is properly authorized and under budget.

Audit without custody

Operant records payment requests, policy decisions, submissions, and reported outcomes without storing payment proofs or signing transactions. The agent's wallet remains responsible for authorization and settlement. Operant controls whether the payment attempt may proceed; it does not hold customer keys or become the payment custodian.

‍

Operant Agent Commerce Dashboard

One guard across an interlocking stack

Agent payment protocols are complementary rather than mutually exclusive. MPP can interoperate with x402 services. AP2 can use x402 for stablecoin settlement. All three can participate in MCP-based tool flows. Operant applies one transaction-level policy model across them, so commercial scope follows the agent instead of the payment rail:

  • Is this paid action consistent with the user's task?
  • Is this agent permitted to use this MCP server?
  • Is the destination approved?
  • Is the network and asset allowed?
  • Does sufficient budget remain?
  • Does the activity resemble injection, drift, or a payment loop?

The payment protocol handles authorization and settlement. Operant determines whether the agent should be allowed to make that payment in the first place.

Your agents get a wallet. You keep the purse strings.

Book a demo to see Agentic Commerce Defense in action today!