Ask an AI agent to do something with real consequences, and the question comes later: who allowed that? Most setups can tell you what the agent did. Fewer can tell you which rule let it happen, and almost none keep a record of what was refused.
Verax is an MCP server that sits between an agent and its tools. I built it to answer that question with a file, not a guess.
Every call passes a rule first. Each tools/call goes through a policy before anything runs. Nothing is allowed by default: a tool with no rule is refused. Renaming the tool doesn't help, because the new name has no rule either.
Refusals are records too. An allowed call and a refused call both leave a signed decision record: which agent, which tool, which rule, what time. When something goes wrong, the attempts that were stopped often say more than the ones that went through.
Money waits for a person. A spend always defers. The person approving sees a summary, and the approval names the request they saw. If the request changed after they looked, the approval doesn't go through. The agent's own token can't approve; approving is a separate scope it doesn't have.
The record stays with you. The ledger lives on the machine the server runs on. verax verify reads it back without the server, and a one-cent change breaks the signature.
Try it in a terminal (Node 22.6+):
npx @verax-ai/body demo
It records an allowed memory write and read, a signed refusal of a message to a host off the policy list, and a payment held until you answer y.
What it doesn't do. The policy sees the tool name and the token's scopes, not the argument text or what a tool returns, so it is not a prompt-injection filter. There is no independent audit yet; what is proven and what isn't is listed line by line in docs/STATUS.md.
Break it. Each valid break of the boundary between the agent's account and the approver pays USD 100, up to USD 500 in total. The terms are in SECURITY.md.
The video above is the first of two one-minute animated episodes. The scenes are drawn in three.js and the voices are generated with ElevenLabs.
Top comments (2)
This is a solid approach to the authorization boundary. The key insight that most projects miss is exactly what you've built: the agent proposing an action and a separate entity approving it should live at different trust levels. Giving the agent a key and telling it to use it responsibly is not a strategy.
The money-deferred pattern is the part that scales. Once you separate initiation from authorization for payments, the same architecture handles identity verification, credential access, and any action where the agent should be able to propose but not authorize itself. The proposal and the approval exist at different trust levels, and that split is what makes the whole thing hold up to real scrutiny.
Thanks, that split is the part I care most about. In Verax it isn't a convention: the agent's token doesn't carry the approve scope, so it can ask but can't sign an approval, and a test fails if that ever changes. Since 0.4.1 the same rule covers stopping: any operator session can halt the body, but only someone who can approve can lift the halt, so an agent can't undo its own stop.
Curious how you've seen this set up in practice: does the approver usually sit on the same machine as the agent, or somewhere else, like a phone?