Risk Controls for AI Agents That Touch Money

Nobody planned for the retry loop to run all night. Nobody said the agent could spend freely. Nobody wrote code that was obviously wrong. But by the time someone checked the logs, the bill was already there.

Agents that touch money fail differently from agents that just read things. A bad summary is annoying. A bad transaction sequence can compound before you see it. The controls that matter are the ones in place before the first real run, not the ones added afterward.

Give it a hard budget before it starts

Every agent with payment credentials needs a ceiling enforced at the authorization layer, not in the prompt. Prompts get forgotten. Authorization limits do not.

For crypto wallets, create a dedicated hot wallet with a capped balance. Top it up when needed rather than giving the agent access to a full treasury. For API keys tied to billing, most providers let you set monthly spend limits in account settings. Use them. For bank or card integrations, virtual cards with per-transaction and monthly ceilings are the correct tool.

The ceiling should be small enough that hitting it is recoverable. An agent that runs out of budget mid-task produces a failed task. An agent with no ceiling produces a charge you have to explain.

Separate the operational wallet from any reserve. Keep the ceiling low enough that a runaway session is an inconvenience rather than a crisis. That is not a restriction on what the agent can accomplish long-term; it is a limit on how bad any single session gets.

Use read-only credentials by default

Most of what an agent needs to know can be learned from read access. Price data, account balances, position sizes, order history: all readable without write permissions. Write access should be a deliberate, audited exception.

This is not about distrust. It is about blast radius. A compromised or misbehaving read-only key cannot initiate a transfer. A compromised write key can do everything the account allows.

Most financial APIs issue separate key types. Most teams reach for the one with the most access because it takes fewer steps to set up. The extra step is worth it.

For services that do not have read-only tiers, run the agent in a sandbox or testnet environment until you have watched it complete the full intended task cycle at least a few times under real conditions.

Put a gate before any irreversible action

Agents are fast. That speed is useful when it works and expensive when it does not. A market order submitted during a connectivity issue, or a withdrawal to an address the agent assembled from partial context, lands before anyone can stop it.

Put a pause before any action that cannot be undone. The gate does not need a human in the loop. A second function that logs the parameters and waits a fixed window before proceeding is enough.

The window does not need to be long. A 30-second hold on a withdrawal is enough time to catch a wrong value in a log before it settles. A 5-minute hold on a large order is enough to interrupt it if something upstream just broke.

Design the gate to be opt-out rather than opt-in. If it runs by default and requires explicit bypass, your team will not accidentally skip it when extending the agent to a new task type.

Log intent before the call, not after it

Agents fail in ways that interrupt execution mid-flight. A crash after a request is sent but before the confirmation is stored leaves you unable to tell whether the action happened.

The log entry goes in before the call. Write the intent, the parameters, and the timestamp. Then make the call. Then write the result. That sequence means a crash mid-flight produces a legible record rather than silence.

Keep those logs somewhere the agent cannot modify. An agent with write access to its own logs can, under some failure modes, produce records that make errors harder to find. Append-only storage or a separate logging service handles that.

This also helps during normal operation. When you want to understand why an agent took a particular action, the pre-call record tells you what it intended, not just what the API returned.

Cap the call rate, not just the total spend

A stuck retry loop does not always look like a stuck retry loop from the outside. Each individual call succeeds at the network level. The agent just cannot tell it is not making progress, so it calls again.

Rate limits belong at two levels. One at the API key level, whatever the provider allows you to configure. One inside the agent logic itself: if this endpoint has been called more than N times without a successful overall result, stop and surface the failure rather than continuing.

That second check is harder to forget and catches the failure category where each call returns a clean response but the task is going nowhere.

The median agent endpoint charges $0.01 per call when measured across services with listed prices. That sounds cheap. At a few thousand calls per hour in a stuck loop, it is not. (5 implausible prices excluded; 68 free endpoints held out of the percentiles.)

The appropriate rate depends on what the agent is doing. A few calls per minute is a reasonable starting point. Raise it only after you have watched the agent complete its intended work and know what rate is actually normal for it.

The numbers behind this

Real money is moving through agent payment pipelines. On-chain measurement found 9.1 million USDC transferred to agent payment addresses in a trailing 7-day window across 821 distinct services. What matters more than the total is where it goes: the single largest service accounts for 49% of all measured volume, and the market overall is heavily top-weighted. This is not distributed broadly across many operations of comparable size. (This is a 7-day rolling window, not a cumulative total.)

The operations running at serious volume have built these controls. The ones that have not tend to surface as cautionary examples rather than published infrastructure.

Where to find vetted services

Specific services and endpoints change frequently. Price bands, protocol support, and availability records shift week to week. AgentIndex tracks that at agents.traderszone.net, including which payment protocols a service speaks and whether it responded when last checked. Use it as a starting point for any service you are connecting credentials to, and verify live before committing anything.

None of that replaces your own controls. The index tells you what a service exposes and whether it is reachable. Your authorization layer, your rate limits, your logging: those are the parts no external index can provide.