Moving an Onchain Agent from testnet to production is an irreversible moment — once the Agent starts operating real funds, any security design gaps can cause losses before you realize it.
This article provides a complete production deployment security checklist divided into five categories: code security, wallet and private key security, tools and API security, Agent reasoning security, and runtime monitoring and incident response. This checklist isn't best practice recommendations — it's the minimum baseline where missing any single item creates security risk. Before your Agent enters production deployment, each item should be explicitly confirmed.
Code security is the foundation of all security design — if there are problems at the code level, other security designs may all fail. Code Security Checklist (8 items):
1. .env file added to .gitignore — search the entire Git history for private key and API Key formats to confirm no leakage. If .env was ever uploaded to GitHub, even if deleted, old commits can still be found — immediately rotate all related private keys and API Keys.
2. All sensitive credentials read through environment variables — confirm no addresses or private keys are hardcoded in code; confirm no API Keys are hardcoded.
3. Dependency security confirmed — run pip audit (Python) or npm audit (Node.js) to confirm no dependencies with known vulnerabilities. Pay special attention to Web3 library versions.
4. All write tool functions have unit tests — every tool function that can trigger on-chain operations must have tests covering normal execution and edge conditions (amount over limit, address not on whitelist, Gas fee over budget).
5. Tool function error handling doesn't leak sensitive information — error messages don't contain private key fragments, API Keys, or system paths.
6. All tool calls have timeout settings — external API calls have explicit timeouts set (e.g., 10-30 seconds), preventing Agent from infinitely waiting.
7. Code passes linter and static analysis — use flake8 or pylint; use bandit to confirm no common security issues.
8. Deployment config files reviewed — confirm no debug mode, no unnecessary ports exposed, container doesn't run as root.
Wallet design determines the maximum possible loss even if code has problems. Wallet Security Checklist (8 items):
9. Operations wallet and fund wallet completely separated — operations wallet holds only small amounts of ETH for Gas (recommended under $50 ETH); major funds in Safe multi-sig address.
10. Safe multi-sig correctly configured — threshold set to 2-of-N; operations address is one Signer; guardian address is a completely offline cold wallet; tested manually triggering one Safe transaction.
11. Private key storage meets production security standards — not acceptable: private key in code or plaintext .env; personal computer .env files. Acceptable: encrypted environment variables on Railway/Heroku; AWS Secrets Manager or HashiCorp Vault.
12. ERC-20 approvals set with reasonable limits — no unlimited approvals; approval amounts not exceeding planned operation maximum × 1.5; periodically reviewing and revoking on Revoke.cash.
13. Operations wallet Gas replenishment mechanism designed — auto-replenishment logic when Gas falls below threshold; replenishment amount ceiling set.
14. Guardian address private key storage and management — stored in hardware wallet (Ledger/Trezor); backup mnemonic in secure offline location; tested signing one Safe transaction from guardian address.
15. All testnet operations completed on testnet — complete run of all functions on Sepolia or Base Sepolia before switching to mainnet.
16. Initial production deployment has capital limit — first two weeks: set capital at 10-20% of planned final amount; confirm Agent behavior matches expectations before increasing.
The tool layer is the Agent-external world boundary and most common Prompt Injection entry point. Tool Security Checklist (7 items):
17. Read and write tools clearly separated — clear naming conventions; LangGraph graph path from read to write node must pass validation node.
18. All write tools have backend secondary validation — target address whitelist check, operation amount ceiling check, operation type permission check — hard-enforced at code level.
19. Tool whitelist locked down — System Prompt lists only whitelisted tools; non-whitelisted tool calls return error directly.
20. Tool return data has reasonability filtering — range validation: stablecoin APY above 30% is anomalous; anomalous values don't enter LLM Context.
21. External APIs have fallback mechanisms — backup data source for each critical API; auto-switch when primary fails; circuit break when backup also fails.
22. MCP tool sources verified (if used) — only use MCP Servers from trusted sources; don't use unreviewed third-party MCP Servers.
23. API Key permissions minimized — only necessary API methods enabled; rotate API Keys regularly (recommend every 3 months).
Reasoning security ensures LLM behavior stays within designed boundaries. Reasoning Security Checklist (6 items):
24. System Prompt contains complete grounding rules — all cited values must come from tool returns; tool failure means abort cycle and declare data missing.
25. System Prompt contains strategy boundary declarations — whitelist of protocols, token types, max operation amount, no non-whitelisted operations.
26. Backend numerical consistency validation implemented — deviation above 5% triggers P1 alert; above 30% triggers P0 and operation block.
27. Maximum loop count set — hard ceiling of 10-20 Thought-Action cycles per task; auto-terminate and alert when exceeded.
28. Context utilization monitoring enabled — above 70% triggers compression; above 90% force-terminates current task.
29. Human confirmation mechanism tested — Telegram Bot confirmation flow tested end-to-end; timeout behavior tested (cancel operation, not default execute).
Incident response is designed and rehearsed before problems occur, not started when they do. Incident Response Checklist (6 items):
30. Emergency stop mechanism designed and tested — mechanism to immediately stop all Agent operations (e.g., specific Telegram command or environment variable); completable within 30 seconds; rehearsed on testnet.
31. ERC-20 approval revocation flow prepared — knows how to quickly revoke all approvals on Revoke.cash; revoking approvals is one of the fastest ways to prevent further losses.
32. Post-incident log review flow defined — knows which log to check first; has an incident timeline recording template.
33. Guardian address holder knows their responsibilities — knows when to refuse signing Safe transactions; knows how to contact you to confirm.
34. Written emergency contact and operations list — prepared assuming worst case: no computer, only a phone.
35. Monthly simulated incident drill — once a month, 15-30 minutes simulating an emergency scenario; confirm each step executes smoothly.
The 35 items aren't bonus points for doing more — they're the minimum baseline where any missing item creates specific security risk. Each should have an explicit 'completed' or 'consciously skipped with understood risk' answer.
Three most commonly skipped items: Safe multi-sig ('too complicated, deal with it when capital is larger'); simulated incident drills ('deal with real problems when they come'); written emergency operations guide ('all in my head'). These three aren't the most technically complex, but in real emergency scenarios they often determine the difference between loss controlled and loss uncontrolled.