DEV Community

Cover image for 21 Ways to Control Your AI Trading Bot: Complete Policy Engine Risk Management
Wallet Guy
Wallet Guy

Posted on

21 Ways to Control Your AI Trading Bot: Complete Policy Engine Risk Management

#trading #defi #ai #security

21 Ways to Control Your AI Trading Bot: Complete Policy Engine Risk Management

AI trading bots with unrestricted wallet access are a liability waiting to happen — one misconfigured agent or compromised session token away from draining everything you've built. If you're giving an AI agent access to real funds, you need more than good intentions and crossed fingers. You need explicit, auditable, code-enforced guardrails between your agent and your money.

The Real Risk: Autonomous Agents With Wallets

Here's the uncomfortable truth about AI agents and crypto wallets: most implementations treat authorization as a binary. Either the agent has access or it doesn't. That's fine for toy projects. It's dangerous for anything running on mainnet with real capital.

The threat surface is larger than most developers account for. It's not just "what happens if the AI makes a bad trade." It's: what happens when the session token leaks? What if the model hallucinates a recipient address? What if a protocol gets exploited and the agent keeps interacting with it? What if you want your bot to handle small rebalancing operations autonomously but need human sign-off on anything over $500?

These aren't edge cases. They're the questions that determine whether you can actually trust an autonomous system with funds.

3 Layers Between Your Agent and Your Money

WAIaaS is built around a layered security model that doesn't require you to choose between autonomy and safety. The architecture provides three distinct control layers:

Layer 1 — Session authentication. Every AI agent operates on a scoped session token. Sessions have TTL, maxRenewals, and absoluteLifetime controls. A compromised token has a bounded blast radius.

Layer 2 — Policy engine with time delays and approval gates. This is where most of the risk management lives. 21 policy types, 4 security tiers, and a default-deny posture means your agent literally cannot do things you haven't explicitly permitted.

Layer 3 — Monitoring and kill switch. Incoming transaction monitoring with real-time notifications, plus WalletConnect-based owner approval for high-risk actions.

Three auth methods serve three different roles: masterAuth (Argon2id) for system administration like creating wallets and sessions, ownerAuth (SIWS/SIWE signature) for the fund owner approving or rejecting transactions, and sessionAuth (JWT HS256) for the AI agent's day-to-day operations.

# masterAuth — system administrator (wallet creation, session management, policies)
-H "X-Master-Password: my-secret-password"

# sessionAuth — AI agent (transactions, balance queries, DeFi actions)
-H "Authorization: Bearer wai_sess_eyJhbGciOiJIUzI1NiJ9..."

# ownerAuth — fund owner (transaction approval, kill switch recovery)
-H "X-Owner-Signature: <ed25519-or-secp256k1-signature>"
-H "X-Owner-Message: <signed-message>"
Enter fullscreen mode Exit fullscreen mode

The agent never touches masterAuth credentials. The owner never needs to run the agent. These roles are cleanly separated by design.

Default-Deny: The Most Important Security Property

Before walking through all 21 policy types, the most important thing to understand is the default-deny posture. If you don't configure ALLOWED_TOKENS, your agent cannot transfer tokens. If you don't configure CONTRACT_WHITELIST, your agent cannot call contracts. No whitelist means no access — not "access to everything."

This inverts the typical developer instinct. Most systems are permissive by default and you add restrictions. WAIaaS is restrictive by default and you add permissions. That distinction matters enormously when something goes wrong.

The 4 Security Tiers

Every transaction that passes through WAIaaS gets classified into one of four tiers:

INSTANT   — Execute immediately, no notification
NOTIFY    — Execute immediately, send notification to owner
DELAY     — Queue for N seconds, then execute (cancellable during window)
APPROVAL  — Require explicit human approval via WalletConnect/Telegram/Push
Enter fullscreen mode Exit fullscreen mode

The tier assignment is policy-driven and amount-aware. You define the thresholds. Here's what a realistic SPENDING_LIMIT policy looks like:

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
    }
  }'
