Sui Foundation Mandates System-Enforced Spending Limits For AI Agents

The Sui Foundation published a design note on October 28 arguing that artificial intelligence agents require permissions enforced by the systems they use, rather than relying solely on instructions the agents are expected to remember. The document outlines a framework for managing spending limits and delegation using onchain atomic transactions and verifiable records.

The note addresses the tension between granting an agent enough authority to complete tasks without constant approval and maintaining boundaries that remain effective if the agent misunderstands an instruction or encounters misleading information. The Foundation describes the publication as an analytical framework for building safer workflows, not an announcement that all AI agents operating on the Sui blockchain have become reliable.

Permissions Versus Instructions

The design note distinguishes between telling software to stay within a limit and providing it with credentials that technically cannot authorize a payment above that limit. The first approach depends on the agent correctly interpreting and following the rule. The second approach allows the system to reject an action even if the agent makes a mistake.

According to the note, effective deployment requires both a sensible objective and a mechanism that constrains execution. The document emphasizes the need for shared terms and verifiable records when multiple organizations participate in a workflow. This ensures that boundaries are enforced by the infrastructure rather than existing only as guidelines within the agent’s programming.

Atomic Transactions and Delegation

Sui’s programmable transaction documentation describes how multiple commands can be grouped so their state changes apply together. If a command within a grouped transaction fails, the group does not leave the intended asset changes half-completed. For automated workflows, this helps when several onchain steps depend on each other, such as a purchase and the subsequent movement of the acquired asset, which can be evaluated as one composed transaction.

However, the note states that atomic execution controls how a set of operations completes but does not establish whether the underlying business judgment was good. It does not verify that a price was sensible, a recipient was appropriate, or an external service delivered what it promised. Transaction costs also remain a factor even when using atomic transactions.

The design note addresses the complexity of delegation, where an agent may call another service or delegate part of a task. This raises questions about authority and whether the next participant can do only what the original user permitted. A robust design, as outlined in the document, would make delegation permissions visible by specifying a budget, approved purpose, expiry, and a limited set of counterparties. The system would then check these conditions at the point where an action is authorized.

Verifiable Records and Limitations

The note argues that a shared record can help establish which action was authorized and which transaction occurred, which is useful for reconciliation and investigation when participants keep separate internal systems. However, a successful transaction does not prove that a customer received a physical good, that an invoice was genuine, or that an offchain input was accurate. Those facts require their own evidence and dispute process.

The Sui Foundation states that the design note is an analytical principle, not a claim that one blockchain automatically supplies every required control. Developers still need to implement rules correctly and account for actions that occur outside the chain. The strongest implication of the note is to start with a narrowly defined authority, enforce it at the system boundary, and make completed actions inspectable. The scope of agent authority should only be expanded when controls and operational evidence justify doing so. The quality of the resulting agent depends on the complete application, including its permissions, information sources, and response to unexpected workflows.