{
  "id": 17674960,
  "title": "Giving an AI agent a wallet without giving it your keys",
  "url": "https://urgent.news/2026/11/01/giving-an-ai-agent-a-wallet-without-giving-it-your-keys",
  "topic": "ai",
  "section": "AI",
  "published": "2026-11-01T20:41:25.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/ahmad_shawar_de8d35d546cf/giving-an-ai-agent-a-wallet-without-giving-it-your-keys-407k"
  },
  "original_language": "en",
  "account": "Recent developments have seen AI agents engaging in financial transactions, such as purchasing API credits, renting GPUs, or acquiring datasets. The emergence of x402 (HTTP 402 Payment Required with on-chain payment) has made such actions commonplace. The primary challenge lies in determining how these agents should manage their funds. Two undesirable approaches include assigning a private key to the agent, which can be compromised through prompt injection, bugs, or leaked environment files, and manually approving each payment, a cumbersome process that negates the purpose of utilizing an agent.\n\nThe solution lies in implementing a budgeted wallet for agents, akin to a company card with predefined limits. These limits should be established in a manner inaccessible to the agent itself and the machine it runs on. A smart contract, such as Purser, an ERC-4337 smart account, is well-suited for this purpose. The owner grants each agent a session key, complete with a policy encompassing an allow-list of contracts and functions, a cap per payment, and a budget per period, all set to expire at a specific time. Once the agent initiates a transaction, it operates independently, provided the sum does not surpass the pre-set limits. Should the limits be exceeded, the transaction transforms into an approval request, which will only proceed with the owner's signature.\n\nA significant challenge revolves around the ERC-4337 protocol, which separates an operation into validation and execution stages. However, validation cannot access the clock, complicating the implementation of a daily budget. To address this, the checks are segregated: during validation, the signature, validity window, allow-list, and per-payment cap are evaluated, preventing disallowed calls from incurring any costs. During execution, the rolling budget can read the block time without any issues.\n\nSeveral rules further refine this approach. An owner approval increases the payment amount but not the scope, meaning that approved payments must still adhere to the authorized locations. Additionally, a revoke command executed earlier in a bundle effectively nullifies subsequent operations within the same bundle.\n\nTesting the monetary code demands more than traditional unit tests. Purser employs 41 unit tests, fuzz tests that juxtapose random payment and time sequences against a simplified budget model, and invariant tests that subject thousands of random calls to the account, verifying three properties—no overspending without approval, no funds movement by a revoked key, and no policy alteration without owner permission. Slither is integrated into the Continuous Integration (CI) process.\n\nThe system is still nascent and not fully audited, which is why all operations are conducted on a local chain. Agents interact with Purser via an MCP (Multi-Chain Protocol) server, which offers six tools: wallet_status, send_eth, send_token, call_contract, get_request, and list_requests. Each transaction yields one of three outcomes—the remaining budget, a request ID awaiting owner approval, or a refusal reason that the agent can interpret. To begin, install the Purser demo container using the command `docker run --rm -it -p 127.0.0.1:8787:8787 ghcr.io/ahmad-codex/purser:demo`. Once operational, connect your own agent using `claude mcp add --transport http purser http://localhost:8787/mcp` and instruct it to pay a merchant 0.3 ETH. The roadmap encompasses facilitating x402 endpoint transactions within budget constraints, introducing a gas budget per key, and incorporating EIP-7702 support. The project is licensed under the MIT license and boasts open good first issues. If you currently allow agents to spend money, I would be interested in learning how you manage to impose such limitations.",
  "summary": "Agents are starting to pay for things. An agent buying API credits, renting a GPU for an hour or paying for a dataset is no longer a thought experiment, and x402 (HTTP 402 Payment Required with on-chain payment) makes it a normal web request. That leaves the question of how the agent holds money. The two bad options Give the agent a private key. It works until a prompt injection, a bug or a…",
  "key_points": [
    "AI agents engage in financial transactions like purchasing API credits or renting GPUs.",
    "Budgeted wallets with predefined limits prevent agent compromise and manual approvals.",
    "Purser, an ERC-4337 smart account, manages agent budgets with validation and execution stages."
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}