An AI agent security checklist is a list of yes/no checks a team completes before an agent can move money, so that each risk has a named control and an owner before launch rather than after an incident. The checklist below has 15 items in six groups: keys, tools, limits, approvals, testing, and shutdown. Every item should be a clear "yes" before the agent touches a funded wallet.
​

The checks draw on the OWASP AI Agent Security Cheat Sheet, OWASP's LLM01:2025 prompt injection guidance, and wallet-level documentation. They are ordered the way a launch review runs: start with where the key lives, end with how to stop the agent. For deeper treatment of individual controls, the checklist links out instead of repeating them.
​

Key facts at a glance:

Before giving an agent funds, confirm the key is outside the agent's reach, the agent has only the tools its task needs, hard limits cap every transaction, a human approves anything above those limits, the setup passed adversarial tests on a fork, and someone can stop the agent and revoke its permissions within minutes.
​

The full checklist:
​

The sections below explain why each group matters and what a "yes" looks like in practice.
​

The key should live where the agent cannot read it. An agent running as a user can read whatever that user can read, including wallet files and password sources, so isolation must be by machine, account, or signing service. Where the agent must sign, a small dedicated hot wallet caps the loss.
​

Eco's Sauce security notes spell out why this is item 1. A coding agent's shell commands, and any MCP server it starts over stdio, run under the user's account. Such an agent can read the key files and every password source the account reads, sign through paths that skip the spending policy, and edit the policy file itself. The guidance for wallets the command creates is direct: these are hot wallets, keep small balances in them.
​

A "yes" on items 1 to 3 usually means one of two setups. Either the agent builds unsigned transactions and a separate wallet signs, or the agent signs from a dedicated wallet on a separate machine or account, funded with only what it needs this week. Eco's agent wallets guide compares custody models.
​

Grant each agent the smallest tool set for its job. A research agent needs read tools, not send tools. A payment agent needs a send tool scoped to its task. Every tool that can move funds or grant allowances is a path an injected instruction can take, so remove tools rather than relying on the model to ignore them.
​

The OWASP cheat sheet asks for per-tool permission scoping (read-only vs write), separate tool sets for different trust levels, and explicit authorization for sensitive operations. It also lists what not to do: give agents unrestricted tool access or wildcard permissions.
​

For MCP-based agents, the server's own flags often decide the tool set. The Sauce agent docs, for example, state that a server started with --no-wallets --no-stores lists 18 tools while the default stdio server lists 27, the difference being wallet and Pot tools. Counting the tools an agent sees is a fast audit of item 5.
​

Set limits outside the model at three levels: the wallet (per transaction and per day), the account (permissioned sub-keys or allowances), and the transaction (bounds checked at execution). Each level catches a different failure. Spend controls are covered in depth in Eco's AI Agent Spend Controls article; this checklist only asks that they exist.
​

Item 7 is the familiar one, and Eco's AI Agent Spend Controls compares the options, from one-time tokens to programmable allowances. At the account level, the EIP-7702 specification describes sub-keys with weaker permissions, such as spending a token but not ETH, or interacting only with one application.
​

Item 8 is the in-transaction layer. Eco's Sauce SDK lets an operator write how much the agent can spend, what it must receive, and where funds may go into the transaction itself, so the transaction reverts if any bound fails at execution. It sends on Ethereum, Base, Arc, and Solana. A program enforces only the conditions written into it, per the Sauce docs, so the bounds must come from the operator's config, not from the model.
​

Item 9 closes a gap the other two miss. An allowance granted today can be spent in a later transaction, and Revoke notes a contract with permission to spend tokens can spend them at any time.
​

Approval rules should be written down before launch: which amounts, recipients, or actions need a human, and how approvals bind to exact parameters. Testing should include deliberate attacks, such as injected instructions in fetched content, and confirm the agent produces denials. A setup nobody has tried to break is untested.
​

For approval design, see Human Approval for AI Agent Transactions. The checklist asks only that the rule exists and blocks by default when a check fails.
​

For testing, the OWASP cheat sheet recommends adversarial test suites in CI/CD, regression tests for previously observed injection and tool-abuse failures, and retained evidence of the approval, denial, timeout, or circuit-breaker behavior observed. Run those tests against a fork or simulator, never a funded wallet. Transaction Simulation Tools Compared lists options; the Sauce agent docs note that compiling and simulating need no funded wallet. For injection test cases, see Prompt Injection Attacks on AI Agents That Hold Funds.
​

Before launch, a named person should be able to stop the agent, cut its signing access, and revoke outstanding allowances, and should have practiced doing it. Logs should be detailed enough to reconstruct what the agent decided and why. A kill switch that has never been tested is an assumption, not a control.
​

The steps and their limits are covered in AI Agent Kill Switch: Stopping an Agent Before It Moves Money. For logging, OWASP lists structured fields for high-risk actions: action classification, authorization outcome, approval identifier, execution result, and policy version. It also warns against logging credentials or personal data in plain text.
​

Run the checklist as a meeting with evidence, not a self-assessment. For each of the 15 items, the agent's owner shows the config, log, or test result that makes it a "yes." Any "no" blocks launch until fixed or formally accepted as residual risk with a compensating control, named and dated.
​

Three practices make the review stick:

Teams that already run security reviews for payment code can fold this list into that process. The difference with agents is item 13: the reviewer should see the agent attacked, not just configured.
​

A checklist confirms controls exist; it does not prove they work under pressure. Items can pass on paper and fail in practice, limits can be set too high to matter, and new tools can be added after launch without a re-review. Re-run the checklist on every change to tools, limits, models, or signing setup.

These are short answers to the questions developers and operators ask most often about securing an AI agent before it gets access to funds. Each answer stands on its own and points to the primary documentation used in this article, retrieved in November 2026, for readers who need the full detail.
​

Only its working balance for a short period, refilled by a separate process. The loss from any single failure is then capped at that balance.
​

No. A limit caps loss per transaction or day but does not stop many small bad transfers, a wrong recipient, or an unlimited approval. Combine limits with destination allowlists and approvals.
​

One named person per agent, usually the engineer responsible for its deployment, with sign-off from whoever owns the funds.
​

On every change to tools, limits, model version, or signing setup, and on a fixed schedule even when nothing changed.
​

Yes. The checks are framework-neutral. Eco's guides to Solana Agent Kit and ElizaOS cover framework specifics.
​

Retrieved November 9 2026: OWASP AI Agent Security Cheat Sheet, OWASP LLM01:2025, EIP-7702, Revoke, Tenderly docs, and Eco's Sauce launch post, agent docs, wallet policy docs, and security considerations.
​

Related reading: AI Agent Spend Controls, Security Risks of Autonomous AI Agents, Human Approval for AI Agent Transactions, AI Agent Kill Switch, Prompt Injection Attacks on AI Agents, Agent Wallets, AI Agent Wallets: ERC-4337 + ERC-8004, ERC-7715 Wallet Permissions.
​