Before a crypto AI Agent launches on mainnet, there's a security checklist that cannot be skipped. This isn't 'best practice suggestions' — it's the baseline requirement of 'if you haven't done these, your Agent should not touch real funds.' This article breaks 12 mandatory items into four categories, explaining why each is needed and how to verify it has been correctly implemented.
Many developers think 'launch first, fix problems when they appear' — acceptable in ordinary web applications, fatal in crypto Agents. The reason is simple: on-chain transactions are irreversible. Once funds are transferred, there's no 'undo' button. A single security incident's losses can far exceed an entire development cycle's costs. More importantly, crypto Agent attackers are motivated and technically capable, and will start scanning for vulnerabilities the day you launch. Preventive security design costs far less than post-incident loss remediation.
Item 1: No private keys exist in any plaintext location. Check all environment variables, configuration files, and code repository history (including Git history) — confirm no private keys, mnemonics, or equivalent signing credentials exist in plaintext. Scan code history with git log with grep for private/mnemonic/seed keywords. If plaintext keys have ever entered Git history, even if later deleted, that repository should be treated as compromised and all keys rotated. Item 2: Agent wallet and primary asset wallet are completely isolated. The Agent's operations wallet holds only a few days of working capital and cannot share the same wallet as primary assets. Item 3: ERC-20 approvals have precise limits — not unlimited authorization (type(uint256).max). Item 4: Agent's System Prompt contains no credentials. LLM System Prompts can be extracted via Prompt Injection. Item 5: Private key storage uses secure solutions — AWS Secrets Manager, HashiCorp Vault, or AWS Nitro Enclaves, not system environment variables or `.env` files.
Item 6: All read/write tools strictly classified. Confirm write tools are not called directly after reading unvalidated external data — there must be a human confirmation or parameter validation step between reading external data and triggering write tools. Item 7: All write tools have backend parameter validation. Don't rely solely on LLM reasoning output to determine whether to execute write operations. Validate amount limits, address whitelists, and operation types in backend code the LLM cannot bypass. Item 8: Tool return data has Schema validation. All tool returns, especially from MCP Servers or external APIs, must be validated for format and numerical plausibility before entering the LLM Context. Item 9: High-value operations have independent confirmation channels. Any write operation above your configured threshold (e.g., $100) must pass through a confirmation channel completely independent of the LLM reasoning layer before backend execution.
Item 10: Daily spending limit circuit-breaker. Set a maximum total daily spend the Agent can trigger. Exceeding this limit automatically pauses all subsequent write operations and notifies you until you manually reset. This circuit-breaker executes at the backend code level, not overrideable by Agent reasoning. Item 11: Market anomaly circuit-breaker. Set market condition thresholds (asset drops >X% in 15 minutes, Gas exceeds X times normal, DEX slippage >X%, etc.). Any trigger automatically pauses all write operations and sends emergency notification. Item 12: Complete operation logging system. Four layers: LLM reasoning logs, tool call logs, decision authorization logs, on-chain execution logs. Encrypted storage with minimum 90-day retention.
After completing design and implementation of the 12 items, verify with this cadence: Week 1 — run complete functional testing on testnet (Sepolia or Base Sepolia), including actively triggering all circuit-breakers and attempting to trigger Schema validation with anomalous tool returns. Week 2 — behavior verification with small real funds ($20–$100) on mainnet, confirming testnet and mainnet behavior are consistent. Week 3 onward — gradually expand authorized amounts, observing at least one week of normal behavior before each expansion. Whenever you're unsure how the Agent will behave in an edge case, return to testnet to validate first. Mainnet 'uncertainty cost' is many times that of testnet.
These 12 items are not an optional checklist but the minimum requirement before 'your Agent should manage funds you cannot afford to lose.' If time pressure tempts you to skip some, ask yourself: 'If an attacker discovers and exploits this vulnerability on launch day, what's the worst loss?' If that number exceeds what you can accept, that item cannot be skipped.