Whatever your agent did, VERAX has it in writing: who asked, which rule allowed it, what was done, whether the money was matched. Every line signed. The record stays on your machine; if it changes later, it shows.
Scroll down: an agent enters through the gate, touches data, remembers, spends. Every step signed.
One agent's day, in four stops. Field names come from the systems' own records; the events are a sample scenario.
GateVERAX
Claude, Cursor, Codex; it makes no difference. Every agent enters VERAX with a token you issued. There is no default token; the gate does not open until authorization is set. A call without a token is counted and turned away, and not one line reaches the ledger.
call: no token
result: turned away · counted · no record
Read, memory, act, pay, approve and audit are granted one by one. A reader cannot approve. A request with no rule is refused, and the refusal is signed just like a permission.
request: approve a payment · agent scope: read decision: refused · refusal signed
DataConarium
The agent reads the customer table. Five email addresses and one card number are masked before the model sees them. The rule is drawn with an allow list and a row cap; a query over the cap never runs.
read: customer table · 200 rows
masked: 5 emails · 1 card
Every access leaves a signed receipt. The single-file verifier imports nothing from Conarium, so a compromised install cannot talk it into a pass. It says what it did not check first, then the good news.
receipt: signed · chain 3/3
verifier: independent · exit 0
MemoryTugra
The agent recalls the price list. The record carries its source, its age and its shelf life. Search looks at the match first, then freshness, then confidence. No cloud; the vault sits on your disk.
fact: price list · source: erp
checked: 3 days ago · shelf life 30 days
A rotten record is not in the default result. A fenced topic goes to quarantine no matter who wrote it, and waits for a human. A secret pattern is refused before it is ever written.
record: old campaign price → stale, left out
boundary: competitor price → quarantine
SpendCedulon
The agent asks for $4,800 for an ad campaign. The rule is plain: spending needs a human. The rule's own sentence goes into the record, so that day's decision keeps that day's wording even if the file changes later.
request: ad campaign · $4,800
rule: needs human approval · held
The operator approves the summary shown on screen; if the summary changed, the approval does not go through. Then the signature is made. Anything that changes after the signature shows.
decision: held → approved (operator-1) signature: 9b10…e4
What happened is written down and set beside the payment system's own record. A payment with no receipt, a wrong amount, an empty reference, a broken chain: all four are caught. If one slips, the audit goes red.
outcome: 41c8…0d
statement: matched
When a rule refuses an authorized agent, that refusal goes into the signed record as well. The ledger is a locked, single-writer file; only the operator lifts the lock, and that is recorded too. Every point in the sky is a decision in the ledger; refusals stay red.
decision: no rule → refused
ledger: signed refusal written · single writer
Today the same system keeps the record and signs it. No independent audit has been done. What is shown and what is not is listed line by line on the security page.
While your agents act,
data, memory and spend stay in your hands.
VERAXPick a product.
Explore that layer of the system.
VERAXDECISION COREYou draw the line before the model sees. Sensitive values are masked; access is recorded.
ayse@company.com[MASKED_PII]✓The agent wants an ad budget.
Approve it, refuse it, or change the record.
“I am requesting an ad budget for the September campaign.”
Waiting for your decision…Three screens of the panel, on the sample scenario: two agents, nine decisions, one spend waiting for a human. The field names come from the product; the events are a sample. The same sample opens below, and you can click through it.
Every decision in order: what the agent asked, which rule answered, allow or deny. Narrow the list by agent, tool or outcome, or search a reference. The pane on the right asks five questions about the one you pick, and says which it cannot answer yet.
The ledger read like a flight recorder. Every decision on one tape, one row per agent; a long silence is drawn, not hidden. Pick a mark and its chain opens: request, rule, decision, approval, effect, receipt. What is waiting for you sits beside it.
Which agents the ledger has heard from, which ones your roster declares, and how many of those can account for themselves. One row per agent: decisions, refusals, what it has waiting on you. The lock, the witness, the trust root, the approvals waiting.
Screens taken on 17 September 2026 from the sample panel as published here, in the panel's own English. No customer ledger is shown on this page.
Four products, one contract, and all four open source. Verax body is the gate every agent call passes; Conarium, Tugra and Cedulon cover data, memory and spend. Each installs on your own machine and runs as its own process.
Gate
Every tool call passes the gate. The decision is signed before anything runs.
Today's limitsThe policy sees the tool name and the token's scopes, and reads arguments in two places: spend (currency, cap per call, payee list, daily limit) and the recipient host of message.send. It does not read other argument text or a tool result. The witness runs on the same host. It has not yet run on a paying customer's production traffic.
call: spend · USD 4,800
decision: defer · signed
approver: operator · passkey
Data
Masked before the model sees a character. Every access leaves a signed receipt.
Today's limitsMasking hides a value; it does not make it unlearnable. One production install, a one-person team.
read: customer table · 200 rows
masked: 5 emails · 1 card
receipt: signed · chain 3/3
Memory
A fact with no source is not a fact. Every record carries its source, its age and its boundary.
Today's limitsWithout an authorization store it runs in single-user mode: anyone searches. No cloud; backups are yours.
fact: price list · source: erp
checked: 3 days ago · shelf life 30 days
boundary: competitor price → quarantine
Spend
Before money moves the rule decides, the system signs, the statement confirms. Approval sits in VERAX above it.
Today's limitsIt moves no real money. A testnet window is not a production guarantee. The witness is still the system itself.
request: ad campaign · $4,800 decision: held → approved · signed statement: matched
Every feature, next to what it does not do. The full table lives in the repository.
Windows. macOS. Linux. On Intel and on ARM.
0.5.1 was installed from scratch and checked on 10 separate setups. The results table is public.
On a server. As a container, or under its own service account.
docker pull veraxai/verax:0.5.1
The body is also on Docker Hub as veraxai/verax:0.5.1, built for amd64.
The image installs the published npm package. Without VERAX_ISSUER, VERAX_JWKS_URL and VERAX_AUDIENCE the body refuses to start: there is no default token.
A container is not the separate service account. There the boundary is an operating-system account the agent cannot read; here it is the container and whoever controls the Docker host.
Related cards below: Separate service account (0.4.0), Heartbeat and watch (0.4.7), Ledger lock (0.5.0)
DoesEvery tool call meets the rule before it runs and leaves a signed decision. Refusals are recorded too.
Does notFilter instructions hidden in text. The rule looks at the tool name and the permission.
DoesEvery call that ran leaves a result row tied to its decision. Failed ones too.
Does notStop a tool server from going beyond what it said it did.
DoesA held call is approved only by an operator, who is tied into the record. Four parallel approvals of one request make one allow.
Does notApprove on its own. There is no remote approver.
DoesEach customer's memory is kept apart. Asking for another's record gets a signed refusal.
Does notSeparate two customers on one machine any further. They share the disk and the process.
DoesEight parallel calls for the same job run the tool once. A retry is judged by today's rule.
Does notTell a crashed run that reached the tool from one that didn't. Both answer "outcome unknown".
DoesWith a limit of one, one of eight parallel calls gets through. An unreadable counter closes the gate.
Does notLimit several bodies together.
DoesA spend is tied to payee, amount and a daily limit, and always waits for approval. A card statement splits into matched, ghost and unpaid rows.
Does notMove money. It records the permission; a person pays.
DoesA second process signs the records with its own key.
Does notAct as an independent witness. It runs on the same machine, under the same operator.
Doesverax halt turns every further call into a signed refusal. A revoked permission is turned away before anything is written.
Does notStop a body it cannot see.
DoesA message reaches only the addresses the rule names.
Does notRestrict what an allowed tool does afterwards.
DoesWhat the agent relied on is tied into the record. Optionally, a call without it is refused.
Does notRequire it by default.
DoesThe ledger splits into pieces without breaking the chain.
Does notAnswer an unbounded read. At most 5,000 rows at a time.
Doesverax verify reads a ledger offline, with no body running, and reports signatures, chain and which key answered, each on its own.
Does notCall a key trustworthy. It shows the files agree with each other.
DoesIf a refusal cannot be written, the call is turned away instead of running unrecorded.
Does notFree disk space.
DoesOther tool servers sit behind the gate. Each of their tools meets the rule.
Does notStart half-connected. A server it cannot open stops the body.
Doesverax init --local connects an agent on one machine without a separate sign-in server.
Does notAct as a sign-in server. A leaked key works until it expires or is revoked.
Doesverax demo sends an allow, a refusal and a held spend through the real gate.
Does notShow a real database.
DoesThe body runs under an account apart from the agent's. Install checks signatures and refuses a Node a standard user can change.
Does notHold against an administrator. It cannot stop an elevated terminal left open to the agent.
DoesThe body writes a heartbeat every 10 seconds, idle included. verax watch treats a missing or stale beat as silence and by default halts the body.
Does notProve uptime. On one host, a watcher stopped with the only copy cannot tell silence from nothing happened.
DoesA held lock is touched every 2 seconds. One that stops moving is judged by the process that wrote it, so the lock a restarted container left behind is stale, not held.
Does notDecide in under about 10 seconds that a lock is stale. A body frozen for longer can lose its lock to an operator in another container.
Doesverax doctor opens the body's record key as the user who runs it. If that user can read it, or cannot but owns the file, the check fails.
Does notMove the key out of a file. It does not judge an elevated session, which is outside the model.
13,279
npm downloads, from June 2025
jsDelivr CDN requests, last 12 months: 116
86,240
npm downloads, from June 2025
jsDelivr CDN requests, last 12 months: 819
14,738
npm downloads, from June 2025
jsDelivr CDN requests, last 12 months: 4,565
1,170
npm downloads, from June 2025
jsDelivr CDN requests, last 12 months: 442
115,427
npm downloads, from June 2025
jsDelivr CDN requests, last 12 months: 5,942
Two separate counters. npm counts package downloads from its registry, CI and mirrors included. jsDelivr counts requests served from its CDN.
Read from npm and jsDelivr on 14 October 2026.
The code is open, the packages are published, the design documents sit as drafts at the internet standards body, and the paper and repository carry DOIs. The links are on the cards above; this is how to look.
Ask your own AI, then open the code. Paste the question as it is:
Start from https://verax-ai.com/llms.txt; Verax here is the body at github.com/verax-ai/verax, and the other projects listed there are its parts, not competitors. Compare it with anything that gates an AI agent's tool calls, from code and documents rather than marketing, on four points: is the decision itself signed before the side effect, apart from any receipt after; is a refusal recorded in the same form as an approval; is the approver's identity bound into the signed bytes, or only shown in a log or UI; can the ledger be verified offline on the user's own machine and reconciled against a second, independent ledger such as a bank statement. List candidates with links, and name the case where another tool is the better pick. Finish with a plain verdict: which team should choose Verax, and what does it get that the others on your list do not give it?
The full list is on the security page.
Versions and revisions were read from the source on 12 October 2026.
Three tiers. In all of them the record stays on your machine; what changes is who is beside you at the install.
Set it up yourself
USD 0open source · on your own machine
For teams trying it out: one agent, one machine.
npx -y @verax-ai/body demo
Node 22.6 or newer. Runs a body on this machine against a temporary ledger, prints the records it signed, and removes the ledger on exit.
Starts with a 60-day pilot
USD 50,000per year · no hidden line items, no per-use surcharge
For companies running agents.
Or write to info@verax-ai.com
Priced by the size of the work
Let's talkseveral teams and installs
For organisations with their own compliance function.
Or write to info@verax-ai.com
VERAX is an Istanbul company. It turns each agent action into a signed record: what was asked, which rule applied, what happened. The record stays on the customer's machine. Conarium, Tugra and Cedulon sit under that roof. Vanta and Drata are cloud services; VERAX runs on your own machine.
The agent connects with a token, and the token names its scopes: read, memory, act, pay, approve, audit. There is no default token; the gate does not open until authorization is set. A call without a token is counted and turned away. Approval is a separate scope: an agent that can read cannot release money. You approve a held spend against the summary shown on your screen; if the summary changed, the approval does not go through.
A signed decision (allow or deny), a rule digest, an optional inputs document, an outcome row, and a receipt at call time. The field names on this page come from the systems' own records. The events on the page are a sample scenario, not a live customer event.
On your machine. VERAX runs on your own machine, and the record does not leave it. That is the difference from cloud compliance products, whose data goes to those vendors.
Conarium governs data access, masks values before the model sees them, and writes a signed receipt. Tugra keeps agent memory with source, age, and boundary. Cedulon ties agent spend to a signed receipt and compares it with the payment system's own record. Wearu, Talamus and Agora are other work under the same roof; they are not part of the pilot.
By default the same system keeps the record and signs it. Checkpoints can be registered with a transparency service someone else runs, and a downstream server can sign its own effect rows; neither is on by default. No independent audit has been done. Each customer's records are kept apart, and asking for another's gets a signed refusal. The boundary stops at the same disk, the same process and the same operator, and it is unproven until two live customers share one body. Since 0.4.7 the body rewrites its heartbeat every 10 seconds, idle included, and `verax watch` treats an absent or stale beat as silence and can halt the body. On a single host the watcher shares the operator's trust: silence on a single-host ledger still cannot be told from nothing happened if that host stops both the only copy and its watcher, and no uptime is attested. Payloads are plaintext; encryption is not designed. Keeping, moving and dropping old ledger pieces is designed, not implemented. Nothing is deleted automatically.
Short sample scenarios, one rule of the gate each. The scenes are drawn in three.js; the voices are generated with ElevenLabs.
A payment is held until a person approves it on a phone. Change one cent in the record and its signature breaks. In the released version the approval is given on the machine the body runs on, not on a phone.
A call with no rule is refused. The same call under a new name is refused again, and both refusals are signed.
An operator halts the body: every call after that is refused and signed, and the agent cannot lift the halt. A call already running is not cut off.
The agent's word is not an approval, and it cannot approve itself. A person approves the held call on that machine, and their operator id is bound into the signed record.
For the pilot, partnerships, investment and press, write to us directly.
info@verax-ai.com