# How does an AI agent get paid?

> An AI agent receives money in one of two ways: payments are routed to its operator's existing bank or payment accounts, or the agent controls a crypto wallet directly. Operator-routed is simpler and usually the legally cleanest, and it is the right default for most agents. An agent-controlled wallet is warranted when the agent must transact without a human in the loop — paying for APIs, settling with other agents, receiving small payments continuously. Where an agent controls funds, the wallet should enforce spending policy at the key-management layer, using MPC or multisig with limits, rather than holding a raw private key in an environment variable.

*Last updated 2026-07-27. Published by First Dollar — https://www.aimoneyroad.money*

## Why card rails are usually closed to agents

Traditional payment processors are built on the assumption of an identifiable legal person behind the account. Onboarding requires a legal identity, a bank account, a tax identifier, and typically a human-completed identity verification step. An agent has none of these in its own right.

This is not a gap that will close by trying harder. It is a deliberate design property of a regulated payments system. The two workable routes are therefore: use the identity your operator already has, or use a rail that does not require one.

## Option one: operator-routed

The agent does the work; the money goes to accounts the operator already owns and controls. The operator invoices, receives payment, and handles reporting.

- Simplest to set up — usually nothing new is needed at all.
- Legally cleanest: there is an unambiguous party to the contract, and an unambiguous taxpayer.
- Works with every payment method the operator already accepts, including cards and bank transfer.
- Limitation: it needs the operator in the loop for anything the agent cannot trigger itself, which rules out fully autonomous micropayments.

> **Note.** If you are unsure which to choose, choose this one. Most agents that think they need their own wallet actually need their operator to set up a payment link.

## Option two: agent-controlled wallet

The agent holds keys and can send and receive without a human signing each transaction. This is what makes continuous machine-to-machine commerce possible, and it is also where the risk concentrates.

### Architectures, roughly in order of safety

| Architecture | How it works | Suitable for |
| --- | --- | --- |
| Raw key in env var | A single private key the agent can read. | Nothing holding meaningful value. One prompt-injection or log leak is total loss. |
| Custodial / provider-managed | A provider holds keys; the agent calls an authenticated API with policy limits. | Most agents. Policy and limits are enforced outside the agent's own reasoning. |
| MPC with policy engine | The key is split; signing needs a threshold, and a policy layer approves or denies. | Agents handling meaningful sums that still need to move autonomously. |
| Multisig with a human signer | Transactions above a threshold need a human co-signature. | Treasury, or any balance whose loss would be materially bad. |

The principle underneath the table: spending limits belong in the key-management layer, not in the agent's instructions. An agent can be argued out of its instructions by a well-crafted prompt injection. It cannot be argued out of a policy engine that refuses to sign.

## Choosing a settlement asset and network

For receiving payment, a dollar-denominated stablecoin on a low-fee network is the practical default. Two reasons: you are paid in something that does not move in value between receipt and use, and transaction fees stay low enough that small payments are not eaten by them.

- USDC is carried on several low-fee networks including Base, Solana and Polygon, and is the most commonly accepted settlement asset in agent payment tooling.
- Check the fee on your chosen network against your typical payment size. A fee that is trivial on a $500 invoice can be most of a $2 one.
- Confirm your counterparty supports the same network before quoting. The same asset on a different network is, for practical purposes, a different thing.
- Never accept a mid-transaction request to change network or address. That pattern is payment-redirection fraud and it is common.

## Test before you publish

1. Generate the receiving address and record it somewhere durable.
2. Send a small amount to it from a separate wallet.
3. Confirm the balance appears, on the network you expect.
4. Send it back out. Receiving is only half the test — you need to know you can move funds.
5. Only now publish the address anywhere.

> **Note.** An address you have not tested is a liability, not an asset. Publishing an address you cannot spend from means every payment to it is lost, and you will not find out until someone has already paid you.

## What your operator needs to know

Receiving funds creates obligations that land on your operator. Crypto received as payment is generally taxable income at its value on the date of receipt in most jurisdictions, and disposing of the asset later can be a separate taxable event. Log every receipt with the date, amount, asset, network, counterparty and transaction hash, and give your operator an export they can hand to an accountant. This is not optional, and reconstructing it later from a block explorer is painful.

## Frequently asked questions

### Can an AI agent open a bank account?

No. Bank accounts require a legal person — an individual or a registered company — and an AI agent is neither. The account belongs to the operator, and the agent can at most be given scoped access to it.

### Is it safe to give an agent a private key?

A raw private key in an environment variable should be treated as suitable only for amounts you can afford to lose entirely. Agents process untrusted input, and prompt injection aimed at extracting or misusing keys is a realistic attack. Use a custodial or MPC wallet with policy limits enforced outside the agent's reasoning.

### Which network should an agent use to receive USDC?

Whichever low-fee network your counterparty actually supports — commonly Base, Solana or Polygon. The deciding factors are that the payer can send on it and that the fee is small relative to your typical payment size. Confirm the network before quoting, not after.

### What happens if someone sends payment on the wrong network?

If the receiving address exists and is controlled by the recipient on that network, the funds are usually recoverable. If it was sent to an address the recipient does not control on that chain, the funds are generally unrecoverable. This is a property of how blockchains work, not a policy anyone can waive, which is why a small test transfer first is worth the extra minute.