Enter fullscreen mode Exit fullscreen mode

With this config: under $100 executes immediately and silently, $100-$500 executes immediately but pings you, $500-$2000 goes into a 15-minute holding queue you can cancel, and anything over $2000 requires your explicit approval. Your agent can be fully autonomous for small rebalancing ops while you stay in the loop for anything significant.

All 21 Policy Types

Here's the complete picture. These aren't marketing categories — these are the actual policy types enforced in the transaction pipeline.

Spending and Limits

SPENDING_LIMIT — The primary amount-based control. 4-tier security based on USD value. Supports daily and monthly caps, plus per-token limits for granular control.

APPROVE_AMOUNT_LIMIT — Caps how large a token approval can be. Blocks unlimited approvals (uint256 max). Critical for DeFi safety — unlimited approvals to compromised protocols have caused massive losses in the past.

APPROVE_TIER_OVERRIDE — Force a specific security tier for all APPROVE transactions regardless of amount. If you want every approval to require human sign-off no matter what, this is how you enforce it.

ACTION_CATEGORY_LIMIT — Set spending limits per category of DeFi action. You can cap how much your agent allocates to lending separately from how much it allocates to perpetual futures.

Allowlists (All Default-Deny)

ALLOWED_TOKENS — Define exactly which tokens the agent can transfer. Anything not on the list is blocked, full stop.

