The narrative around autonomous agents often fixates on throughput, but the real threat is authorization. A recent deep dive by developer Lewis Awe compares two distinct implementations of spending limits for AI agents: AWS AgentCore Payments and a custom Sui Move module. The core thesis is simple: once an agent holds a wallet, you have handed a non-deterministic process the ability to move money. The failure mode isn't slowness; it's a confused agent signing a payment it never should have, perhaps driven by a poisoned web page read three tool-calls ago.

The AWS Model: Trust the Service

The AWS implementation, which Awe previously shipped and tested on Base Sepolia, places enforcement off-chain at the service layer. The budget is a server-side check inside a trusted admin path, with wallet keys stored in AWS Secrets Manager. The agent never holds the credentials; it asks AWS to pay, and AWS enforces the limit. Using the x402 protocol, the agent handles HTTP 402 challenges and settles stablecoin microtransactions. The critical security feature is that the budget check is deterministic at the API layer, not a sentence in a system prompt. Prompt injection cannot spend past the budget because the model is not the entity holding the budget.

The Sui Model: Trust the Bytecode

In contrast, the Sui implementation puts rules directly on-chain within the Move type system. Awe built a module called agent_auth where the budget is a set of fields on a capability object. There is no admin service to query; possession of the object is the authorization. The SpendingCap struct carries its own rules, including per_period_limit and total_cap, into every transaction. Enforcement happens via bytecode assertions that abort the transaction with specific named codes like EExceedsPeriodLimit if a rule is violated. This approach removes the service layer entirely, relying on the immutability of published code and the validator set.

Implementation Realities and Trade-offs

Both systems offer strong prompt-injection resistance but for different reasons. In AWS, the model cannot exceed the cap because a trusted service rejects the call before signing. In Sui, the model is irrelevant to enforcement; the chain refuses to execute the state transition if the limit is breached. However, the trade-offs are stark. AWS requires a browser-based delegation step via Privy, which cannot be scripted, and keys remain in a trusted provider's vault. Sui allows programmatic delegation via object transfer but forces the developer to manage key custody and gas. While AWS offers rich SDKs and CloudWatch audit trails, Sui provides public, inspectable chain state and typed abort codes.

Key Takeaways

  • Authorization, not throughput, is the primary security frontier for agentic payments.
  • AWS AgentCore enforces limits via a trusted off-chain service, keeping keys in Secrets Manager.
  • Sui enforces limits via on-chain bytecode, making the capability object the rule.
  • Prompt injection fails in both models, but AWS relies on service integrity while Sui relies on code correctness.
  • AWS requires manual browser delegation; Sui allows fully programmatic capability transfers.

The Bottom Line

If you are building for production today, AWS offers a safer, auditable path with managed custody. If you are building for a permissionless future, Sui proves that the rule can be the transaction itself, eliminating the service layer as a single point of failure. The verdict is clear: neither model is perfect. The AWS approach is ergonomic but introduces a trusted third party that can be misconfigured. The Sui approach is trust-minimized but makes bugs in the spend function immutable law. Awe's recommendation is a hybrid: start with the Sui enforcement model where the cap is the limit, then bolt on AWS-style custody and observability. Until then, choose your trust anchor carefully. The money leaks where the rules are weak.