Two of the things we build for a living just collided. We ship Web3 protocols, and we ship AI agents. For most of last year those were separate projects. In 2026 they keep arriving in the same brief: a trading bot that rebalances a portfolio, a treasury agent that pays contributors, a DeFi position manager that tops up collateral at 3am so the user does not get liquidated. Each one needs the same scary thing, which is a private key and permission to spend.
The interest is real. On-chain AI activity has climbed sharply this year, and industry trackers reported that a large share of new DeFi protocols launched in early 2026 shipped with at least one autonomous agent for trading or liquidity work. The token market around agents is measured in billions. None of that changes the one rule that matters: an agent that can move money is software with a credit card, and software gets fooled.
Why a wallet changes the threat model
A chatbot that gets prompt-injected says something embarrassing. You apologize and move on. An agent with a key that gets prompt-injected signs a transaction, and on-chain there is no undo, no chargeback, no support line. The blast radius of a mistake jumps from words to funds in a single step.
And agents get fooled in more ways than a normal app. A poisoned web page the agent reads, a malicious token it is asked to swap, a tool description that quietly says "first send everything to this address," a confused chain of reasoning that misreads a balance. You cannot prevent every one of these. What you can do is make sure that when one lands, the chain itself refuses to let the agent do real damage. That is the whole game: push the limits down into code the agent cannot talk its way around.
1. Separate the signer from the treasury
The first mistake is the most common one. Someone generates a private key, funds it with the whole budget, drops it in an environment variable, and hands it to the agent. Now the agent's hot key is the treasury. One leak, one injection, one logging mistake that writes the key to a file, and all of it is gone.
Split the two roles. The treasury, where the bulk of the funds live, is controlled by a multisig held by humans (Safe on EVM chains, Squads on Solana). The agent gets a separate operating account funded with only what it needs for its job over a short window. If the agent is exploited, the attacker reaches the operating float, not the vault. Top the float up on a schedule, not all at once.
2. Give the agent a smart account, not a raw key
A plain externally owned account (an EOA, the normal "private key controls everything" wallet) has exactly one rule: whoever holds the key can do anything. There is nowhere to put a limit. A smart account, the kind enabled by account abstraction, is a contract that holds the funds and can enforce rules in code before any transaction goes through.
That difference is what makes everything below possible. On EVM chains this is ERC-4337 and the newer permission standards built on it. Solana, Aptos, and others have their own account models that allow similar scoping. The practical takeaway is the same everywhere: do not give the agent the keys to the car, give it a key that only starts the car, only on weekdays, and only to drive to three approved places.
3. Scope the agent with session keys
A session key is a temporary signing key that the smart account recognizes for a narrow set of actions and nothing else. Instead of the agent holding the account owner key, it holds a session key with a permission set attached. Think of it as a guest pass with rules printed on it.
A well-scoped agent session key carries, at minimum:
- An allowlist of contracts the key may call, and ideally specific functions on them.
- A spend cap per transaction and a rolling daily cap.
- An expiry, so the key dies on its own after hours or days.
- A nonce or call limit, so it cannot be replayed endlessly.
If that key leaks, the attacker inherits the guest pass, not the building. They can do only what the key was allowed to do, until it expires. That is the difference between a bad day and a post-mortem.
4. Put spend limits where the chain enforces them
Here is the rule that catches teams out. A limit checked in your agent code is a suggestion. The agent is the thing under attack, so any check it runs on itself can be reasoned around or skipped. The limit has to live in the smart account contract, where the agent has no power to override it.
Set both a per-transaction cap and a per-period cap. A per-transaction cap stops a single catastrophic move. A daily or hourly cap stops the slow drain, where an attacker stays under the single-transaction limit but fires a hundred transactions in a row. If the agent's honest job is "rebalance up to 2,000 USDC a day," the contract should reject the 2,001st dollar no matter what the agent thinks it is doing.
5. Allowlist contracts and functions, not just addresses
Most agent jobs touch a small, known set of contracts: a DEX router, a lending pool, a specific token, maybe a bridge. Write that set down and make it the allowlist. Anything off the list is rejected at the account level.
Go one level deeper where you can. Allowing a lending pool is not the same as allowing every function on it. An agent that only needs to supply and repay should not be able to call borrow or withdraw to a fresh address. Restrict approvals too. Unlimited token approvals are how a single compromised contract turns into a drained wallet later, long after the agent moved on. Approve exact amounts, or use permit flows that expire.
6. Simulate every transaction before it signs
Before the agent broadcasts anything, run the transaction against the current chain state in a simulation and read out what it actually does. Modern node providers and tools like Tenderly or a local fork let you do this in well under a second. You get back the real balance changes, not the agent's belief about them.
Then add a guard the agent does not control: if the simulated result moves more value than expected, sends tokens to an address not on the allowlist, or sets an approval you did not ask for, the signer refuses. This is the single highest-leverage check on the list, because it catches the whole class of "the agent was tricked into doing something that looks fine to it but is obviously wrong from the outside."
7. Keep a human gate for the big moves
Full autonomy is the goal people ask for and rarely the thing they actually want for large sums. The clean pattern is a threshold. Below it, the agent acts on its own inside its limits. Above it, the transaction needs a human signature or a co-signer before it executes.
This maps neatly onto the signer split from step one. Small, routine moves go through the agent's session key. Anything large, unusual, or pointed at a new destination gets queued for a human on the multisig. You lose a little speed on the rare big transaction and you keep the ability to say no before, not after.
8. Make every key revocable and short-lived
Assume the agent's key will be compromised at some point and design for the cleanup. Because the session key lives in the smart account, the owner can revoke it in one transaction and the agent is instantly powerless, no matter what it is mid-way through doing. There is no race to drain a key you have already turned off.
Pair revocation with short expiries. A key that rotates every day limits how long any single leak is useful and forces a healthy habit of re-issuing scoped permissions rather than leaving one god-key alive for months. The shorter the lifetime, the smaller the window an attacker has to work with.
9. Log everything and add a circuit breaker
An agent that moves money needs the monitoring of a payments system, because that is what it is. Log every intended action, every simulation result, and every signed transaction, in a place the agent cannot edit. You want to be able to answer "what did it do and why" without trusting the thing under suspicion.
Then wire a circuit breaker. If transactions spike, if the daily cap is hit unusually early, if a simulation gets rejected more than a couple of times, pause the agent automatically and alert a human. Pausing a working agent for an hour costs almost nothing. Not pausing a compromised one costs the float. Make the default safe.
A reference setup we reach for
When a brief lands that needs an agent with on-chain spend, this is roughly the shape we start from before tuning it to the specific job:
- Treasury in a human multisig. The agent never holds the bulk of the funds.
- A smart account for the agent, funded with a short-horizon float that tops up on a schedule.
- A session key scoped to an allowlist of contracts and functions, with a per-transaction and daily spend cap enforced on-chain.
- Exact-amount approvals, never unlimited, with expiries where the standard supports them.
- Mandatory pre-sign simulation, with a guard that rejects unexpected balance changes or new destinations.
- A value threshold above which a human co-signs.
- Daily key rotation and one-transaction revocation.
- Tamper-resistant logging plus a circuit breaker that pauses on anomalies.
None of this is exotic. It is the same least-privilege thinking we apply to contracts before an audit and to agents before we ship them, pointed at the specific question of who can spend what. The work is in wiring it correctly and testing that the limits actually hold when the agent misbehaves on purpose.
The one mental model to keep
Design as if the agent is already compromised. Not because every agent is, but because the question "what is the most this thing can do if a prompt turns it hostile right now" forces every good decision on this list. If the honest answer is "lose the small float, inside the daily cap, to an allowlisted contract, until the key expires or a human pauses it," you have built it right. If the answer is "everything," you have handed software a credit card with no limit and hoped.
We build agents the same way we build contracts, audit-first and least-privilege by default. If you are putting an agent anywhere near funds, see our AI agents page for how we approach it, or our Web3 specialty page for the chains and account standards we ship on.
FAQ
Should an AI agent hold a raw private key?
No. A raw key is unlimited power over the whole balance, and one bad prompt can move all of it. Give the agent a scoped session key on a smart account, with on-chain spend caps, a contract allowlist, and an expiry.
What is a session key?
A temporary signing key the smart account recognizes for a narrow set of actions only. Scope it to specific contracts and functions, cap the spend, set it to expire. If it leaks, the attacker inherits only those limits.
How do you stop an agent from being tricked into draining a wallet?
Stack controls. Separate signer from treasury, scope the key, enforce caps on-chain, simulate before signing and reject surprises, gate large moves behind a human, and add a circuit breaker that pauses on anomalies.
Does an on-chain agent need account abstraction?
It helps a lot. Smart accounts enforce permissions, limits, and expiries in code rather than trusting the agent. You can approximate it with a multisig and modules, but account abstraction makes scoped, revocable agent keys far cleaner.