Giving AI Agents a Wallet Gatekeeper: Fizzl's Spending Limits and Mobile Approval System

When AI agents can autonomously pay for APIs, a real-world question emerges: who keeps their wallet in check? A developer shared their solution on Reddit — Fizzl Agent Wallet — an attempt to build a controllable middle layer between an agent's autonomous payment capabilities and human control over funds.

Where the Problem Comes From: Agents That Spend on Their Own

As infrastructure like the x402 protocol, Base, and on-chain USDC on Solana matures, AI agents can now independently complete payments — subscribing to APIs and purchasing resources on their own. This is extremely convenient from an engineering standpoint, but it also introduces hidden risks.

As the developer put it: "I didn't want an agent with an open wallet that can spend everything." This statement captures the core tension in the agent economy — we want agents to be autonomous enough to improve efficiency, yet we worry they might make out-of-control spending decisions without supervision. Whether due to a software bug, a prompt injection attack, or simple logic errors, an agent with full payment authority could cause real financial damage.

The x402 protocol is a machine-to-machine (M2M) payment standard designed specifically for AI agents, named after the HTTP 402 "Payment Required" status code. The core idea is: when an API or service requires payment, the server returns a 402 response with payment requirements, the agent automatically completes a cryptocurrency payment and retries the request — all without human intervention. Combined with Base (Coinbase's Ethereum L2) or USDC stablecoins on Solana, AI agents can complete cross-border micropayments in milliseconds, subscribing to data services, calling paid APIs, or purchasing compute resources. The maturation of this infrastructure greatly expands agents' autonomous capabilities, but it also means a misconfigured or compromised agent could drain an entire linked account in a very short time — far too fast for traditional manual approval processes to respond.

Fizzl's Core Design: Spending Limits Plus Human Approval

Fizzl Agent Wallet's approach is to insert a "gatekeeper" layer between the agent and its funds, providing several key capabilities.

Tiered Spending Controls

The system allows you to set per-transaction and daily spending limits for each individual agent. This means that even if an agent behaves abnormally, losses are capped within predefined bounds. Different agents can be configured with different limits to match their respective task contexts.

Mobile Approval When Limits Are Exceeded

This is the most practically valuable design in the solution. When a payment exceeds the limit, the agent doesn't execute the transaction directly — instead, it enters a waiting state and sends a request to the user via mobile, supporting Face ID, push notifications, or Telegram confirmation. The critical detail is its default-deny logic: "No answer means no payment." This fail-safe mechanism ensures that silence equals rejection, not approval.

Human-Readable Transaction Receipts

Every payment generates a human-readable receipt recording what was purchased, from whom, for how much, and whether the system's presign-guard deemed the transaction safe. This provides a clear record for after-the-fact auditing and issue tracing.

The Architectural Choice: Non-Custodial Key Management

In the crypto asset management space, key ownership is the foundation of trust. Fizzl takes a clear stance here: agents always hold their own keys, while the server is only responsible for counting, querying, and logging — "it never holds keys or money."

This non-custodial design means Fizzl itself does not represent a single point of failure or trust risk for funds. The server's role is strictly limited to policy enforcement and approval mediation — not as a custodian of value. For users wary of centralized custody risks, this is an important architectural advantage, and it reduces concerns about losing funds if the platform shuts down or gets compromised.

Login supports wallets, email, or Face ID, and the app can be installed on mobile, lowering the barrier for everyday use.

Non-custodial vs. custodial are two fundamental models of crypto asset management. In custodial solutions, the platform holds users' private keys — users depend on the platform's integrity and security. The collapse of FTX, Mt.Gox, and other exchanges are extreme examples of this model's risks. In non-custodial solutions, private keys are always held by the user (or in this case, by the agent itself), and the platform cannot access the funds. Fizzl's non-custodial architecture means that even if Fizzl's servers are hacked or the company shuts down, attackers cannot directly transfer user assets. The presign-guard is a key complement to this design — it performs a policy review of the transaction before it's broadcast to the blockchain, acting as a final checkpoint at the signing stage rather than attempting recovery after funds have already left.

Product Status and the Developer's Requests

Fizzl currently offers a free tier: you can browse without an account at wallet.fizzl.eu/demo, and the free version supports 1 agent. The Pro version offers unlimited agents, 90-day receipt storage, and an endpoint monitoring feature. The developer says they're willing to provide 30-day free trial codes for testers.

Notably, the developer is explicitly seeking "blunt feedback" — specifically asking which parts are unclear, what features are missing, and "what do you need before you'd trust an agent to something like this?" The wallet has a built-in feedback channel, and the developer says they read every piece of feedback. This open solicitation reflects that the product is still in early validation stages.

An Observation: Agent Payment Security Is an Emerging Must-Have

From a broader perspective, Fizzl addresses a need that is actively taking shape. As autonomous agents begin participating in real economic activity, "financial governance" tooling around them will inevitably become part of the infrastructure. Spending limits, human approval, auditable receipts, non-custodial keys — these concepts are essentially migrating mature ideas from traditional financial risk management into the AI agent context.

As an early-stage product, however, it still needs to answer several key questions: Will mobile approval become an efficiency bottleneck in high-frequency payment scenarios? How reliable is the presign-guard's safety assessment logic? What is the scope of endpoint monitoring coverage? These all require real-world testing to validate. For developers exploring autonomous agent payments, it at least offers a reference implementation worth trying out.

(This article is based on a single developer self-report from the Reddit platform. Actual feature performance should be verified through direct experience.)