Agents That Can Pay: Gate the Wallet First

An AI agent that can browse, plan and act is a productivity story until the day it can also pay, and that day is arriving on published rails rather than in a lab. The question is no longer whether an agent will hold a payment method, but what should stand between the agent and the money before you switch it on.

The agent-payments stack has come together in public

For most of the past year, "agents that transact" was a demo. It is now a set of protocols that major payment networks and AI vendors have agreed to build against. The clearest primary marker is Google's Agent Payments Protocol, announced on 16 September 2025 and developed, in Google's words, with "more than 60 organizations" including Mastercard, American Express, PayPal, Coinbase, Adyen, Intuit, Revolut and Worldpay. When card networks, banks and an AI vendor sign up to the same way of authorising an agent's payment, the rails have stopped being hypothetical.

AP2 is built to answer three questions Google names directly: authorisation, proving a user gave an agent the authority to make a particular purchase; authenticity, letting a merchant be sure the agent's request reflects the user's true intent; and accountability, determining who is answerable if a transaction goes wrong. Reporting through mid-2026 adds a settlement-layer story too, with major payment and technology firms backing a shared, programmable dollar aimed partly at machine-to-machine transactions. Take that as direction of travel, but the direction is unmistakable: the plumbing for autonomous agents is being poured now.

What does it mean for an agent to hold a payment method?

The phrase sounds alarming, and the reassuring part is that the serious protocols do not hand an agent your card. They hand it a scoped, signed instruction.

AP2 calls these instructions mandates. When you delegate a task, you sign an intent mandate up front that, in Google's description, "specifies the rules of engagement, price limits, timing, and other conditions". When the agent assembles a purchase, your approval signs a cart mandate that creates "a secure, unchangeable record of the exact items and price". Google describes the resulting chain, from intent to cart to payment, as a "non-repudiable audit trail". So the agent never holds open-ended spending power. It holds a cryptographically signed permission that already carries a limit, a scope and a record.

That is the mental model for every vendor pitch. An agent "with a wallet" should mean one that presents a scoped, revocable, logged instruction, not one handed raw credentials and told to go shopping. If a product cannot show you the scope, the limit and the log, it has not solved the payment problem. It has hidden it.

What should gate an agent's wallet?

Strip away the branding and every scheme answers four questions, the same four an Australian finance or procurement team should answer before enabling any tool that can spend.

First, which payments may the agent initiate? Scope it by merchant, by category and by purpose, the way a corporate card already restricts where it works. An agent that reconciles invoices does not need to buy anything.

Second, what is the limit? Set a per-transaction cap and a cumulative one, because an agent making many small payments quickly is a different risk from a person making one. A limit the protocol enforces beats a limit in a policy document.

Third, whose approval is required, and above what value? This is the wallet-specific version of approval gates before autonomy: decide the threshold at which a human must sign before money moves, and keep that human in the loop by design, not good intentions.

Fourth, what gets logged? Every agent-initiated payment should leave a reviewable trail tying the spend back to the mandate that authorised it. AP2's non-repudiable audit trail is what your auditors will ask for anyway: who authorised this, to what limit, and can you prove it.

None of this is new governance. It is delegated purchasing authority and dual authorisation, applied to a non-human actor. Australia's write-access pathway under the Consumer Data Right, where a consumer authorises an accredited party to initiate actions on their behalf, is the regulated cousin of the same design. You already own the policy questions; the protocols just give you the switches to enforce them.

Prompts to draft your agent-payment policy

Use these to turn the four questions into a written position before a vendor conversation, keeping inputs generic so nothing confidential leaves your environment.

You are helping [ORGANISATION] draft an agent-payment policy before enabling any
AI tool that can initiate a payment. Our finance controls today are: corporate
card limits [DESCRIBE]; delegated purchasing authority thresholds [DESCRIBE];
dual-authorisation rule above [AMOUNT].

