AgentVault
Everyone is building AI agents that can trade. Almost nobody is building the part that stops them. AgentVault is agent permission and risk infrastructure on Robinhood Chain. A Genesis Agent NFT owns an isolated smart account governed by a deterministic risk engine the agent cannot override — the AI proposes, code decides. Live on testnet: five verified contracts, 126 tests, and no admin key anywhere in the system.
Videos
Tech Stack
Description
AgentVault — the deterministic risk layer an AI agent cannot override
In July, Robinhood launched its own chain, and part of what shipped were Agentic Accounts — a way to wire AI models directly into trading infrastructure. That is where the whole space is heading, and it raises a question with no good answer today: when an agent can move money, what stops it?
Right now, mostly prompt engineering and hope. The model is instructed not to do anything catastrophic, and everyone proceeds as if instructions were constraints. They aren't. A model that misreads its context, gets prompt-injected through market data, or simply produces malformed output has nothing structural standing between it and the account.
Most approaches to this problem validate what the agent asks for. AgentVault changes what the agent is able to ask.
The agent's entire vocabulary is one data structure with five fields: an asset, a direction, a size, a maximum slippage, and the timestamp of the market data behind it. There is no field for a contract address to call, no field for calldata, no field for a recipient, no field for a token approval. An agent that wanted to drain an account could not encode the attempt — not because validation catches it, but because the type has nowhere to put it.
Everything that can be expressed then passes through a deterministic validator. Not a model. Code. The risk engine's validate function is a pure view function with no storage, no access control, no admin and no pause. Anyone may call it, because calling it changes nothing. It checks the holder's kill switch before it checks anything about the trade, then mandate limits, asset allowlist, position cap, slippage and data freshness — and it returns a named reason rather than a bare revert. A revert says something failed. A reason code says which rule stopped it, which is what makes a rejection legible, recordable and honest.
Three further design choices, each enforced rather than promised.
No contract in this system has an owner, an admin, or a role-gated function. Not one. The asset allowlist is fixed at deployment with no setter. There is no privileged key to lose, leak or subpoena.
Withdrawal has no pause check on any code path. The kill switch stops automation and can never stop a holder reaching their own funds. That asymmetry is the difference between a safety feature and a hostage situation.
Collectible rarity cannot touch financial risk. The risk engine depends on an interface that cannot see an NFT's archetype at all, so a rare agent structurally cannot receive a higher limit.
The demo is ninety seconds, running live against deployed contracts. A proposal inside every limit is approved. A proposal over the position cap is rejected by name — MaxPositionExceeded. The holder then flips the kill switch in one transaction, and the identical proposal from earlier, same asset and same size and same slippage, comes back rejected as AutomationPaused. Nothing about the trade changed. Only the holder's instruction did, and the agent has no path to that switch.
What is built: 126 tests passing from a clean clone, including four stateful-fuzz invariants that assert withdrawal stays available in every reachable state and that a deposit can never be reported as profit. Static analysis with Slither finds five items in project code, zero high and zero medium, each triaged in the repository. Five contracts are deployed and source-verified on Robinhood Chain testnet, chain ID 46630, which was measured rather than read from documentation after two sources disagreed.
Paxos USDG is on the risk engine's asset allowlist at 0x7E955252E15c84f5768B83c41a71F9eba181802F, so proposals denominated in USDG are validated against mandate limits. That address came from Paxos first-party documentation and was then confirmed on chain, because explorer search on this testnet returns more than fifty tokens claiming to be USDG, five of them named literally Paxos USDG. The allowlist has no setter, so sourcing it from search would have baked an impostor in permanently.
You can try the risk engine yourself at markantpacheco.github.io/agentvault. Build a proposal, send it to the deployed contract, and get back an approval or a named rejection. There is no wallet to connect and nothing to sign, because validate is a pure view function. Set the size to 1999 and watch MaxPositionExceeded come back from chain 46630.
Who this is for: agent developers who need permission scaffolding they didn't write themselves, and capital allocators who need a record of what an agent really did — including the losses and the trades that were refused. Today the only evidence a strategy works is a screenshot, and screenshots are free to fabricate. The record here is append-only, includes rejections, and travels with the NFT when it's sold.
Where this honestly is: early. No users and no real capital. The web page is a read-only window onto the risk engine, not a product — no accounts, no wallet connection, no write path, because nothing in this system executes a trade.
Not a fund. No custody. No advice on securities. No claim the system cannot lose money — it can.
The repository documents every major decision, its cost, and what would reverse it. The assumptions register separates verified from unverified from blocking, and includes a corrections log of assumptions that turned out wrong — including a test count this project reported, caught, and corrected downward before anyone asked. That discipline is the actual product: a performance record is only worth something if the project keeping it doesn't overstate things.