Security model
Warden limits what an agent key can do with money. It is a seatbelt for agents that misbehave, get confused, or get their key stolen. This page is explicit about where that protection ends.
Version 0.1 is unaudited and deployed only to Base Sepolia. Do not use it to hold real value.
The parties#
| Party | Holds | Can |
|---|---|---|
| Owner | The owner key, usually in a browser or hardware wallet | Everything: set and revoke policies, approve, pause, withdraw, transfer ownership |
| Agent | Its own hot key, in the agent runtime | Spend within its policy, nothing else |
| Account contract | The funds and the policies | Enforces every rule on every action |
| This website, the SDK, the MCP server | Nothing | Read the chain and ask a key to sign |
No Warden server sits between an agent and its money. Taking the website down, or compromising it, does not change what an agent can spend; the worst a compromised dashboard can do is show an owner a misleading transaction to sign. Read the wallet's confirmation, which comes from your wallet, not from the page.
What the contract enforces#
- Only listed tokens move. A token without a limit cannot be spent by that agent at all.
- Per-payment and per-window caps, per token, in exact token units.
- An allowlist of recipients and contracts, and optionally of functions per contract.
- The recipient inside ERC-20 calldata is checked too, so allowlisting a token contract does not let the agent transfer it anywhere.
- Approvals and allowance increases count at their full amount, ERC-1363 variants included.
- Agents cannot call the account or the factory, so they cannot reconfigure themselves.
- Human approval above a per-token threshold, re-checked against the current policy when you approve.
- Validity dates and a pause that freezes every agent, approvals included, while the owner can still withdraw.
- Receipts with the hash of the policy in force, so spending can be audited against the exact rules.
- One evaluation path.
check,pay,callandapproveshare the same code, so the free check and the real payment cannot disagree.
What it does not protect against#
A leaked agent key still spends up to its caps#
If someone steals an agent key, they can do exactly what the agent could: spend up to the caps, to allowlisted recipients, until the window resets. They can do it again every window. The policy bounds the loss; it does not prevent it.
What to do: keep caps close to real usage, allowlist recipients instead of anyRecipient, use short windows, set an approval threshold, and watch the activity feed. When something looks wrong, pause first and investigate second. Then revoke the agent and register a new key.
An allowlisted recipient that misbehaves#
Warden checks where the money goes, not what happens there. If an allowlisted API provider overcharges, or an allowlisted contract has a bug, the agent can lose what it sends there within its caps. Allowlist the narrowest thing that works: a payment address rather than a router, a named function rather than any function.
Losing the owner key#
Whoever holds the owner key controls the account and can withdraw everything. There is no recovery and no second owner in v0.1. Use a hardware wallet for the owner, and use transferOwnership plus acceptOwnership to move to a new key before an old one is retired.
Approval fatigue#
The approval threshold only helps if a human reads the request. If requests arrive often, people approve without looking. Set the threshold where requests are rare and worth reading; the dashboard shows the amount, recipient, memo, time left, and whether the payment would pass if approved now.
Prices#
There is no price oracle. Caps and thresholds are in token units. A cap in ETH is worth a different dollar amount next week; a stablecoin cap is the easier one to reason about.
Things outside the account#
- Funds the agent key holds directly, outside the account, are not covered. Give the key only the ETH it needs for gas.
- An agent with access to other keys, as in the OpenAI incident of October 2026 where a model derived wallet keys from public seed phrases, can spend from those wallets. Warden governs the money you route through it; it cannot stop an agent from using a different wallet. What it changes is the reason an agent goes looking: an agent with its own budget does not run dry mid-task.
- Prompt injection that tricks a model into a payment it should not make is limited by the same caps and allowlist, not prevented.
Threat model summary#
| Threat | Outcome with Warden |
|---|---|
| Agent tries to pay an unlisted address | Denied, TARGET_NOT_ALLOWED |
| Agent loops and overspends | Stops at the window cap, OVER_PERIOD |
| Agent tries one large payment | Denied over perTx, or held for approval at the threshold |
| Agent tries to approve a token to a spender to bypass caps | Counted at full amount; spender must be allowlisted |
| Agent tries to change its own policy | Impossible: only the owner can, and agents cannot call the account |
| Agent key stolen | Loss bounded by caps per window until you pause or revoke |
| Owner key stolen | Full loss of the account's funds |
| Dashboard compromised | Can show you a bad transaction; your wallet shows the real one |
| Allowlisted recipient malicious | Loss bounded by caps |
Operational checklist#
- Owner in a hardware wallet. Note the account address somewhere safe.
- One agent key per agent, generated fresh, stored in the agent's secret manager.
- Allowlist recipients; name functions for contracts.
- Caps at real usage; window as short as practical; threshold for anything unusual.
- Validity dates for agents that should not live forever.
- Check the activity feed, and pause at the first surprise.
Reporting a vulnerability#
Open a private security advisory on the project's repository, or contact the Deference Works team directly. Please do not post details publicly before a fix.