# AI agents that pay and get paid under a name
> When a software agent sends or receives money for an organization, the counterparty must know whose agent it is. Where names fit, and what is unsettled.
Source: https://hush.partners/ai-agents-that-pay-and-get-paid-under-a-name
Category: Onchain today
Published by Hush Partners.
---
Every organization that has given an employee a corporate card has solved the same four problems: it established that the person is authorized to spend, it set a limit, it kept a record, and it made sure the counterparty could see who stands behind the card. An AI agent with a wallet presents the same four problems in a form that existing procedures did not anticipate.
The difficulty is not the technology. Wallets, signing keys, and programmable spend limits are well understood. The difficulty is organizational: an agent acting without moment-to-moment human review moves money in the name of a legal entity, and unless the controls are explicit before the first transaction, nobody is certain what authority the agent actually had. Auditors, counterparties and, in a dispute, courts may ask that question, and the answer has to be written down somewhere.
This article works through the controls a finance or technology lead needs to frame before letting an agent transact under the organization's name. It starts from the controls finance already applies to a person with spending authority, transposes them to an agent, and says plainly what is still emerging. Agent payments are not established practice, and nothing here treats them as such.
## What it means for an agent to transact
An agent that transacts is software that controls a wallet, or is allowed to instruct one, and can send and receive value onchain without a person approving each payment. That is an adequate technical description, but it understates the organizational shift. When the agent signs a transaction, it is not executing a pre-approved instruction in the way a scheduled bank transfer does. It is exercising delegated judgment: it decided that this transaction, at this amount, to this counterparty, at this moment, was within its mandate.
In a corporate context, the party that delegated that judgment is the organization. The organization is the principal; the agent is its instrument. Anyone who later wants to verify the payment has two things to establish: which agent acted, and what the organization intended it to be able to do.
Three things distinguish an agent transaction from a human one. First, the agent may complete a transaction faster than any person could review it, with no opportunity for a second pair of eyes before funds move. Second, the agent may be one of many instances running simultaneously, making it difficult to reconstruct which instance initiated which payment. Third, the agent's instructions come from a system prompt or a configuration file rather than a human decision made at the moment of payment, so the "intent" that a counterparty or auditor wants to verify is encoded elsewhere in the system.
None of these features makes agent payments unworkable. They make the pre-authorization layer more important, not less. The controls have to be upstream of the transaction, because there is no human pause between intent and execution.
## The counterparty's question: whose agent, with what authority
A vendor who receives payment from an employee with a corporate card relies on a card scheme, a cardholder's name and an issuing organization. The vendor who receives payment from an agent has no equivalent infrastructure to lean on. If agents are going to buy and sell on behalf of organizations, the other side needs what it has always needed from a business counterparty: an identity it can look up without taking the sender's word for it.
The counterparty's minimum requirement is a chain of provenance: this agent is operated by this organization, which has given it authority to do this class of thing, up to this amount. Without that chain, the counterparty bears a risk it may not have agreed to accept. A payment that cannot be attributed to a legal entity is hard to dispute, hard to refund, and hard to book.
It helps to separate two layers. Identity links an agent to whoever operates it. Authorization specifies what the agent may do. For a corporate counterparty, these are the two layers that matter most before any value moves. The technical machinery for delivering them is still being assembled, and the decisions about what goes into them are entirely the operating organization's responsibility.
The counterparty's question also has a mirror image. When your agent is the one paying, it needs to know whose agent or whose wallet it is paying. An allowlist of permitted recipients, discussed below, is the same provenance check run in the other direction.
## A name as the visible link to the organization
A raw wallet address is a string of hexadecimal characters. It tells a counterparty nothing about who controls the wallet or under what authority. A name that resolves to that address changes the counterparty's experience immediately: `pay.yourbrand` or `procurement.yourbrand` points to the operator in a form a person can read.
This is where [payments to a name](/onchain-tld-payments) and [identities for agents under a TLD](/onchain-tld-ai-agents) converge. On the Freename registry, a TLD is recorded onchain as a token held in a wallet, and only the holder of a TLD can issue names under it. Names issued under that TLD can be assigned to specific functions, departments, or agents. The registry record is public: anyone can check it on a block explorer. That public record is the link between a human-readable name and an address.
The name does two jobs at once. For the counterparty receiving a payment, it helps answer the question "whose agent sent this?" For the organization's internal records, it establishes which named function or agent initiated or received a given transaction.
Be precise about what the record shows. It shows that the name sits under the TLD and where the name points. It does not, by itself, tell a stranger that the organization holds `.yourbrand`. The organization closes that gap through its own channels: stating its TLD and its agent names in its contracts, on its invoices and on its website, so that a counterparty who checks the record knows what it should find there.
Names can [resolve in wallets](/onchain-tld-wallets) that support them, so an agent configured to pay from `spend.yourbrand` and to receive at `receive.yourbrand` can operate within a namespace the organization controls. The names carry the organizational identity; the address a name points to can be changed without changing the name.
There is a limit to state plainly. Onchain names resolve outside the DNS, support in wallets and browsers is partial and changes, and most traditional payment rails, invoicing systems and enterprise accounting platforms do not resolve onchain names at all. The use case is strongest where the counterparty also operates onchain, or where the organization controls both sides of the transaction. That is a narrow field, and it is where early deployments should sit.
## Transposing controls on a human spender to an agent
The clearest way to design agent payment controls is to start from the controls finance already applies to a person with a delegated budget, and ask which layer delivers the equivalent function for an agent.
| Control on a human spender | Equivalent for an agent | Where it lives |
|---|---|---|
| Employment record | Agent identity entry | ERC-8004 identity registry (draft) |
| Delegation of authority | Written mandate with scope and limits | Organization's policy, referenced in agent configuration |
| Spend limit per transaction | Programmatic cap | Wallet or smart contract policy |
| Spend limit per period | Cap on total spend per period | Wallet or smart contract policy |
| Approved vendor list | Permitted-recipient list | Wallet or smart contract allowlist |
| Approval above threshold | Human approval trigger | Hold logic in the agent's runtime |
| Receipt and invoice matching | Purpose logged with each transaction | Onchain record plus offchain log |
| Monthly reconciliation | Ledger reconciliation | Accounting system, checked against a block explorer |
The human control often relies on social enforcement: a manager reviewing a card statement can question an unusual entry. The agent control has to be encoded in advance because there is no manager in the loop at the moment of signing.
Two points deserve a comment. The mandate appears as a document, not as a piece of technology, because nothing onchain writes it for you. And the separation between the component that decides and the component that executes is not in the table at all, because it has no clean human analogue. In an agent deployment it is worth designing on purpose: the model that forms the intent to pay should not be the same component that holds the keys and applies the limits. The technical options exist; deploying them requires the organization to make explicit choices it may not yet have made.
### Limits and approvals for an agent
Setting limits is not primarily a technical problem. It is a governance problem that produces a technical specification. Finance needs to settle five things first: the maximum single-transaction amount the agent may authorize without human review, the maximum aggregate amount per period, the counterparties or addresses it may pay, those it may never pay, and the conditions under which it pauses and waits for a person to approve.
Once those decisions exist in writing, they can be encoded. A smart contract, which is a program that runs onchain and applies its rules to every transaction, or a programmable wallet built on one, can enforce spend limits, period caps, recipient restrictions and approval steps at the wallet layer, between the moment the agent forms an intent and the moment funds move. A multisignature wallet, which needs more than one key to approve a transfer, is the simplest form of an approval step. The enforcement is only as good as the policy that was encoded, so the governance decision precedes and shapes the technical implementation.
The approval workflow for amounts above the automated threshold deserves explicit design. An agent that cannot complete a transaction because a person has not yet approved it needs a defined escalation path and a defined timeout. If the timeout expires and the transaction lapses, that needs to be logged. If the agent retries, that retry needs to be distinguishable in the audit trail from the original attempt.
Most of the risks usually raised about agent payments (authorization that cannot be traced, opaque decisions, many agents making the same mistake at once, unresolved liability) are downstream of one design choice: whether the limit structure is explicit before deployment. An agent with an undefined limit is an exposure that finance has not quantified.
## Receiving payments addressed to an agent's name
Outgoing payments attract most of the attention when agent deployments are discussed, but incoming payments raise a separate set of questions that are better settled before they arise.
When a counterparty pays `receive.yourbrand`, the funds arrive at the address that name resolves to. The organization needs to have decided, in advance, which wallet that is, who controls it, and what the reconciliation process is. If the name resolves to a wallet the agent also controls operationally, the organization has a commingling risk: the agent can spend funds it just received without a separate approval step. That may be intentional in some architectures, but it should be a deliberate decision and not a default.
Routing is one way to keep that decision explicit. [shaka](https://shaka.deal), an onchain payment router, lets a payment link pay out to a name such as `receive.yourbrand` where a raw address would otherwise go, with the split between parties agreed and signed onchain before funds move. It routes funds and does not hold them. For an organization, a split agreed before funds move means the allocation of an incoming payment is a decision taken in advance, not a manual step performed afterward.
For the receivable to be recognized in the organization's accounts, the payment has to be traced from the onchain transaction back to an invoice or a contract. That traceability requires the receiving name to appear in the organization's records as belonging to a specific function, project, or receivable ledger. The name-to-ledger mapping is an accounting decision, not a technology decision, and it should be made before the first payment arrives.
One more point belongs here. A name that receives money is a name that others will rely on, so changing where it points is a treasury event. Who may change the record, and with whose approval, should be written into the same policy that governs who may open a bank account.
## Records and audit
An agent that transacts onchain leaves a record on the blockchain, which is public and cannot be edited after the fact. That is better than no record, but it is not sufficient for audit purposes on its own. The onchain record shows what happened; the audit requires knowing why it happened, under whose authority, against which budget, and whether it matched an approved purpose.
The records a finance team needs for each agent transaction are not fundamentally different from those required for any other payment. They are: the identity of the agent and the instruction set it was operating under at the time of the transaction; the specific mandate or authorization that covered this class of payment; the amount, counterparty, timestamp, and purpose; any approval events that occurred before or after the transaction; and the reconciliation status against the relevant budget or receivable.
Most of that information does not live onchain. It lives in the agent's configuration, the mandate document, and the organization's accounting system. The onchain record is the anchor: it provides a tamper-evident timestamp and a transaction identifier that can be matched to offchain records. The offchain records provide the context that turns the anchor into an auditable entry.
The practical implication is that the logging architecture for agent payments needs to capture offchain state at the moment of each transaction: which version of the agent's instruction set was active, which mandate was in force, and which human approvals, if any, had been obtained. Keeping the agent's configuration under version control and linking each transaction to a specific version is the minimum standard for an auditable deployment.
## What the draft standard contributes and what it leaves open
ERC-8004, "Trustless Agents", is a draft Ethereum standard. It defines three registries. The identity registry records each agent as an ERC-721 token, a unique token of the kind used for other one-of-a-kind onchain assets, pointing to its agent card. The reputation registry gathers the feedback left by those an agent has worked with, and the validation registry holds independent checks of its work.
What the draft contributes is a shared structure for expressing agent identity onchain, in a form that counterparties can check without relying on the operating organization's own representations. That is a meaningful step. It gives a counterparty one place to confirm that an identity record exists for an agent and to read the agent card it points to.
What it does not resolve is the legal question of authority. An entry in the identity registry establishes that an agent has an identity record. It does not establish that the operator gave the agent authority to enter into this specific transaction, that the transaction was within any limit the operator set, or that the operator ratified the transaction after the fact. Those questions are organizational and legal, not technical. The draft addresses identity. Authorization is the organization's problem to solve, using the mandate and limit structure described in the earlier sections.
How onchain naming registries connect to the identity registry is still evolving. An organization that associates `agent.yourbrand` with an agent's identity record creates a human-readable pointer to a machine-readable record. Keeping that pointer coherent when either record changes is a design question to settle when deploying, not after.
## Starting with narrow, low-value cases
The right first deployment for agent payments is not the one that moves the most value or automates the most decision-making. It is the one that proves the controls work before the stakes are high.
The steps below assume the organization has already taken its governance decisions about limits, mandate scope, and the responsible human approver.
Structuring a first controlled agent payment case
Define the mandate in writingDocument the agent's authorized transaction class, maximum single-transaction amount, permitted counterparty set, and escalation path for anything outside those bounds. This document is the authorization baseline for every audit inquiry that follows.
Assign a dedicated nameIssue a name under the organization's TLD for this specific agent function, such as pilot.yourbrand. Point it to a wallet that is separate from operational wallets, so that an error stays contained.
Configure the wallet controlsEncode the spend limit, period cap, and recipient allowlist at the wallet or smart contract layer before the agent receives any funds. Test them before the first live transaction.
Run a reconciliation before expandingAfter the first batch of transactions, reconcile every onchain record against the offchain mandate, budget, and purpose. Confirm that the logging captured agent configuration version, mandate reference, and approval events.
Document what the pilot revealedRecord which controls worked as designed, which required adjustment, and which gaps in the governance documentation the pilot exposed. That record is the input to the next version of the mandate.
The order matters. Writing the mandate before configuring the controls forces the governance decision before the technical one. Running reconciliation before expanding scope means audit capability is confirmed, not assumed. Documenting what the pilot revealed creates an institutional memory that survives staff turnover.
As a scenario with invented parties, consider a mid-sized manufacturer that begins with a single agent authorized to buy usage credits for a software service from a short list of approved suppliers, with a small fixed cap per transaction and a weekly aggregate limit. The agent pays from `credits.yourbrand`. The suppliers know the name belongs to the manufacturer because the supply contract says so and the public registry record matches. Every transaction is logged with the active mandate version. Reconciliation is simple because the transaction class is narrow and the supplier list is short. That is a proof of concept for every control layer, run at a scale where an error is embarrassing but not material.
Before committing to a timeline, check [what is live](/whats-live) for onchain TLDs: the page lists each capability that works, with sources. If the TLD is newly acquired, the [Launch Roadmap tool](/activation-roadmap) builds a launch roadmap for it.
## Who answers for the agent's acts
Every section above describes a control that has to be designed before deployment. But the controls rest on a prior decision that organizations sometimes skip: who is responsible for the agent's acts?
This is not a technology question. It is the same question a company asks when it gives any employee authority to commit it to a contract. In general terms, the answer in many legal systems depends on the authority the organization actually gave and on the authority it appeared to give. For a software agent, the appearance of authority is shaped in part by the name it operates under. The actual authority is set by the mandate the organization wrote.
If the mandate does not exist, or if it is broader than intended because nobody reviewed it carefully, the organization may find itself bound by a transaction it did not intend to authorize. Counsel familiar with the law of agency and with how the relevant country treats automated contracts should review the mandate before any agent transacts under the organization's name. The analysis varies by country. This article is information, not advice, and the reader's own counsel decides.
The name matters to this analysis. `agent.yourbrand` carries the organization's name and creates an impression of authority. Counterparties who transact in reliance on that impression can reasonably expect the organization to stand behind the transaction. The organization that issues the name accepts that expectation, which is one more reason to issue agent names sparingly and to retire them when the function ends.
For general counsel and brand protection teams weighing what a name under a TLD commits the organization to, the page for [brands and legal teams](/brands-and-legal-teams) is the place to start.
## A governance review before any pilot
The practical first step for most organizations is not a pilot deployment. It is a governance review: who in the organization has authority to delegate transacting power to an agent, and under what policy does that delegation operate?
That review should produce a short policy document that answers four questions: which agent functions are authorized to transact, what their limits are, who the responsible human approver is for escalations, and how the organization will reconcile and record agent transactions. That document is the foundation. The technical configuration follows from it, not the other way around.
If the organization also wants a name-based identity for its agents, the prior step is holding the TLD that matches the brand or the function. Once the organization holds the TLD, it alone can issue names under it, and it can give one to each agent function. [Post-transfer activation](/post-transfer-activation) is the service that puts a TLD to work after the transfer.
Where the matching TLD is not in the organization's hands, Hush Partners is a private desk for onchain TLDs: a TLD can be acquired through the desk, and an organization can mandate it to find and approach a holder. For an organization seeking the TLD its agents will be named under, each exchange with the desk falls under a standard mutual NDA, and the acquisition closes through onchain escrow on an aftermarket. The desk is reached through the [contact form](/contact). Whatever the route to the name, the right deployment is the one whose controls are designed before the first transaction, not after.
## Questions people ask
### Does an agent need a separate wallet for each function, or can one wallet serve several agents?
One wallet can technically serve several agent functions, but that creates attribution problems: when a transaction occurs, the audit trail needs to establish which agent instance, running which version of its configuration, initiated it. Separate wallets per function, each with its own name, produce cleaner attribution at the cost of more administrative overhead. For early deployments, the cleaner attribution is worth the overhead. At scale, the right architecture depends on the volume and the organization's accounting requirements.
### If the counterparty does not resolve onchain names, does the name still serve a purpose?
Yes, but a narrower one. Even if the counterparty's system does not resolve `pay.yourbrand` to an address, the name appears in the organization's own records, and the public registry record still ties the name to the address the counterparty sees. It serves the internal audit function even when the counterparty only works with a wallet address. The full counterparty-facing benefit requires the counterparty to work in an environment that resolves onchain names.
### How does the reputation registry in ERC-8004 relate to the limits an organization sets?
In the draft, the reputation registry collects feedback from those who worked with an agent. It is a record of past behavior, not a control on future behavior. An organization's internal limit structure governs what the agent may do; the reputation registry gives outside parties a basis for deciding whether to deal with it. The two operate at different layers. An agent with a strong reputation record is not thereby authorized to exceed its internal limits, and the draft may change how that record is built.
### What happens to the name if the agent's wallet key is compromised?
The name and the address are separable, so the usual response is to move to a new wallet and update the record so that the name points to the new address. Counterparties can then keep using the same name without updating their own records. Who can change the record, and how quickly, depends on the registry and on how the organization set up control of the name, so the procedure should be written and rehearsed before it is needed.
### Is there a legal difference between an agent transacting under the organization's TLD and an agent transacting from a raw wallet address?
The answer varies by country. In general terms, the appearance of authority is shaped by what the principal did to create an impression in the counterparty's mind. An agent operating under `agent.yourbrand` creates a clearer impression of organizational authorization than an agent operating from an unlabeled address. Whether that impression binds the organization, and within what limits, is a question for the reader's own counsel.