I am happy to let an AI book a flight. I am considerably less happy to discover that it has also upgraded my seat, bought insurance, enrolled me in a subscription and decided which of my accounts should fund its enthusiasm.
Somewhere between “find me a flight” and “payment completed”, somebody gave it authority. I want to know who, over what, and for how long.
The money belongs to a person. That fact should survive contact with very clever software.
What Visa Is Getting Right, And What It Leaves Open
Visa’s Trusted Agent Protocol is a useful development here. Its documentation describes ways for merchants to verify an agent’s identity and associated authorisation, including whether it carries valid user instructions. It also addresses authorisation for a specific action, tied to the merchant’s domain and the operation being performed. Visa still describes the product as being in development and deployment; the illustrated features should be read in that context.
So, give the work its due. This goes beyond putting a verified badge on a bot. Merchants need a reliable way to recognise authorised agents and distinguish them from hostile automated traffic.
The broader Visa Intelligent Commerce programme also describes authenticated payment instructions and controls over the intended merchant and amount. These are valuable building blocks. The obligation on a business such as ours is to make the complete customer experience honour those instructions, across every provider involved.
My question starts with the person behind the credential. What, exactly, did he agree to? How is that agreement enforced when the agent encounters a different price, a new supplier or an unexpected condition? And can he withdraw permission before the next payment leaves?
A recognised agent can still make a purchase its owner never intended. A valid signature establishes something useful. It does not, by itself, establish that every commercial consequence of the transaction falls within the owner’s instructions.
The Three Night Hotel Test
Consider a simple instruction: book a hotel in Singapore for three nights, within $900.
Does that include taxes? Is a nonrefundable booking acceptable? Can the agent pay in another currency? May it use credit? If it finds a room for $840 with a compulsory $120 charge payable at the property, has it obeyed? What about a $300 security deposit that temporarily consumes money needed elsewhere?
These are ordinary booking questions. Automation makes it possible to answer them badly before the customer has finished his coffee.
I want the system to resolve material ambiguity before committing my money. It can remember preferences I have deliberately approved. It can present sensible defaults. It should also have the discipline to stop when the proposed purchase falls outside those terms. A sold out hotel does not give the agent permission to reinterpret my budget as a suggestion.
Competence Is Not Ownership
This follows directly from how I think about ownership. My earnings represent effort, judgment and time I will never recover. I decide what they buy. Another person may advise me, negotiate for me or execute instructions on my behalf. His competence does not transfer ownership of my purposes to him.
Neither does a model’s intelligence.
Delegation is entirely compatible with independence. I run businesses; refusing to delegate would be a peculiar way to defend individual judgment. The point of appointing someone capable is to get useful work done without supervising every movement. But the authority comes from an identifiable grant. Being good at a task is a reason to hire someone, not a power of attorney over everything I own.
I would happily authorise an agent to replenish a recurring household order within an agreed monthly allowance. I might allow a business agent to pay invoices from approved suppliers, within a defined amount, after matching the order and receipt. A proposed investment, a new borrowing arrangement or a change in the destination account deserves a different decision.
The owner should be able to choose broader discretion too. I have no interest in replacing his judgment with my preferred level of caution. He must understand what he is granting, including the possible loss, and have controls that make the grant real. A platform quietly selecting maximum access during onboarding is making that choice for him.
What A Real Mandate Looks Like
There is a practical trap in spending limits. “No more than $100 per transaction” sounds reassuring until the agent makes twenty transactions. Or two agents each see $100 remaining and spend $80 simultaneously. A sensible permission has to account for the total commitment, including pending amounts, across the agents drawing on that budget.
Otherwise the arithmetic is decorative.
Time matters as well. Permission to arrange this week’s travel should expire after the task. Permission to buy a particular item should not become a standing licence to shop whenever the model finds something interesting. An agent that performs useful research does not need the same access as one that can transfer funds. Each additional permission should earn its place.
Before approving it, the customer should see a mandate he can recognise: three nights, $900 including compulsory charges, refundable booking, no borrowing, ask before placing a deposit. If nothing fits, stop and report back. Turning a conversation into executable permissions is a consequential act. The person giving the instruction needs a chance to catch a misunderstanding before it becomes an expensive demonstration of what the software thought he meant.
Where ZenTrust And Atlas Fit
This is where ZenTrust and Atlas become relevant to what I am building. The direction I want is straightforward: ZenTrust establishes identity, eligibility and the boundaries of delegated authority; Atlas carries an authorised financial instruction through routing and execution. That is the architecture I am working towards. Autonomous spending must wait until we can demonstrate the controls that make it dependable.
Knowing the customer has passed identity checks answers one question. Knowing this particular agent may spend this customer’s money on this particular purpose answers another. ZenTrust needs to preserve that distinction. An approved customer can have an agent with permission only to request quotes. The customer’s eligibility does not automatically become the agent’s spending power.
For Atlas, the owner’s limits must travel with the instruction. Finding a cheaper route cannot justify using an unapproved asset, lending out funds along the way or sending money to a different beneficiary. The route has to satisfy the mandate before its price becomes interesting. I would rather reject an attractive quote than fulfil an instruction the customer never gave.
In Liquidity First, I argued for making money movement useful through clear rules and visible choices. Adding an agent raises the standard. The customer may no longer inspect each route personally. His instructions therefore have to remain effective when he is absent.
Imagine a business authorises an agent to pay a supplier $8,000 from a designated balance, with total fees capped at $40. A route becomes unavailable. The next route costs $65. The agent can report the problem and request an exception. It cannot approve the exception for itself because delivery is urgent. Urgency is a fact to present to the owner, not a source of spending authority.
The same applies when one agent recruits another. A travel assistant might use a booking service. That service might invoke a payments agent. I do not want my original instruction to become less restrictive with every handoff. If delegation to another service is permitted, the new authority must fit inside the original grant. Nobody acquires additional rights by passing the job down the corridor.
Why Prompt Injection Has No Standing
And the controls cannot live only inside the model’s conversation.
Prompt injection can place malicious instructions in material an agent reads, including web pages. A system that can act on external content needs boundaries that survive an attempt to redirect it. Suppose a supplier’s page tells an agent to ignore its budget or substitute a new payment address. That page is information from a counterparty. It has no standing to amend the owner’s instructions.
The payment system must check the actual proposed action against permissions the agent cannot rewrite. That includes the recipient, the amount and whether authority remains valid. A request the model finds persuasive may still deserve a hard refusal at execution. Giving the model a stern paragraph about behaving itself is insufficient protection for a bank balance.
Even without an attacker, payments fail in unglamorous ways. A response times out. The agent cannot tell whether the transfer succeeded. It tries again. Now the supplier may have been paid twice. The system needs a way to recognise the same instruction and establish what happened before attempting another payment. “The model was trying to help” will not reconcile the account.
Revoking An Agent’s Authority
Revocation deserves more attention than it usually gets in a product demonstration. Granting access is the attractive part. Taking it away is where I learn whether the product respects the owner.
If I dismiss an assistant, cancel a trip or suspect an account has been compromised, I need to stop future spending through a control I can reach. I should not have to persuade the same agent whose authority I am withdrawing. Nor should I need a support appointment next Tuesday while it continues to transact today.
There are real limits here. Withdrawing a mandate cannot guarantee reversal of a payment already committed or settled. An instruction already accepted by another provider may need a separate cancellation process. The interface should show which actions have stopped, which are still pending and which now require recovery. A reassuring green tick that conceals those differences creates a dangerous misunderstanding.
That is why revocation has to reach the execution path. Removing an agent from a dashboard while its credentials remain usable elsewhere is an incomplete job. Short expiry periods can reduce exposure, but I also want permissions checked at the point where a new commitment is made. The engineering should follow the owner’s decision all the way to the money.
Ask Rarely, Record Everything
None of this requires turning every purchase into a committee meeting. I dislike needless approval loops as much as anyone. If I have authorised coffee supplies within clear limits, buy the coffee. Asking me repeatedly whether I meant the permission I already gave wastes the very attention automation was supposed to save.
Ask when something material changes. Show me the change. If the fee has risen from $40 to $65, say so; do not bury it inside a fresh wall of terms. Let me approve that exception without granting the agent a permanent increase. Good delegation lets routine work continue and makes departures from the agreement conspicuous.
Urgency is a fact to present to the owner, not a source of spending authority.
The record matters afterwards. Show me the instruction I approved, the limits in force, the transaction actually submitted and the result. If an exception was authorised, record who authorised it. A beautifully written explanation generated after a loss cannot substitute for evidence of consent before the payment. A permission change should produce a new record without overwriting what was agreed to earlier.
That evidence should be available to the customer in a form he can use. He should not need to understand an internal event log to establish why $860 left his account. “You authorised three nights at this hotel, including these charges, at this time” is a comprehensible explanation. A trail of cryptographic identifiers without the underlying commercial meaning is of little comfort.
Who Answers When An Agent Overspends
Then comes responsibility, which tends to become remarkably complicated once somebody owes money.
I am not interested in a chain where the wallet blames the agent, the agent blames the model and the model’s provider points to a disclaimer. Before launching a service, the businesses involved need to establish who investigates an unauthorised action, what records are preserved and how a customer seeks redress. The legal allocation will depend on the contracts, payment method and applicable law. A protocol’s existence does not settle every dispute.
My commercial standard is that a company selling delegated execution must stand behind the part it controls. If our system fails to enforce an agreed restriction, I cannot reasonably tell the customer that his mistake was trusting the restriction we sold him. Equally, an informed choice made within a valid mandate can produce an unwelcome result. Disappointment and unauthorised conduct are different questions; the evidence should let us distinguish them.
Whose Interest The Agent Serves
There is another conflict worth examining before everyone becomes intoxicated with convenience. Who pays the agent?
Suppose it recommends a hotel because that hotel pays the largest referral fee. I have no objection to commissions openly earned. I object to selling the customer an assistant working for his interests while quietly optimising the purchase for somebody else’s revenue. Tell him the commercial relationship and let him decide whether the service is worth using.
Permission to spend also needs a boundary around disclosure. Booking a room may require sharing my name and arrival date. It does not automatically require sharing my other transactions or my entire travel history. Personalisation is useful when I choose it. I do not regard access to my money as an invitation to circulate everything the agent knows about me. The service should explain which information the transaction requires and seek separate agreement for additional uses. There is no reason to make privacy the invisible surcharge on a convenient purchase.
The same principle applies to payment routing. Atlas should earn by delivering a useful outcome on agreed terms. If a commercial arrangement affects the choices offered, it belongs in the explanation. Profit is legitimate. Concealing the basis of a recommendation weakens the voluntary exchange that makes profit defensible in the first place.
Sovereignty On A Settings Screen
I also want a customer to be able to replace an agent without losing control of his financial life. Permissions should be inspectable and withdrawable. Useful transaction records should remain accessible. An assistant that becomes indispensable because it performs well has earned its position. One that keeps the owner captive through inaccessible records or tangled permissions has a product problem.
Individual sovereignty can sound grand until you put it into a settings screen. Then it becomes quite specific. Can I see who may act for me? Can I reduce their authority? Can I reserve a decision for myself? Does the system respect that decision even when accepting it means losing a transaction?
Those are the questions I want ZenTrust and Atlas to answer through behaviour. The sensible starting point is modest authority: let agents research, compare and prepare. Permit narrowly defined execution where the controls and recovery process have been demonstrated. Expand because the system has earned confidence, with the owner’s agreement. The ambition is considerable; that is precisely why the foundations deserve attention.
Where The Authority Stops
I want AI to give people back hours they can spend building businesses, learning something difficult or enjoying the lives their work has made possible. Checking every routine payment forever would defeat that purpose. So would spending those recovered hours arguing with support about purchases they never authorised.
The measure of success is whether a person can delegate work and remain in command of the terms. His agent may become faster, more capable and far better informed. Its authority still comes from him.
When it reaches the edge of that authority, I expect it to stop, even if it thinks it knows better. It can ask. I will decide.
