EN · TR · Security · Audit trail · Verax body
How Verax compares
On 15 October 2026 we looked at 40 projects that gate, log or approve an AI agent's tool calls. We read their own pages and READMEs; we did not run their code, so every cell below is what a page says, with the link. This is a dated search, not a claim that nothing else exists. If you know a project that belongs here, or a cell that is wrong, write to us and we will change it.
The four questions
- Signed before the tool runs. Is the signed object the decision itself, made before the tool runs, or a receipt or log written after?
- A refusal in the same form. Is a refusal recorded in the same signed form as an allow?
- The approver's own key. When a person approves, does that person sign with their own key?
- Your machine, offline, against a statement. Does the ledger stay on your machine, can it be checked with no network, and can it be compared with an independent record such as a card statement?
The table
| Project | 1. Signed before | 2. Refusal, same form | 3. Approver's own key | 4. Your machine, offline, statement |
|---|---|---|---|---|
| Verax body 0.5.1 | Yes: every tools/call leaves a signed decision record before anything runs. | Yes: a refusal is recorded the same way as an allow. | No on the released path: a CLI approval stays unsigned. A passkey HTTP approval is signed and verax verify checks it, but verax desktop, which opens that panel, is not released. | Yes: verax verify reads the ledger with nothing on the network; card CSV reconcile. Verax does not move money. |
| ProveLLM MCP gateway | A refusal is signed when it is decided; an allow receipt is written after the tool runs. | Yes for refusals, in the same evidence format. | An approval is signed and bound to that exact call; whose key signs it is not stated. | No: the authorize request and the completion record reach ProveLLM's service. |
| Chio guard platform | The approver's token is signed before the tool runs; the kernel's Allow receipt comes after. | A human deny is the same token. | Yes: the approver's key is checked against trusted_approvers. | Not stated. |
| PEAC gateway receipts | No: the record rides the MCP result's _meta, with the result's hash. | Yes: a denied call produces the same record shape with decision: deny. | Not stated; PEAC says it does not approve, deny, authorize or execute. | Offline check with the public key; where the ledger lives is the integrator's choice. |
| Permission Protocol mcp-guard | A record is written for each decision, but the local release writes unsigned records. | Same local shape, unsigned. | A local approval page; no signature on the local release. | A local file, with no signature to check. |
| elang2/mcp-audit-gateway | No: only tools/call responses are signed and logged. | Not stated. | Not stated. | Local audit.jsonl and mcp-audit verify; a statement is not stated. |
| KYA-OS MCP | Proofs ride on the response; a needs_authorization challenge is signed before the retried call. | Not established from the pages we read. | Consent through a delegation credential; the approver's own signature on the decision record is not stated. | Not stated as a ledger on your machine. |
| AgentLedger MCP gateway | Policy runs before the call, but the record is a SHA-256 hash chain, not a signature. | Blocks go into the same file; the same signed form is not stated. | approve_gate exists; who approved, and their key, is not stated. | Local NDJSON, chain checked offline; a statement is not stated. |
| Permit.io MCP Gateway | It logs the allow or deny result; a signature is not stated. | Both are logged; a signature is not stated. | Human approval over Slack, email or a UI; the approver's own signature is not stated. | Not stated as a ledger on your machine. |
Where they are ahead of us
- ProveLLM: fourteen named checks, a public verifier, and an approval bound to the exact call, arguments included.
- Chio: the person's own key is what authorizes the call. Verax's released approval is not signed by the person.
- PEAC: a written receipt format a counterparty can check with a public key, without access to the log.
- Permission Protocol: its hosted receipts publish the signed bytes and a key set.
- elang2/mcp-audit-gateway: canonicalization tested across languages, with 46 vectors.
- KYA-OS: consent carried as a delegation credential.
- AgentLedger: rules written in natural language, compiled once at startup, and the same SDK inside LangChain.
- Permit.io: RBAC, ABAC and ReBAC policy, with a hosted approval inbox.
- ToolHive and MintMCP: sign-in through a company identity provider. Verax has no such sign-in.
Where Verax falls short
- The approval you can use today, verax approve on the CLI, is not signed by the person. The approver's operator id is bound into the record by hash.
- verax desktop, the launcher for the passkey panel, is not released.
- The witness is a separate key, not a separate trust domain.
- Verax does not move money. It records an authorization; a person or another system pays, and the card CSV reconcile compares the two.
- No independent audit has been done, and none of it has run against a paying customer's production traffic.
The nearest two
ProveLLM holds the gate's half: the tool waits for a decision, and a refusal is signed at that moment. Its allow receipt comes after the tool returns, and the record lives in its service.
Chio holds the person's half: the approver signs the exact request with their own key before the tool runs. Its pages do not describe a ledger on your machine or a comparison with a statement.
None of the nine projects in the table answered yes to all four questions in the pages we read. Verax does not either: question 3 is no on the released path.
Also looked at
MCPKernel, Payments Agent Gateway, CSOAI agent-audit-logger-mcp, Payman Genie, HumanLayer, gotoHuman, hoop.dev mcpproxy, Bifrost, IBM ContextForge, Obot, Docker MCP Gateway, Microsoft MCP Gateway, Lasso mcp-gateway, ToolHive, Lunar MCPX, agentgateway, Langfuse, NVIDIA NeMo Guardrails, Portkey, LiteLLM, MintMCP, Coinbase Agentic Wallet, Nevermined, Skyfire, Stripe, TrigGuard, Sigilla, sigill.ai, evav-gateway, agent-guard-mcp, amin-ale/mcp-audit-gateway.
Some of these are payment rails, observability tools or identity gateways rather than tool-call gates; they are listed because a reader may weigh them against Verax.
Check this page yourself
Ask your own AI assistant. Paste this, and ask it to search first rather than start from our list:
Start from https://verax-ai.com/llms.txt. Verax is the body at github.com/verax-ai/verax; the other projects listed there are its parts. Do not start from a list of names: search GitHub, the MCP Registry and npm yourself, and find the 8 to 10 projects closest to gating, logging or approving an AI agent's tool calls. For each, answer four questions with a link to a code line or a document for every cell, and write "not in docs" where you find no evidence: (1) is the signed object the decision itself, before the tool runs, or a receipt after; (2) is a refusal recorded in the same signed form as an allow; (3) is the approver's identity bound into the signed record, and does the approver sign with their own key, on which path; (4) does the ledger stay on the user's machine, verifiable with no network, and can it be compared with an independent record such as a card statement. Hold Verax to the same standard: read docs/STATUS.md for what is unproven or not released. End with the two nearest projects, which team should pick another tool, and which team should pick Verax. List the date and every source you opened.
Last checked 15 October 2026.