The Agent Economy Needs Infrastructure, Not More Custodial Services

AI agents will need to pay for compute, data, and API calls — and the infrastructure to let them do that autonomously already exists today. The problem isn't that the idea is too early; it's that most current approaches hand wallet control back to a human, defeating the purpose entirely. If an agent has to wait for a person to approve every transaction, you haven't built an autonomous agent. You've built a very expensive form.

The Real Problem with "AI Agent Wallets" Today

When people talk about giving AI agents access to money, they usually mean one of two things: a custodial account where a company holds the keys on behalf of the agent, or a developer who manually wires API calls to a centralized exchange. Both approaches have the same structural flaw — a human or corporation is in the control path.

That matters because the agent economy doesn't work that way. Agents need to operate on timescales and at frequencies that humans can't match. An LLM-based research agent might need to pay for ten different data APIs in a single session. A trading agent running at 3am shouldn't be blocked waiting for someone to wake up and click "approve." A swarm of specialized agents coordinating on a task shouldn't require a human to act as financial middleware between them.

The infrastructure question isn't "how do we give agents a credit card?" It's "how do we build wallet infrastructure that agents can actually operate autonomously — with real policy controls so that autonomy doesn't mean uncontrolled?"

What Autonomous Wallet Infrastructure Actually Requires

A wallet built for autonomous agents isn't just an API wrapper around key management. It needs several things to work together:

Session-scoped access — agents shouldn't hold master keys. They should get scoped credentials that expire, with limits on what they can do.

Policy enforcement at the infrastructure layer — spending limits, token whitelists, contract whitelists, and rate limits shouldn't live in the agent's code. If they do, a prompt injection or model error can bypass them. They need to be enforced by the wallet daemon itself, outside the agent's trust boundary.

Human oversight without human bottlenecking — the owner of the funds needs visibility and veto power, but shouldn't be in the critical path for routine transactions.

Native HTTP payment support — agents paying for API calls shouldn't require wrapping every payment in a custom integration. There's a protocol for this.

Multi-chain, multi-protocol reach — a real agent economy won't exist on one chain. Agents need to operate across EVM networks, Solana, and the DeFi protocols that run on them.

WAIaaS is an open-source, self-hosted Wallet-as-a-Service that addresses all of these. It runs as a local daemon, and agents interact with it through a REST API, an MCP server, or TypeScript/Python SDKs. You hold your own keys. Nothing goes through a third-party custodian.

The Architecture: Three Auth Layers, One Pipeline

The security model has three distinct layers, each scoped to a different principal.

masterAuth (Argon2id) is for the system administrator — creating wallets, configuring policies, issuing session tokens. Your agent never sees this credential.

sessionAuth (JWT HS256) is what the agent actually uses. Sessions have TTL, max renewals, and an absolute lifetime. An agent that gets compromised or goes haywire has a bounded credential.

ownerAuth (SIWS/SIWE signature) belongs to the fund owner — the human who can approve pending transactions, or trigger a kill switch.

Every transaction goes through a 7-stage pipeline: validate → auth → policy → wait → execute → confirm. The policy stage is where the infrastructure does the work your agent shouldn't be trusted to do itself.

Policy Enforcement That Lives Outside the Agent

WAIaaS has 21 policy types and 4 security tiers (INSTANT, NOTIFY, DELAY, APPROVAL). The default-deny model means a transaction is blocked unless explicitly allowed — you have to opt into what the agent can do, not opt out of what it can't.

Here's a spending limit policy that lets an agent execute small transactions instantly, sends a notification for medium ones, queues larger ones with a delay, and requires human approval for anything above a threshold:

curl -X POST http://127.0.0.1:3100/v1/policies \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{
    "walletId": "<wallet-uuid>",
    "type": "SPENDING_LIMIT",
    "rules": {
      "instant_max_usd": 100,
      "notify_max_usd": 500,
      "delay_max_usd": 2000,
      "delay_seconds": 900,
      "daily_limit_usd": 5000
    }
  }'

Transactions under $100 execute immediately. $100–$500 execute but the owner gets notified. $500–$2000 queue for 15 minutes before executing, giving the owner time to cancel. Above $2000, the transaction requires explicit approval via WalletConnect, Telegram, or push notification.

The agent doesn't know or control any of this. The policy engine evaluates it before execution regardless of what the agent requested.

Beyond spending limits, you can layer in ALLOWED_TOKENS (agent can only move whitelisted tokens), CONTRACT_WHITELIST (agent can only call approved contracts), RATE_LIMIT (max transactions per period), ALLOWED_NETWORKS (restrict to specific chains), and DeFi-specific policies like PERP_MAX_LEVERAGE and LENDING_LTV_LIMIT.

This is the right place for these controls. Not in the agent's system prompt, not in application-layer code the agent can influence — in the infrastructure layer that the agent can't touch.

x402: Agents That Pay for What They Use

One of the most interesting near-term applications of autonomous agent wallets is HTTP payments. The x402 protocol lets an HTTP server respond to a request with a 402 Payment Required status, the agent pays automatically, and the request proceeds — all without human involvement.

WAIaaS has native x402 support. An agent using the TypeScript SDK can make paid API calls like this:

