AI agents are moving closer to money.
They can already compare suppliers, prepare purchase requests, reconcile invoices, draft payment instructions and chase approvals. The next step is obvious: let the agent initiate the transaction.
That is also where a useful digital coworker can become an unmanaged financial actor.
Fortune reported a new compliance question for banks: “know your agent.” The issue is not only whether an AI can complete a payment task. It is whether the payment network can identify the agent, identify who it belongs to and prove who authorized it. Ant International, Mastercard and Visa are collaborating on an interoperability framework through BuildFin.ai, an industry platform convened by the Monetary Authority of Singapore.[1]
This is an emerging collaboration, not an adopted industry standard. But the operating question is already relevant to every SME connecting AI to procurement, ERP, CRM or finance systems:
Before an agent can influence or move money, can you prove who it is, what it may do and who remains accountable?
A user account is not enough
Most companies control software access through user accounts and roles. That works reasonably well when a human logs in, makes a decision and clicks the button.
An agent changes the sequence.
It may collect context from several systems, interpret a policy, decide which action fits, call a tool and continue working while the owner is doing something else. The same instruction can also produce different reasoning paths because the system is probabilistic, while the payment rail still expects a deterministic result: an approved amount goes to an approved party through an accountable process. Fortune highlights this tension between adaptive agents and transaction infrastructure built around predictable rules and clear accountability.[1]
Giving the agent a shared finance login does not solve that problem. It removes the very evidence the company will need when something goes wrong.
The agent needs its own operating identity.
The agent passport
Think of an agent passport as the employment record and delegated-authority document for a digital coworker. It is not a replacement for KYC, legal accountability, payment controls or maker-checker approval. It makes those controls usable when software is doing the preparation and execution.
A practical passport should contain nine fields.
1. Named human owner
Every agent needs one accountable business owner. Not “the AI team.” Not “finance.” A named person must own the outcome, review exceptions and decide whether the agent keeps its authority.
2. Business role
Describe the job in operational terms.
Good: “Prepare approved supplier payments from matched purchase orders and invoices.”
Bad: “Help with finance.”
A narrow role makes permissions, testing and audit review much easier.
3. Permitted systems
List the systems the agent may access, such as the procurement portal, ERP invoice module or bank-payment sandbox. Access should not silently expand because a new connector becomes available.
4. Transaction scope
Define what the agent may do inside those systems. Reading an invoice, drafting a payment batch, creating a purchase request and releasing funds are different verbs with different consequences.
This is where many automation projects become unsafe: access to a system is mistaken for permission to perform every action in it.
5. Spending limit
Set a hard ceiling per transaction and, where useful, per day or month. The limit should be enforced by a deterministic control outside the model’s reasoning.
An instruction saying “do not exceed $5,000” is guidance. A payment control that rejects $5,001 is a boundary.
6. Approval threshold
Specify when a human must intervene. The rule may depend on amount, supplier status, payment destination, category, confidence score or exception type.
For example:
- existing supplier, matched documents, below $500: prepare and queue;
- $500–$5,000: named manager approval;
- new supplier or changed bank details: finance approval regardless of amount;
- policy conflict or missing evidence: stop and escalate.
The model can assess context. The approval engine should enforce the decision rights.
7. Expiry
Authority should expire. A project agent may need access for 30 days. A recurring accounts-payable agent may require quarterly recertification. Permanent credentials create permanent exposure.
8. Revocation mechanism
The owner must be able to stop the agent quickly without redesigning the workflow. Revocation should disable its credentials, tool access and pending actions—not merely remove it from a dashboard.
9. Audit trail
Record the source documents, data retrieved, tools called, policy checks, proposed action, approvals, final transaction reference and any later reversal.
The goal is not to archive every hidden reasoning token. The goal is to reconstruct the business decision: what happened, under whose authority, using which evidence and through which controls.
Put deterministic rails around probabilistic workers
The right design is not to make the agent deterministic. That would remove much of the judgment and flexibility that makes it useful.
The right design is to place deterministic boundaries around the agent.
Let the agent read an invoice, compare it with the purchase order, identify a mismatch and recommend the next step. But let policy code decide whether the amount is within scope. Let the ERP confirm whether the supplier is approved. Let the payment platform enforce maker-checker approval. Let the audit log record the final state.
The agent handles ambiguity. The control layer handles authority.
This is the same management principle used for human teams. A capable employee does not receive unlimited authority because they are intelligent. They receive a role, access, limits, approvals and accountability. Digital coworkers should be managed with at least the same discipline.
Start with the agents that can influence spending
Do not begin with a company-wide governance programme. Begin with an inventory.
List every agent that can initiate, approve or influence spending. Include agents that only recommend suppliers, change purchase quantities, prepare payment batches or draft customer credits. Financial influence starts before money moves.
Then assign each agent a named human owner and complete the passport fields.
You will quickly find one of three things:
- the agent has more access than its job requires;
- the approval boundary exists only in a prompt;
- nobody is clearly accountable for revoking it.
Fix those gaps before granting more autonomy.
The question is no longer whether an AI agent can participate in a payment workflow. It can.
The operator’s question is whether the business can identify that agent, constrain its authority and prove who approved the outcome.
Orchestrate the work. Do not outsource accountability.