verax-ai/verax

The body an agent asks before it acts.
Listed on: npm · Glama · MCP Registry · MCP Market · mcp.so · Docker Hub · Zenodo
Verax is an MCP server that sits between an agent and its tools. Every tool
call passes a policy gate and leaves a signed decision record before anything
runs; every call that ran leaves an effect row that is reconciled against its
record afterwards. A refusal is recorded the same way as an approval. A call
the policy will not decide alone is held until an operator on this machine
approves it. The ledger stays on the machine the body runs on, and the body
opens only when its authorization is configured: there is no default token.
**Break it, and we pay.** USD 100 for each valid report of a way for the
agent's account to get a refused call allowed, run a call with no decision
record, or change the service's code, keys or ledger. The budget is USD 500
in total. Terms: SECURITY.md.
By VERAX Teknoloji. Sister projects:
Conarium ·
Tugra ·
Cedulon. Decision records use
the Cedulon record format.
How Verax compares, dated 15 October 2026: of 40 projects that gate, log or
approve an agent's tool calls, nine are compared on four questions with a
source for every cell, and the page says where Verax falls short:
verax-ai.com/compare.html.
See it run
The recording is the output of one run in a terminal where the approval
question was answered y and the amount was typed. That run took about a
second; it is played back slowly here so it can be read.
What it prints, without a terminal to answer the approval question:
Node 22.6 or newer, @verax-ai/body 0.2.1 or later. The command records an
allowed memory write and read, a
signed refuse of a message to a host off the policy list, and a payment held
for the operator on this machine (approved when the terminal answers y and
then types the amount, 100; up to 0.5.0 the demo did not print that second
question).
--keep leaves the temporary ledger on disk. verax verify reads it
back without a body, as in Read the ledger back without us.
The same rules, animated
Four short episodes show the same gate, with characters in place of a
terminal. They are sample scenarios: the scenes are drawn in three.js and the
voices are generated with ElevenLabs.
Episode 1, "$1,850": a payment is held until a person approves it on a phone,
and changing one cent in the record breaks its signature.
https://github.com/user-attachments/assets/772ae1c4-2697-47a0-a228-36f0508b0d93
Episode 2, "No rule, no way through": a call with no rule is refused, the same
call under a new name is refused again, and both refusals are signed.
https://github.com/user-attachments/assets/4fb86627-3310-4f10-b1a9-059d8fcffb28
Episode 3, "The red lever": an operator halts the body, every later call is
refused and signed, and a call that was already running is not cut off.
https://github.com/user-attachments/assets/8d19eed9-3359-46b3-bd77-f2b1b1c4dd75
Episode 4, "Who approved?": a held spend waits for verax approve on the
machine, the agent cannot approve it, and the approver's operator id goes into
the record.
https://github.com/user-attachments/assets/0b8aade4-a970-4b63-835e-4837e2a39cc9
Connect your agent
Elevated verax install and verax approve run a copy of this program that only an administrator can change; a copy your account can change is refused. On Windows an elevated CLI approve is the way to approve until the passkey panel is released. It has to be run from a separate administrator account, not this account elevated, because a same-user elevated shell inherits that user's environment variables and PowerShell profile, which the agent can set. Clear NODE_OPTIONS in that shell (Remove-Item Env:NODE_OPTIONS). Start that other account's PowerShell with -NoProfile (an elevated shell otherwise runs your $PROFILE, which your account can change):
On Linux and macOS, with a root-owned Node (the distribution's /usr/bin/node, or /opt/verax-node/ /bin/node; the installer prints those steps when the Node it was started from can be changed by your account). Do not start an elevated command with env node:
The command installs @verax-ai/body from the npm registry into an administrator-owned directory after signature checks, runs that Node, and keeps the ledger under a service account. On Windows the agent token is %ProgramData%\Verax\agent-token\ \agent.token (Administrators and SYSTEM have full control, your SID can read the file and read-execute the directory). On Linux and macOS a child process running as your uid writes ~/.verax/agent.token from its stdin. It prints the Claude Code line that reads that file. Port 8787 taken? verax install --port 8797. Node must be the all-users installer from nodejs.org on Windows; a Node your account can rewrite is refused. On macOS the remedy extracts the official tarball as root into /opt/verax-node (root:wheel, not group- or other-writable). On Linux the same place, /opt/verax-node (root:root), which SELinux labels usr_t. On SELinux systems install requires Node labelled bin_t or usr_t (distribution Node is; a tarball under /usr/local/lib is not) and prints the one-line fix. The service then runs in unconfined_service_t. The service account and the file permissions are the boundary.