Sui is exploring how AI agents can perform useful financial actions while remaining constrained by their owners. Its October 28 architecture update describes payment demonstrations and tools for defining, checking and recording authority. The central design choice is to put meaningful limits in the surrounding system, where an agent cannot simply reason its way around them.
TL;DR
- Sui described a suite of agent-control experiments on October 28.
- Its Agent Payments demonstration uses owner-defined limits on testnet.
- Revocation and delegated authority need to hold even when a model behaves unexpectedly.
A prompt is not a spending permission
The update describes an Agent Payments testnet demonstration with owner-set limits such as budgets, permitted applications and expiry. It also discusses components including Rooms, Warrant, Agent Pass and an arbiter, with several elements still in development. These should be read as work at different stages, not one finished production service.
A natural-language instruction can express intent, but it is a weak place to enforce a financial boundary. An agent might misunderstand a request, follow an untrusted document or pass work to another service. A transaction check can instead ask whether the proposed action fits an explicit permission before assets move.
For a hypothetical purchasing agent, a monthly budget of 500 units is only one constraint. The owner may also require approved recipients, a maximum per transaction and a ban on borrowing. Each rule limits a different way the agent could exceed the intended task while appearing to remain within a broad spending instruction.
Delegation needs to preserve the original limits
Sui’s security guidance discusses authority and capability patterns for applications. The broader lesson for agent systems is that possession of a permission should have a precise meaning. A component authorised to obtain a price quote should not silently acquire the ability to settle the resulting trade.
That becomes harder when one agent uses another. The second service may have its own tools and credentials, but the owner’s original restrictions still need to govern the work. Otherwise, delegation can become a route to actions the first agent was never allowed to perform directly.
An effective design would make the permitted scope explicit at each handoff. Operators should be able to see which action was authorised, which system checked it and which identity submitted the final instruction. A persuasive explanation from the model is useful context, but it cannot replace that record.
Revocation is an operational requirement
Owners also need a reliable way to stop an agent. Removing a key from a dashboard is insufficient if another service has cached authority or a pending operation can still execute under an earlier permission. The system must define when revocation takes effect and which actions remain possible afterward.
Consider an agent that has obtained approval to make a purchase but has not yet submitted the payment. If the owner revokes access during that interval, the outcome should follow an explicit rule. It should not depend on whether the agent happens to notice a new message before completing its task.
Some actions cannot be undone once completed. That makes prevention and cancellation different features. A product can block future spending while leaving an earlier valid transaction intact, and its interface should explain that distinction without implying that revocation reverses settled transfers.
Atomic execution has a defined boundary
Combining several onchain steps into one transaction can prevent a partial result within that transaction’s scope. It does not prove that an offchain service delivered what was purchased or that an external data source reported the truth. Agent systems still need a way to handle those dependencies and disputes.
For developers, the strongest demonstrations will therefore include failures as well as successful purchases: an expired permission, an unavailable service, a changed price and an attempted action outside the mandate. Those cases reveal whether limits are enforced by the infrastructure or merely respected by a cooperative model.
Sui’s work makes the boundary between reasoning and authority visible. If that boundary holds through delegation, revocation and unexpected inputs, agents can become useful participants in blockchain applications without requiring owners to grant them unrestricted control over an account.
Written by the News Desk and edited by Samuel Rae.
Leave a Reply