How to restrict who an AI agent can pay

Amount limits decide how much an agent can lose, not where it goes. Most ways an agent is misled into paying end with a destination the attacker controls, such as an address in a document the agent read or a 'new payment details' message, so the destination is the thing to pin down. On-chain this is sharper still: a token allowance caps the amount a spender can move but says nothing about the recipient. Addresses also have traps. EVM addresses can be written in mixed or lower case and are the same address either way, so a naive string comparison can let a variant through or reject the real one.

1. List the payees you already know. Collect the addresses or accounts for the services the agent pays today. Get them from the provider directly, not from something the agent found.
2. Put them in the policy, not the prompt. Store the allowlist with the payment service so it is checked on every request. A list in the system prompt can be argued with.
3. Compare addresses canonically. For EVM addresses, compare case-insensitively so 0xabc… and 0xAbC… are treated as the same address, as they are on-chain.
4. Decide how new payees get added. Adding a recipient should be something only you can do, outside the agent's tools. If the agent needs a new payee, it should ask you.
5. Keep a human path for one-offs. If an agent occasionally needs to pay someone new, route those payments through approval rather than widening the allowlist.
6. Review the list. Remove payees you no longer use. Every entry is somewhere money can go without you.

• An allowlist doesn't check that a payee delivers. It only guarantees where the money went.
• Merchant category controls on a card are not an allowlist of payees. They narrow the kind of business, not the business.
• An empty allowlist doesn't always mean 'anyone'. Check what your service does with one; Veyra treats it differently for unattended payments, below.

• EIP-20: Token Standard (approve, allowance, transferFrom)
• ethereum.org: ERC-20 token standard
• Stripe docs: Issuing spending controls
• Veyra docs

• Token allowance (ERC-20 approve)A token allowance is the amount of an ERC-20 token that an owner has authorised a specific spender address to transfer from the owner's account, set with approve and spent with transferFrom.
• Auto-approve limitAn auto-approve limit is the largest single payment an agent may make without a person approving it, within any other caps that apply.

• Is it safe to approve a token allowance for an AI agent?What an ERC-20 allowance does and doesn't limit when it powers an agent's unattended payments, and how to size and constrain one.
• Can prompt injection make an AI agent spend money?Yes, if the agent has a payment tool and nothing outside the model checks it. How injected instructions reach a payment and which controls still hold.
• How to set spending limits for an AI agentPer-payment cap, daily cap, an auto-approve band and an ask band, enforced outside the model. How to choose each number and what happens at each edge.
• How to stop an AI agent making duplicate paymentsAgents retry when unsure, and retries can pay twice. Idempotency keys, status checks and tool wording that keep one intended payment to one payment.

All guides →