Stop Dollar Exfiltration: Operant Agent Protector now defends agentic commerce across the 3 most popular protocols - x402, MPP, and AP2

Agents can now pay for services autonomously through three open protocols moving rapidly into production.

x402, governed through the Linux Foundation, lets an agent pay for an API or MCP tool inside a standard request. MPP, introduced by Stripe and Tempo, adds session-based payment credentials across cards, stablecoins, and Lightning. AP2, from Google, 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 outcomes at once: agents that can pay freely within their task, and purse strings that tighten the moment they stray outside it.

Protection at the time of transaction

Operant Agent Protector’s Agentic Commerce Defenses evaluate 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.

‍

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.

‍