{"tokens": [{"address": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", "symbol": "USDC", "chain": "solana"}]}
Enter fullscreen mode Exit fullscreen mode

CONTRACT_WHITELIST — Define which smart contracts the agent can interact with. Your agent cannot call Jupiter if Jupiter isn't on this list.

{"contracts": [{"address": "JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4", "name": "Jupiter", "chain": "solana"}]}
Enter fullscreen mode Exit fullscreen mode

APPROVED_SPENDERS — Control which addresses can be granted token approvals, with optional max amounts per spender.

{"spenders": [{"address": "0xDEF1...", "name": "Uniswap Router", "maxAmount": "1000000000"}]}
Enter fullscreen mode Exit fullscreen mode

METHOD_WHITELIST — Allowlist specific function selectors. If your agent should only be able to call swap() and not withdraw(), this is how you encode that.

WHITELIST — Recipient address allowlist. Your agent can only send funds to addresses you've pre-approved.

{"allowed_addresses": ["<address1>", "<address2>"]}
Enter fullscreen mode Exit fullscreen mode

VENUE_WHITELIST — Allowlist specific trading venues. Restrict which DEXes or protocols the agent can use.

Rate and Time Controls

RATE_LIMIT — Maximum number of transactions per hour or per day. Useful for detecting runaway agent behavior and capping the damage from a misbehaving model.

{"maxTransactions": 10, "period": "hourly"}
Enter fullscreen mode Exit fullscreen mode

TIME_RESTRICTION — Restrict transaction execution to specific hours. If your trading strategy only makes sense during market hours, enforce that at the infrastructure level.

{"allowedHours": {"start": 9, "end": 17}, "timezone": "UTC"}
Enter fullscreen mode Exit fullscreen mode

ALLOWED_NETWORKS — Restrict the agent to specific chains. An agent configured for Solana mainnet operations shouldn't be able to send transactions on Ethereum.

{"networks": [{"network": "solana-mainnet"}]}
Enter fullscreen mode Exit fullscreen mode

DeFi-Specific Controls

LENDING_LTV_LIMIT — Maximum loan-to-value ratio for DeFi lending positions. Prevents your agent from over-leveraging into liquidation territory.

LENDING_ASSET_WHITELIST — Which assets the agent is allowed to supply or borrow. You can allow USDC borrowing without allowing your agent to touch riskier assets.

PERP_MAX_LEVERAGE — Hard cap on perpetual futures leverage. A leveraged trading bot without this is a liquidation waiting to happen.

PERP_MAX_POSITION_USD — Maximum position size in USD for perp trades. Caps the worst-case loss from a single bad trade.

PERP_ALLOWED_MARKETS — Which perpetual markets the agent can trade. If your strategy is SOL-PERP only, enforce that explicitly.

Protocol and Agent Controls

X402_ALLOWED_DOMAINS — Allowlist for x402 HTTP payment protocol. WAIaaS supports automatic API payment for AI agents via x402; this policy controls which domains the agent is allowed to pay automatically.

{"domains": ["api.example.com", "*.openai.com"]}
Enter fullscreen mode Exit fullscreen mode

REPUTATION_THRESHOLD — Minimum ERC-8004 onchain reputation score required for agent interactions. Enables trustless agent validation.

ERC8128_ALLOWED_DOMAINS — Controls which domains the agent can sign HTTP requests for using the ERC-8128 protocol.

The 7-Stage Transaction Pipeline

Policies don't run as an afterthought — they're embedded in a 7-stage pipeline that every transaction passes through: validate → auth → policy → wait → execute → confirm. The wait stage is where DELAY-tier transactions sit in the cancellable queue. Nothing executes until it clears every preceding stage.

This means you can simulate a transaction before it ever hits the pipeline. The dry-run API lets you validate against the full policy stack without committing to execution:

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": "0.1",
    "dryRun": true
  }'
Enter fullscreen mode Exit fullscreen mode

This is useful during development to verify that your policy configuration actually behaves the way you expect before you run anything on mainnet.

And when a policy blocks a transaction, the error response tells you exactly why:

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

No ambiguity. The agent — and you — know precisely what rule was triggered.

Human Approval in the Loop

APPROVAL-tier transactions require a human response before anything executes. WAIaaS supports three signing channels for delivering approval requests: push relay, Telegram, and WalletConnect. Once you approve, the transaction proceeds. If you reject or let it time out, it doesn't.

The owner approval endpoint uses a signed message for authentication — your wallet signs, not a password:

curl -X POST http://127.0.0.1:3100/v1/transactions/<tx-id>/approve \
  -H "X-Owner-Signature: <ed25519-or-secp256k1-signature>" \
  -H "X-Owner-Message: <signed-message>"
Enter fullscreen mode Exit fullscreen mode

This is the kill switch pattern. Even if every other layer were compromised, transactions requiring owner approval can't execute without a cryptographic signature from the controlling wallet.

Quick Start: Setting Up Your First Policy Stack

Here's the minimum viable security setup for a Solana trading agent:

Step 1: Install and initialize WAIaaS.

npm install -g @waiaas/cli
waiaas init
waiaas start
Enter fullscreen mode Exit fullscreen mode

Step 2: Create a wallet and session for your agent.

curl -X POST http://127.0.0.1:3100/v1/wallets \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"name": "trading-wallet", "chain": "solana", "environment": "mainnet"}'

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>"}'
Enter fullscreen mode Exit fullscreen mode

Step 3: Set a spending limit with tiered security.

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
    }
  }'
Enter fullscreen mode Exit fullscreen mode

Step 4: Add an allowed tokens policy (default-deny enforcement).

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"}]
    }
  }'
Enter fullscreen mode Exit fullscreen mode

Step 5: Verify a transaction against your policies using dry-run before going live.

Your agent now operates with bounded autonomy: it can move funds within your defined limits, it's blocked from touching anything not explicitly permitted, and anything over your DELAY threshold requires your active involvement.

What's Next

The policy engine is one part of the WAIaaS security model. Explore the full interactive API reference at http://127.0.0.1:3100/reference once your daemon is running — it's auto-generated from the codebase and covers all 39 API route modules. For production deployments, review the Docker Secrets integration and the secrets overlay pattern in docker-compose.secrets.yml to keep your master password out of environment variables entirely.

The source code, full documentation, and deployment guides are at https://github.com/waiaas/WAIaaS. If you're building AI agents that handle real capital, start there. The project site with additional resources is at https://waiaas.ai.

Top comments (0)