import { WAIaaSClient } from '@waiaas/sdk';

const client = new WAIaaSClient({
  baseUrl: 'http://127.0.0.1:3100',
  sessionToken: process.env.WAIAAS_SESSION_TOKEN,
});

The x402Fetch() method handles the payment flow automatically. The agent requests a resource, the server asks for payment, the wallet pays, and the agent gets the data — the same pattern as any HTTP request, but with a payment step in the middle.

From a policy perspective, you can restrict which domains an agent is allowed to pay via X402_ALLOWED_DOMAINS. The agent can only make automatic payments to whitelisted endpoints — it can't be tricked by a prompt injection into paying an attacker's server.

This is what "agents that pay for what they use" actually looks like at the infrastructure level. Not a billing dashboard where a human reviews charges. Micropayments flowing automatically, bounded by policy, auditable after the fact.

DeFi Access for Autonomous Agents

The agent economy isn't just about paying for API calls. Agents are increasingly being deployed to manage DeFi positions, execute trading strategies, and optimize yield across protocols. WAIaaS has 15 DeFi protocol providers integrated: Aave v3, Jupiter, Uniswap (via 0x), Hyperliquid, Lido, Jito, Kamino, Pendle, Polymarket, LI.FI, Across, and others.

A trading agent executing a Jupiter swap on Solana looks like this:

curl -X POST http://127.0.0.1:3100/v1/actions/jupiter-swap/swap \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "inputMint": "So11111111111111111111111111111111111111112",
    "outputMint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
    "amount": "1000000000"
  }'

The agent sends the intent. The policy engine checks it against CONTRACT_WHITELIST, ALLOWED_TOKENS, SPENDING_LIMIT, and any DeFi-specific policies. If everything passes, the transaction executes. If not, the agent gets back a structured error:

{
  "error": {
    "code": "POLICY_DENIED",
    "message": "Transaction denied by SPENDING_LIMIT policy",
    "domain": "POLICY",
    "retryable": false
  }
}

The agent can handle this error and decide whether to retry with a smaller amount, wait for approval, or report back to the user. The infrastructure enforces the constraint; the agent decides what to do about it.

For agents that need to simulate before committing, the dry-run API lets you test a transaction without executing it — just add "dryRun": true to any transaction request.

Connecting Agents to Wallets via MCP

For developers using Claude or other MCP-compatible AI frameworks, WAIaaS ships an MCP server with 45 tools covering wallet operations, transactions, DeFi, NFTs, and x402. Setup is one command:

waiaas mcp setup --all

This auto-registers all wallets with Claude Desktop. After that, Claude can check balances, send tokens, query DeFi positions, and execute swaps — all scoped to the session token associated with the MCP server, all enforced by the policy engine.

The Claude Desktop configuration supports multiple wallets as separate MCP server instances, so a trading agent and a treasury agent can operate with completely different policies on different wallets, even within the same Claude session.

Getting Started in Five Minutes

If you want to see this working rather than just read about it:

Step 1: Install the CLI and start the daemon

npm install -g @waiaas/cli
waiaas init
waiaas start

Step 2: Create a wallet and a session token

waiaas quickset --mode mainnet

This creates wallets and MCP sessions in one step. The output includes the MCP configuration JSON you paste into Claude Desktop.

Step 3: Create a policy to bound what the agent can do

curl -X POST http://127.0.0.1:3100/v1/policies \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{
    "walletId": "<wallet-uuid>",
    "type": "SPENDING_LIMIT",
    "rules": {
      "instant_max_usd": 10,
      "notify_max_usd": 100,
      "delay_max_usd": 500,
      "delay_seconds": 300,
      "daily_limit_usd": 1000
    }
  }'

Step 4: Connect your agent

Use the TypeScript SDK, Python SDK, REST API directly, or the MCP server depending on your stack. The session token from Step 2 is the only credential your agent needs.

Step 5: Deploy with Docker for production

git clone https://github.com/minhoyoo-iotrust/WAIaaS.git
cd WAIaaS
docker compose up -d

The Docker image (ghcr.io/minhoyoo-iotrust/waiaas:latest) supports auto-provision, Docker Secrets for production, and runs as a non-root user. For production secret management, use the secrets overlay:

docker compose -f docker-compose.yml -f docker-compose.secrets.yml up -d

The Infrastructure Moment

The agent economy is not a future prediction. Agents are being deployed today to trade, research, and coordinate. The infrastructure question — how do they handle money — is being answered right now, mostly with duct tape and custodial services that recreate the centralization problems we already know how to solve.

The right answer is self-hosted wallet infrastructure with cryptographic auth, policy enforcement outside the agent's trust boundary, and open protocols for agent-to-service payments. That infrastructure exists and runs on your hardware today.

What's Next

The full documentation, including the OpenAPI spec (available at /doc after you start the daemon) and the interactive API reference at /reference, covers all 39 REST API route modules and the complete policy configuration options. The GitHub repository has the full source, including the 15-package monorepo and 683+ test files.

If you're building agents that need to move value — start with the infrastructure layer. Everything else follows from there.

Start building: github.com/minhoyoo-iotrust/WAIaaS · waiaas.ai