An agent that recommends a supplier changes how a purchasing decision is prepared. An agent that commits funds changes who can create a financial obligation. Before approving the second capability, a finance leader needs a clear account of whose money is being used, what authority has been delegated and which controls can stop a transaction.
Our view is that institutions should treat agent spending as a narrowly defined delegation of authority. Begin with a specific transaction class and enforce its conditions outside the model. Expand the mandate only when the evidence supports doing so. A capable assistant, a working payment API and a sufficiently controlled financial process are three different achievements.
There is now public evidence beyond hypothetical shopping journeys. In February 2026, DBS and Visa reported real-world food and beverage transactions completed by AI agents using DBS/POSB cards through secure, issuer-controlled flows. The announcement describes a joint pilot and further exploration of other transaction types. It establishes reported transaction feasibility within that setting; it supplies neither a general deployment licence nor measured institutional cost savings.
Put the mandate before the wallet
Consider an illustrative regional procurement process. A Singapore business wants an agent to buy occasional access to approved market-data services. An authorised employee can approve the purpose and budget. The agent can discover an offer and request a payment. Finance still needs to know which legal entity purchases the service, who approved the delegation and whether the supplier is eligible.
A wallet address or tokenised card credential answers only part of that problem. It identifies a destination or gives access to a payment capability. The operating record must connect the credential to an accountable principal, an approved agent instance and a current mandate. Authenticating a request does not establish that the purchase serves an approved business purpose.
Google's Agent Payments Protocol announcement, published in September 2025, describes a useful separation. An Intent Mandate records the user's instructions; a Cart Mandate records the items and price. In a human-present purchase, the user approves the cart. In a delegated purchase, the prior intent specifies conditions under which an agent may generate it. Cryptographic signatures provide evidence of the signed instructions and contents.
This is a protocol design for communicating authority. Whether a mandate binds a business, how disputes are resolved and which party bears a loss still depend on the applicable contracts, law and payment arrangements. A valid signature also leaves open whether an authorised person approved the right instructions in the first place.
For an institution, the mandate should therefore be understandable to finance before it is encoded. Define the permitted purpose, supplier set, transaction ceiling, cumulative budget, expiry and approval triggers. Decide whether the authority covers payment, ordering, contractual acceptance or all three. Paying for a service can also accept terms, create a renewal commitment or transmit sensitive information.
Distinguish assistance, approval and delegated execution
The business should be able to identify its operating level without relying on a vendor's use of the word “autonomous”.
| Operating level | Agent's permitted role | Evidence before commitment |
|---|---|---|
| Prepare | Find offers, check documents and draft a request | Source evidence and an identifiable reviewer; no payment credential available to the agent |
| Submit for approval | Assemble a specific purchase for a person to approve | Exact supplier, items, currency, total cost and relevant terms, followed by recorded approval |
| Execute within a mandate | Request an eligible purchase without individual approval | Current delegation plus independent checks of supplier, amount, budget and transaction conditions |
| Escalate an exception | Explain an unusual case and seek fresh authority | Current transaction state and reason existing authority is insufficient; no self-extension of the mandate |
These are suggested design categories, rather than regulatory classifications. They make a consequential difference: authority to assemble a payment request should not silently become authority to execute it when a product adds a new tool.
Higher autonomy need not be the objective. An agent that prepares accurate, reviewable purchases may produce useful capacity gains while final approval stays with a person. Measure that option before assuming the commercial case requires unsupervised spending.
Enforce limits at the point of action
In the procurement illustration, a prompt telling the agent to remain within budget is inadequate as a financial control. The payment service should check the proposed action against the mandate independently of the model's explanation. The model should have no authority to change its own limits or introduce an unapproved recipient.
Check the full exposure. A per-payment ceiling permits repeated payments. A cumulative budget can be exceeded if parallel requests each inspect the same available balance. The control needs to account for pending commitments, retries and fees, with a consistent rule for reserving and releasing budget. Where currencies differ, specify the conversion source and how price movements affect approval.
The signer or credential service should receive a bounded request, rather than leave reusable secrets in model-visible context. Separate the process that proposes a transaction from the service that verifies and submits it. Protect the latter with explicit access permissions and a route for revocation. This architecture is our recommendation; it is not a claim about undocumented controls in the DBS/Visa pilot.
The controls also need to survive untrusted input. A supplier page, invoice or API response may contain instructions that attempt to redirect the agent. Treat that material as transaction evidence to inspect, without giving it authority to change the mandate. Tests should include plausible supplier impersonation and instructions embedded in otherwise useful documents.
Singapore's Model AI Governance Framework for Agentic AI, launched in January 2026, recommends bounding agent powers, establishing significant human approval checkpoints and controlling access to whitelisted services. It is guidance for deployment, including third-party solutions. It should inform the design without being presented as a certification that a payment service is safe.
Preserve a financial record of the decision
A transcript of the agent's reasoning does not replace a transaction record. Operations needs a reference that connects the request, mandate, control decision, approval where required, payment instruction, provider response and ledger entry. Record the policy version and the credential or agent identity used, while restricting access to sensitive data.
That record serves different questions. Finance asks whether the payment belongs to the business and was posted correctly. Security asks whether the credential was misused. A customer or supplier may challenge the goods, price or permission. An incident team needs to distinguish a refused request from a payment that completed despite a lost response.
In its August 2026 parliamentary reply, MAS described Safeguards for Agentic Finance at Runtime as a potential approach to authorising agent actions, activating human oversight and recording consequential decisions. MAS also said its proposed AI risk-management guidelines would be finalised soon. These are the source's stated positions at that date, not grounds to call the industry framework a mandatory runtime specification.
For ASEAN operations, establish the purchaser, customer, provider and relevant jurisdiction separately for each route. A Singapore control design does not settle another market's payment-service permissions, data requirements or dispute arrangements. Obtain the necessary local interpretation before allowing transactions in that market.
Rehearse the payment that seems to have failed
One of the most consequential test cases is an ambiguous response. The agent submits an instruction, the connection times out, and the application proposes a retry. If the provider accepted the first instruction, repeating it may create another payment.
Use a stable transaction reference and provider-supported duplicate protections, then query the financial state before taking another action. Define what happens when that state cannot be established. An unresolved payment should hold the relevant budget and enter an owned exception queue; it should not disappear into a successful task summary.
Revocation needs similarly precise meaning. Disabling the agent may stop new requests while already authorised instructions remain in flight. State which commitments can still complete, who monitors them and how money can be recovered. A refund, card dispute or authorised compensating transfer follows the chosen rail's arrangements. It should not be confused with reversing a blockchain record or erasing a completed obligation.
The first approval should be small and inspectable
Before permitting agent-initiated spending, complete a delegation record with these fields: principal and approving officer; permitted transaction and suppliers; maximum pending and completed exposure; independent enforcement service; human escalation triggers; retained evidence; revocation and recovery owner; and success measures.
For the illustrative data purchase, test normal fulfilment, a higher price, a changed recipient, simultaneous requests, an expired mandate and an uncertain payment response. Measure correctly fulfilled purchases, review and exception effort, unauthorised requests blocked, and unreconciled commitments. Passing these cases supports a bounded deployment decision, not a claim of general safety.
Bring finance, technology and the process owner into that review. The useful next question is whether they can trace one completed transaction and one unresolved transaction from delegated intent to the books. If either trace is incomplete, resolve the missing authority or record before expanding what the agent may spend.
Read our editorial principles for evidence, contribution and correction standards.