3 Layers Between Your AI Agent and Your Funds

2026-03-31

Giving an AI agent a wallet is like handing over your car keys to a teenager—you know they'll get places faster, but you also know they need guardrails. The question isn't whether AI agents should handle crypto transactions (they already are), but how to let them operate without risking your entire treasury on a hallucination or prompt injection.

Most developers building AI agents face the same uncomfortable choice: either severely limit what the agent can do (defeating the purpose), or give it full wallet access and hope nothing goes wrong. There's got to be a middle ground.

Why AI Agent Security Matters More Than You Think

The stakes are real. Unlike traditional APIs where a bug might corrupt data or spam users, crypto transactions are irreversible. A confused agent that misinterprets "send 0.1 ETH" as "send 10 ETH" doesn't just create an awkward support ticket—it creates an actual financial loss.

Even worse, AI agents are particularly vulnerable to prompt injection attacks where malicious inputs trick the agent into performing unintended actions. When those actions involve moving funds, the damage can be immediate and permanent.

The naive approach—generating a private key and letting the agent sign whatever it wants—works until it doesn't. And when it doesn't work, you're explaining to your users (or your boss) why the trading bot just market-sold the entire position at 3 AM.

Three Layers of Defense

WAIaaS implements a 3-layer security model: authentication → policy enforcement → human oversight. Each layer serves as a backstop for the ones before it, ensuring that even if your agent goes rogue, your funds stay safe.

Layer 1: Session-Based Authentication

Instead of giving your agent raw private keys, WAIaaS uses short-lived session tokens. Your agent authenticates once to get a JWT token that expires, can be revoked instantly, and only grants access to specific wallets.

# Create a session for your AI agent (masterAuth)
curl -X POST http://127.0.0.1:3100/v1/sessions \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"walletId": "<wallet-uuid>"}'

The session token includes built-in limits: time-to-live, maximum renewals, and absolute lifetime. When something goes wrong, you kill the session instead of trying to wrestle control back from a misbehaving agent.

# Agent uses session token for all operations
curl http://127.0.0.1:3100/v1/wallet/balance \
  -H "Authorization: Bearer wai_sess_eyJhbGciOiJIUzI1NiJ9..."

This alone prevents the "oops, I leaked my private key in a GitHub repo" scenario, but it's just the first line of defense.

Layer 2: Policy Engine with Default-Deny

Here's where WAIaaS gets serious about security. The policy engine uses 21 different policy types with 4 security tiers: INSTANT, NOTIFY, DELAY, and APPROVAL. More importantly, it follows default-deny: your agent literally cannot touch tokens or contracts you haven't explicitly whitelisted.

# Create a token whitelist (masterAuth)
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": "ALLOWED_TOKENS",
    "rules": {
      "tokens": [
        {"address": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", "symbol": "USDC", "chain": "solana"}
      ]
    }
  }'

Without this policy, your agent can't transfer USDC at all—even if it has the session token. Default-deny means you explicitly define what's allowed rather than hoping to catch what should be blocked.

The spending limit policy adds amount-based tiers:

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": 1000,
      "delay_seconds": 300,
      "daily_limit_usd": 500
    }
  }'

Now your agent can send up to $10 instantly, $100 with notifications, $1000 after a 5-minute delay (giving you time to cancel), and anything larger requires explicit human approval. The daily limit acts as a circuit breaker.

Layer 3: Human Approval Channels

When your agent hits the APPROVAL tier—or when you need to intervene manually—WAIaaS provides multiple human-in-the-loop channels. WalletConnect integration means you can approve transactions directly from your existing wallet app. Telegram and push notification channels mean you get alerted in real-time when your agent is about to do something expensive.

# Agent submits large transaction → goes to pending queue
curl -X POST http://127.0.0.1:3100/v1/transactions/send \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "type": "TRANSFER",
    "to": "recipient-address",
    "amount": "5.0"
  }'

