{"slug": "complete-ai-agent-lockdown-21-policy-types-for-maximum-security", "title": "Complete AI Agent Lockdown: 21 Policy Types for Maximum Security", "summary": "WAIaaS has implemented a comprehensive security framework for AI agents interacting with crypto wallets, featuring a default-deny policy engine with 21 policy types across four security tiers. The system enforces role separation with three distinct authentication methods and supports transaction approval channels including WalletConnect, Telegram, and Push. This approach prevents unauthorized fund transfers and contract calls by requiring explicit policy configuration for any agent action.", "body_md": "Giving an AI agent a wallet without guardrails is like giving a toddler a credit card — technically functional, potentially catastrophic. If you're building AI agents that interact with crypto wallets, the security model you choose isn't an afterthought. It's the difference between a useful autonomous system and one that drains your funds on a bad inference.\n\nThis post is about exactly how WAIaaS handles that problem. Not vague promises about \"enterprise-grade security\" — specific mechanisms, specific policy types, and specific code you can run today.\n\nLet's be honest about what can go wrong when you give an AI agent wallet access:\n\nNone of these require a malicious agent. They can all happen with a well-intentioned model operating outside the boundaries you forgot to define. The solution isn't to avoid giving agents wallet access — it's to define exactly what they're allowed to do, and nothing more.\n\nWAIaaS approaches this with three distinct security layers, a default-deny policy engine with 21 policy types across 4 security tiers, and multiple channels for human approval when transactions exceed your defined thresholds.\n\nThe first layer is role separation. WAIaaS uses three authentication methods that map to three distinct principals:\n\n**masterAuth** (Argon2id) — The system administrator role. Creates wallets, manages sessions, configures policies. This credential never touches the agent.\n\n**sessionAuth** (JWT HS256) — The AI agent's credential. Scoped to a specific wallet, carries TTL and renewal limits. This is what your agent uses at runtime.\n\n**ownerAuth** (SIWS/SIWE signature) — The fund owner. Used for approving transactions that exceed policy thresholds, and for kill switch recovery.\n\n```\n# masterAuth — system administrator (wallet creation, session management, policies)\n-H \"X-Master-Password: my-secret-password\"\n\n# sessionAuth — AI agent (transactions, balance queries, DeFi actions)\n-H \"Authorization: Bearer wai_sess_eyJhbGciOiJIUzI1NiJ9...\"\n\n# ownerAuth — fund owner (transaction approval, kill switch recovery)\n-H \"X-Owner-Signature: <ed25519-or-secp256k1-signature>\"\n-H \"X-Owner-Message: <signed-message>\"\n```\n\nYour agent only ever holds the session token. Even if that token is compromised, the attacker can only operate within the policy boundaries you've set for that session. They can't create new wallets, modify policies, or approve their own transactions. Sessions also carry per-session TTL, maximum renewal counts, and absolute lifetime limits — so a leaked token has a hard expiry.\n\nThis is where the real work happens. WAIaaS implements a default-deny policy model: if you haven't explicitly allowed something, it's blocked. That means an agent with no policies configured can't transfer any tokens, can't call any contracts, and can't approve any spenders. The safe state is locked down, not open.\n\nPolicies are created by the administrator (masterAuth) and enforced by the daemon before any transaction reaches the network.\n\nEvery policy evaluation produces a tier assignment, and that tier determines what happens next:\n\n```\nINSTANT   — Execute immediately, no notification\nNOTIFY    — Execute immediately, send notification to owner\nDELAY     — Queue for delay_seconds, then execute (cancellable during window)\nAPPROVAL  — Require explicit human approval via WalletConnect, Telegram, or Push\n```\n\nThe SPENDING_LIMIT policy maps transaction amounts to these tiers:\n\n```\ncurl -X POST http://localhost:3100/v1/policies \\\n  -H 'Content-Type: application/json' \\\n  -H 'X-Master-Password: <password>' \\\n  -d '{\n    \"walletId\": \"<wallet-uuid>\",\n    \"type\": \"SPENDING_LIMIT\",\n    \"rules\": {\n      \"instant_max_usd\": 10,\n      \"notify_max_usd\": 100,\n      \"delay_max_usd\": 1000,\n      \"delay_seconds\": 300,\n      \"daily_limit_usd\": 500,\n      \"monthly_limit_usd\": 5000\n    }\n  }'\n```\n\nWith this configuration: transactions under $10 go through immediately. $10–$100 go through but you get notified. $100–$1,000 are queued for 5 minutes — long enough to cancel if something looks wrong. Anything over $1,000 requires your explicit approval. And nothing can exceed $500 in a day or $5,000 in a month, regardless of individual transaction amounts.\n\nThat's a meaningful security boundary defined in a single API call.\n\nThe SPENDING_LIMIT is the most intuitive, but the full policy set covers nearly every attack surface in crypto agent interactions:\n\n**Token and asset controls:**\n\n`ALLOWED_TOKENS`\n\n— Default-deny token whitelist. Your agent can only transfer tokens you've explicitly listed. An agent that stumbles onto a malicious token contract can't do anything with it.`APPROVE_AMOUNT_LIMIT`\n\n— Caps the maximum token approval amount. Blocks unlimited allowances, which are a common attack vector.`APPROVED_SPENDERS`\n\n— Whitelist of addresses that can receive token approvals. Your agent can't approve a random contract.`APPROVE_TIER_OVERRIDE`\n\n— Forces approval transactions into a higher security tier regardless of amount. Useful when you want human review on all approvals.**Contract and method controls:**\n\n`CONTRACT_WHITELIST`\n\n— Default-deny contract call whitelist. Your agent can only interact with contracts you've named.`METHOD_WHITELIST`\n\n— Allowed function selectors. You can permit `swap()`\n\non Jupiter while blocking `withdrawAll()`\n\non the same protocol.**Network and address controls:**\n\n`WHITELIST`\n\n— Allowed recipient addresses for transfers.`ALLOWED_NETWORKS`\n\n— Restricts the agent to specific chains. An Ethereum agent has no business touching Solana, and vice versa.**Rate and time controls:**\n\n`RATE_LIMIT`\n\n— Maximum transactions per period (hourly, daily).`TIME_RESTRICTION`\n\n— Allowed hours of operation. Your trading agent doesn't need to execute at 3am.**DeFi-specific controls:**\n\n`LENDING_LTV_LIMIT`\n\n— Maximum loan-to-value ratio for lending positions. Prevents your agent from over-leveraging a lending position.`LENDING_ASSET_WHITELIST`\n\n— Allowed assets for lending protocols.`PERP_MAX_LEVERAGE`\n\n— Maximum leverage for perpetual futures positions on Hyperliquid and similar protocols.`PERP_MAX_POSITION_USD`\n\n— Maximum position size in USD.`PERP_ALLOWED_MARKETS`\n\n— Approved markets for perpetual trading.`VENUE_WHITELIST`\n\n— Allowed trading venues across protocols.`ACTION_CATEGORY_LIMIT`\n\n— Caps on DeFi action categories.**Protocol-specific controls:**\n\n`X402_ALLOWED_DOMAINS`\n\n— Whitelist for x402 HTTP payment domains. Your agent can auto-pay API calls, but only to domains you've approved.`ERC8128_ALLOWED_DOMAINS`\n\n— Allowed domains for ERC-8128 HTTP signing.`REPUTATION_THRESHOLD`\n\n— Minimum ERC-8004 onchain reputation score required for agent interactions.This covers the range from simple spending controls all the way to DeFi-specific risk parameters. You don't have to use all 21 — but they're there when you need them.\n\nHere's what the token whitelist looks like in practice:\n\n```\ncurl -X POST http://localhost:3100/v1/policies \\\n  -H 'Content-Type: application/json' \\\n  -H 'X-Master-Password: <password>' \\\n  -d '{\n    \"walletId\": \"<wallet-uuid>\",\n    \"type\": \"ALLOWED_TOKENS\",\n    \"rules\": {\n      \"tokens\": [\n        {\n          \"address\": \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\",\n          \"symbol\": \"USDC\",\n          \"chain\": \"solana\"\n        }\n      ]\n    }\n  }'\n```\n\nIf your agent tries to transfer any token not on this list, the daemon returns a policy denial before the transaction is ever signed:\n\n```\n{\n  \"error\": {\n    \"code\": \"POLICY_DENIED\",\n    \"message\": \"Transaction denied by SPENDING_LIMIT policy\",\n    \"domain\": \"POLICY\",\n    \"retryable\": false\n  }\n}\n```\n\nThe agent gets a structured error it can handle. The transaction never leaves your node.\n\nThe third layer handles the APPROVAL tier — transactions that exceed your defined thresholds and require a human decision. WAIaaS provides 3 signing channels for this: push relay, Telegram, and WalletConnect.\n\nWhen a transaction hits the APPROVAL tier, it's queued. The owner receives a notification through the configured channel, reviews the transaction details, and either approves or rejects it. The daemon holds the transaction in the pipeline until that decision arrives.\n\n```\n# Approve a pending transaction (ownerAuth)\ncurl -X POST http://127.0.0.1:3100/v1/transactions/<tx-id>/approve \\\n  -H \"X-Owner-Signature: <ed25519-or-secp256k1-signature>\" \\\n  -H \"X-Owner-Message: <signed-message>\"\n```\n\nApproval requires a valid owner signature — the kind that comes from a hardware wallet or mobile signing app, not from the daemon itself. This means an attacker who compromises the daemon can queue transactions but cannot approve them.\n\nBefore any transaction reaches a network, it passes through a 7-stage pipeline: validate → auth → policy → wait → execute → confirm. The policy stage is where your 21 policy types are evaluated. If any policy returns a denial, the pipeline stops there. The transaction never reaches the execute stage.\n\nThis sequential architecture means policies aren't advisory — they're enforced at the infrastructure level, not in your application code.\n\nOne more safety mechanism worth knowing about: the dry-run API. Before committing any transaction, your agent can simulate it to see what would happen:\n\n```\ncurl -X POST http://127.0.0.1:3100/v1/transactions/send \\\n  -H \"Content-Type: application/json\" \\\n  -H \"Authorization: Bearer wai_sess_<token>\" \\\n  -d '{\n    \"type\": \"TRANSFER\",\n    \"to\": \"recipient-address\",\n    \"amount\": \"0.1\",\n    \"dryRun\": true\n  }'\n```\n\nThe simulation runs the full pipeline — including policy evaluation — without broadcasting to the network. Your agent can check whether a transaction would be approved, denied, or queued before actually submitting it. This is useful for pre-flight validation in agent logic and for testing policy configurations without real funds.\n\n**Step 1: Start the daemon**\n\n```\nnpm install -g @waiaas/cli\nwaiaas init\nwaiaas start\n```\n\n**Step 2: Create a wallet**\n\n```\ncurl -X POST http://127.0.0.1:3100/v1/wallets \\\n  -H \"Content-Type: application/json\" \\\n  -H \"X-Master-Password: my-secret-password\" \\\n  -d '{\"name\": \"trading-wallet\", \"chain\": \"solana\", \"environment\": \"mainnet\"}'\n```\n\n**Step 3: Set a spending limit policy**\n\n```\ncurl -X POST http://127.0.0.1:3100/v1/policies \\\n  -H \"Content-Type: application/json\" \\\n  -H \"X-Master-Password: my-secret-password\" \\\n  -d '{\n    \"walletId\": \"<wallet-uuid>\",\n    \"type\": \"SPENDING_LIMIT\",\n    \"rules\": {\n      \"instant_max_usd\": 100,\n      \"notify_max_usd\": 500,\n      \"delay_max_usd\": 2000,\n      \"delay_seconds\": 900,\n      \"daily_limit_usd\": 5000\n    }\n  }'\n```\n\n**Step 4: Create a session for your agent**\n\n```\ncurl -X POST http://127.0.0.1:3100/v1/sessions \\\n  -H \"Content-Type: application/json\" \\\n  -H \"X-Master-Password: my-secret-password\" \\\n  -d '{\"walletId\": \"<wallet-uuid>\"}'\n```\n\n**Step 5: Your agent checks balance and operates within policy**\n\n```\ncurl http://127.0.0.1:3100/v1/wallet/balance \\\n  -H \"Authorization: Bearer wai_sess_eyJhbGciOiJIUzI1NiJ9...\"\n```\n\nFrom this point, the session token is the only credential your agent holds. Everything above the $100 instant threshold requires your attention. The agent operates within defined parameters, and you get notified or asked for approval on anything that exceeds them.\n\nThe policy engine is documented interactively at `http://127.0.0.1:3100/reference`\n\nonce your daemon is running — it's an OpenAPI 3.0 spec with a live Scalar UI where you can explore all 39 route modules and test requests directly. If you want to dig into the architecture before deploying, the codebase is fully open source and the monorepo structure (15 packages) makes it readable without needing to understand everything at once.\n\nStart with the GitHub repo to review the security model before running anything in production: [https://github.com/minhoyoo-iotrust/WAIaaS](https://github.com/minhoyoo-iotrust/WAIaaS). Full documentation and the hosted version are at [https://waiaas.ai](https://waiaas.ai).", "url": "https://wpnews.pro/news/complete-ai-agent-lockdown-21-policy-types-for-maximum-security", "canonical_source": "https://dev.to/walletguy/complete-ai-agent-lockdown-21-policy-types-for-maximum-security-4a6f", "published_at": "2026-07-13 15:49:34+00:00", "updated_at": "2026-07-13 16:16:46.161334+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-infrastructure", "ai-products", "developer-tools"], "entities": ["WAIaaS", "Argon2id", "JWT HS256", "SIWS", "SIWE", "WalletConnect", "Telegram", "Push"], "alternates": {"html": "https://wpnews.pro/news/complete-ai-agent-lockdown-21-policy-types-for-maximum-security", "markdown": "https://wpnews.pro/news/complete-ai-agent-lockdown-21-policy-types-for-maximum-security.md", "text": "https://wpnews.pro/news/complete-ai-agent-lockdown-21-policy-types-for-maximum-security.txt", "jsonld": "https://wpnews.pro/news/complete-ai-agent-lockdown-21-policy-types-for-maximum-security.jsonld"}}