AI agents with unlimited wallet access can drain funds. ERC-7715 fixes this with granular, time-limited spending controls.
Your AI agents are spending your money. You should be able to control that.
AgentLeash prevents runaway AI agents from draining your wallet. Instead of giving agents full custody of funds, you give them limited permission to spend from your wallet only within rules you approve. Limits can be amount based time based and purpose based.
The agent never holds your funds.
What problem this solves
Many AI agents today use hot wallets. Once funded they can spend everything instantly if something goes wrong. Bugs bad prompts or malicious logic can wipe a wallet in seconds.
AgentLeash replaces custody with permission.
How it works in simple terms
Unsafe setup
You send funds to an agent wallet
The agent can spend freely
Risk is unlimited
AgentLeash setup
You grant a spending permission from your wallet
The agent signs transactions
Your wallet pays only if the transaction matches your rules
Risk is capped and controllable
Key idea
Funds always stay in your wallet
The agent only has permission not ownership
Your wallet holds all funds
You grant an ERC 7715 permission
The agent wallet can sign transactions but has zero balance
Transactions execute only if they match the permission
All activity is indexed in real time for monitoring
Tech stack
Frontend uses React TypeScript and Vite
Wallet connection via RainbowKit and Wagmi
Permissions via ERC 7715 and ERC 7710
Indexer uses Envio HyperIndex
Runs on Sepolia and Base Sepolia testnets
Smart contracts written in Solidity using Foundry
Important notes
Only works with MetaMask Flask for now
Testnet only at the moment
Agents can never drain your wallet beyond the limits you set
What AgentLeash means
Limiting Expenditure for Autonomous Spending Hierarchies
AI agents should act like employees with spending limits not like gods with your private keys
During the hackathon I spent most of the time integrating real infra rather than polishing features. ERC 7715 permissions were flexible but required careful handling. Supporting different permission types meant branching logic, and the response structure was not always consistent, so extracting things like the agent or grantee address required checking multiple paths. Delegated execution worked in some cases but not consistently across chains. To keep things moving, I added a fallback to direct execution when delegation failed, which made the agent more reliable overall. Multi chain support introduced practical differences. Some chains had Aave support while others did not, so vault strategies and contract addresses had to be handled per chain. Base Sepolia in particular needed alternative logic. Indexer connectivity also needed extra care. I added retries, timeouts, and explicit CORS configuration to get stable reads from the indexer. Finally, permission storage required defensive parsing. The Smart Account response format was not always predictable, so local tracking relied on extracting the agent wallet from multiple possible fields. Overall, the project was a good exercise in building against real world assumptions and adapting quickly as those assumptions changed.
pre-funding