# You approve via WalletConnect or API call
curl -X POST http://127.0.0.1:3100/v1/transactions/<tx-id>/approve \
  -H "X-Owner-Signature: <ed25519-signature>" \
  -H "X-Owner-Message: <signed-message>"

This isn't just about large amounts. You can force specific transaction types or recipients into the approval queue. Maybe your trading agent can swap freely but needs approval before interacting with new DeFi protocols.

Default-Deny in Practice

The key insight is that most wallet security failures come from agents doing things they were never supposed to do. Default-deny flips the model: instead of trying to block bad actions, you define the narrow set of allowed actions.

Here's what default-deny looks like for a trading agent:

# 1. Only allow specific tokens
ALLOWED_TOKENS: [USDC, SOL, ETH]

# 2. Only allow known DEX contracts  
CONTRACT_WHITELIST: [Jupiter, Uniswap_Router, 1inch]

# 3. Spending limits with human oversight
SPENDING_LIMIT: instant=$50, delay=$500, approval=$1000+

# 4. Rate limiting
RATE_LIMIT: 20 transactions/hour

Your agent can now trade efficiently within these boundaries, but it cannot:

Touch random tokens (even if they appear in your wallet)
Interact with unknown contracts (even if they claim to be DEXs)
Make large trades without delay/approval
Spam transactions faster than your rate limit

When your agent tries to do something outside these rules, it gets a clear error message instead of silently failing or, worse, succeeding when it shouldn't have.

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

Practical Implementation

Setting up secure AI agent wallets with WAIaaS takes about 10 minutes:

1. Deploy the daemon:

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

2. Create wallets and policies:

npm install -g @waiaas/cli
waiaas init
waiaas start
waiaas quickset --mode mainnet  # Creates wallets + sessions

3. Configure your AI agent with the SDK:

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

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

// Agent can now operate within policy boundaries
const balance = await client.getBalance();
const tx = await client.sendToken({
  to: 'recipient-address',
  amount: '0.1',
});

4. Set up MCP integration for Claude or other AI frameworks:

waiaas mcp setup --all

5. Test the guardrails by having your agent attempt something outside policy bounds—it should fail gracefully with clear error messages.

The daemon exposes 39 REST API endpoints for everything from balance queries to DeFi position management, all protected by the same 3-layer security model. Your agent gets the capabilities it needs without the access it shouldn't have.

Beyond Basic Security

WAIaaS includes more sophisticated security features for production deployments. The 7-stage transaction pipeline includes gas price conditions (transactions only execute when gas is below your threshold), dry-run simulation (test transactions before committing), and cross-chain bridging with built-in slippage protection.

For teams managing multiple agents, the policy engine supports per-agent customization. Your conservative DCA bot gets different spending limits than your active arbitrage bot, but both operate under the same security framework.

The system also integrates with ERC-4337 Account Abstraction for gasless transactions and ERC-8004 for onchain agent reputation—letting you grant higher limits to agents with proven track records while keeping new agents on tight leashes.

The Real Test: When Things Go Wrong

Security systems are ultimately judged by how they handle failures, not successes. WAIaaS assumes your agent will eventually do something stupid and builds accordingly. Session tokens expire and can be killed instantly. Policies are enforced at the transaction level, not just the application level. Human approval channels provide multiple fallback options.

Most importantly, the default-deny approach means that even a completely compromised agent can only operate within the boundaries you've defined. It can't suddenly start interacting with new contracts, transferring random tokens, or exceeding spending limits just because it received malicious instructions.

This isn't theoretical—these are the actual guardrails protecting live agents managing real funds on mainnet today. The question isn't whether your AI agent will eventually encounter edge cases or adversarial inputs. The question is whether you'll have the right safeguards in place when it does.

Ready to give your AI agent a wallet without giving it the keys to the kingdom? Start with the WAIaaS GitHub repository for the full implementation, or check out the documentation and examples at waiaas.ai. Your future self—and your users—will thank you for building security in from the start.