Produce a one-page policy covering four gates for an agent that can pay:
(1) permitted payments by merchant, category and purpose; (2) per-transaction and
cumulative spend limits; (3) the approval threshold at which a human must sign;
(4) what must be logged for every agent-initiated payment. For each gate, state
the control we already run that it maps onto. Mark anything you cannot set from
the inputs as NEEDS INPUT.

You are reviewing a vendor whose AI agent can make payments on our behalf. The
vendor claims [SUMMARISE CLAIM]. The payment method is [TOKEN / VIRTUAL CARD /
BANK TRANSFER / STABLECOIN].

Generate the questions we must ask before enabling it: how spending authority is
scoped and limited, whether the agent holds raw credentials or a signed scoped
instruction, how a payment is tied to a specific user approval, what audit trail
each transaction produces, and how authority is revoked. Flag any answer that
would leave us unable to prove who authorised a given payment.

Do this Monday

1. List every AI tool in use or under evaluation that can, or soon will, initiate a payment, including agents embedded inside software you already run.
2. Write your four gates as a one-page policy, using the first prompt: permitted payments, spend limits, approval threshold, and logging.
3. Map each gate onto an existing control, corporate card limits, delegated purchasing authority and dual authorisation, so the agent inherits rules your people already follow.
4. Set a per-transaction and a cumulative spend limit, and confirm the tool can enforce them technically, not just display them.
5. Define the value above which a human must approve before money moves, and name the role that approves.
6. Require that every agent-initiated payment is logged and tied back to the authority that permitted it, and check you could produce that trail for an auditor.
7. Put the policy in front of finance and risk before any wallet-enabled tool is switched on, and revisit it when a vendor changes how its agent pays.

A pre-enablement checklist

Work down this list before any agent that can pay goes live. Anything absent is a gate you have not built.

• Permitted payments are scoped by merchant, category and purpose, not left open.
• A per-transaction limit and a cumulative limit are set, and the tool enforces them.
• A human-approval threshold is defined, with a named approving role above it.
• The agent receives a scoped, signed instruction, not raw payment credentials.
• Every payment is logged and traceable to the specific authority that permitted it.
• Authority can be revoked quickly, and you have tested that it can.
• The policy maps to existing delegations of authority, so governance is consistent for human and agent spenders.

A worked example

A mid-sized Australian services firm pilots an AI assistant that can renew software subscriptions and pay small supplier invoices without a person completing each checkout. Read as a time-saver it is attractive. Gated properly, it is safe.

The finance lead scopes the agent to a short list of approved vendors and the software-and-subscriptions category only, so it cannot pay an arbitrary merchant. A per-transaction cap of a few hundred dollars and a monthly cumulative cap are set inside the tool, not just written down. Any payment above the cap routes to a named approver who must sign before money moves, keeping the human in the loop where it matters and out of it where it does not. Every payment is logged with the vendor, amount, timestamp and a reference to the standing authority that permitted it, with no personal card details or confidential supplier terms exposed to the model.

Nothing about that setup is exotic. It is the firm's existing purchasing policy, expressed as switches the agent must obey. The pilot proceeds because the wallet was gated first, and the gates match the ones the firm already trusts for its people.

Hype check

Two cautions. The protocols are real and backed by serious names, but agreement on a standard is not mature, battle-tested deployment, and an agent that pays inflates the blast radius of a prompt injection or a logic error from an annoyance to a debit. Do not enable a wallet because the demo was smooth. Equally, do not dismiss the shift as years away: agents that transact are shipping inside products your teams may already touch. The measured reading is that the capability is arriving fast, the controls to govern it already exist in your finance function, and the only real failure is enabling the spend before you have wired the gates.

Bottom line

Agents that can pay are moving from demonstration to published protocol, with card networks, banks and AI vendors converging on how an agent's spending authority is scoped, signed and recorded. The reassuring part is that a serious protocol gives an agent a limited, auditable mandate rather than raw credentials, and the practical part is that the four questions you must answer, which payments, what limit, whose approval, and what gets logged, are the ones your delegations of authority already answer for people. Set that policy before any wallet-enabled tool is switched on, and make the limits ones the tool enforces, not ones you merely hope it respects.