How an AI agent pays a new counterparty

What has to exist before the agent can pay anyone?

Four bounds, before a first payment and before a new recipient is added. The agent needs an identity tied to a verified business, not a borrowed human login. It needs a key that can pay and nothing else. It needs a funded account whose balance is the outer ceiling, with spend limits enforced in the same transaction that moves the money. And it needs a defined set of counterparties it is allowed to pay.

AI agents need accounts, not cards is the argument for that primitive. What is know your agent (KYA)? is the canonical page for the identity and authority layer. This page is the path that starts when the recipient is new.

What happens when the counterparty is new?

The agent should not be able to pay an unseen recipient by guessing an account number or a wallet address. A new counterparty goes through review first: the business is verified and screened, and only then does it become payable. On Infinite, a counterparty vetted on the network is vetted for every participant. Cases that need judgment route to human review, rather than to the agent retrying until it succeeds.

This is the same standard as a first payment a person would send, applied to software. If a raw wallet or a card is allowed to pay any address or any merchant, that path is not this one.

How does the instruction itself get checked?

Once the recipient is payable, the agent submits an instruction: amount, destination, and purpose, from the funded account. Screening and monitoring run on that instruction before funds move. If the instruction is flagged, it should stop and wait for human review, not complete because the agent is confident. Spend limits and the account balance cap what can be sent even when the instruction is otherwise fine.

Agentic commerce describes that path for agent-initiated payments. The audit record for the transfer is owned there; this page only needs the rule: the record has to name the agent, the authority it acted under, the counterparty, and the checks that passed.

What should an operator be able to do after the payment?

Retrieve it, explain it, and stop the next one if something is wrong. An operator should be able to see which agent paid, which counterparty was paid, and what was screened, without reconstructing the event from logs. Revoking an agent should mean closing or freezing that agent's account and credentials, not hunting for a card number or a leaked key. Adding the next counterparty should repeat the same review, not inherit the first recipient's approval.

Frequently asked questions