The problem with prompt rules
You can tell a model “never spend more than 10 USDT a day”. That’s a request, not a rule. A model can misread an instruction, get confused across a long conversation, or be talked into something by text it reads: a web page, an email, or a tool result written by an attacker. This is called prompt injection, and there’s no reliable fix for it inside the model. If the agent’s key can move all the funds, a single bad decision can move all the funds. So the limits have to live somewhere the model can’t change them.Three layers
Put each rule in the strongest layer that can enforce it.
The system prompt is still useful. It tells the model how to behave well. Just don’t let it be the only thing between the model and the funds.
What to build
- Put funds in a vault. The owner key stays with a person. The agent key is only the operator. See Agent vaults.
- Set limits in the contract. A daily cap that resets at 00:00 UTC, and a recipient allowlist. See Spending limits.
- Write narrow tools. Each tool does one thing, checks its input, and simulates before sending. See Tool calling.
- Add an approval step for anything above a threshold. See Human approval.
- Optionally, check counterparties against an identity or reputation registry. See Identity hooks.
- Run the checklist before you add real funds. See Security checklist.
What the code in this section uses
- viem for chain access.
- The AI SDK with zod schemas for tools. The examples use Anthropic’s Claude through
@ai-sdk/anthropic, but any provider the AI SDK supports works. - OpenZeppelin Contracts for the vault.
Next steps
Agent vaults
Hold agent funds in a contract.
Tool calling
Give a model BOT Chain tools.