NANNY

Nanny gives your AI agent an allowance instead of your wallet: a vault on Monad whose spending rules a smart contract enforces. The agent never holds funds it can only ask the vault to pay, and the vault decides. The allowance trickles in per second and is capped, so a fooled agent reaches only what has accrued, never the balance. A per-tx limit bounds any single payment; an allowlist decides who may be paid. Every spend also writes the agent's reason on-chain. In the demo, a real LLM believes a forged merchant record and tries to pay an attacker. The contract refuses. WHAT PROBLEM DOES IT SOLVE? People hand AI agents jobs that spend real money, and there is no safe way to do it. A wallet gives all-or-nothing authority: everything, anywhere, forever. And an LLM can be talked into anything prompt injection isn't a bug someone will fix, it's what these models are. Limits in the app don't survive: they live in the same program the attacker just persuaded. Nanny moves them where the agent cannot argue. It stays exactly as gullible it just can't act on it. WHAT DID YOU LEARN? Three things, each shipped wrong first. 1. GUARD ORDER IS A PRODUCT DECISION. Spend checks the allowlist and per-tx cap before settling the allowance. Reversed, a poisoned payment dies with "insufficient allowance" true, and the wrong story. Revert strings are an API; guard order is what it means. 2. DERIVING STATE FROM A COUNTER IS A RACE THAT HIDES. A new vault's ID as counter-minus-one was correct while one key made every vault; with real wallets, two people opening one in the same block read the same counter. The event is the tx's own output; concurrency didn't add the bug, it stopped hiding it. 3. AN ACCESS CHECK IS ONLY WORTH THE IDENTITY BEHIND IT. Signing owner actions with one shared server key gave every vault the same owner, so the check passed for everybody. The contract was never wrong; the identity feeding it was.