DEV Community: Emek Can Doğru

"The boss said yes" is not an approval

Emek Can Doğru — Thu, 08 Oct 2026 18:27:58 +0000

"The boss said yes" is not an approval.

When an AI agent wants to spend money through Verax, the call is held. The agent cannot approve it by itself; there is no auto-approve path. A person approves it, on the machine where the body runs.

What gets held

spend is capped by payee, amount, currency and a daily limit, and even inside those caps it always defers. Any other call is held when your policy marks its rule for approval. The agent's token can read and write memory through the gate; it cannot approve.

Who resolves it

A held call is resolved with verax approve on that machine. There is no remote approver. When four approvals of the same request arrive at once, one allow is recorded and the others answer already-resolved.

A spend approval also re-checks the daily budget at the moment it is approved, against what has already been approved today, so approvals that are each fine on their own cannot add up past the limit.

The name in the record

The approval is not just a click. The approver's operator id is bound into the signed record, so a week later "who approved this?" has an answer you can check, not one you have to remember.

Since 0.4.2 an approval sent over HTTP needs a passkey assertion when an operator is registered, and verax verify checks that signature against the operator's public key without asking the body. The panel that sends it opens through verax desktop, which is not released yet, so on a released install the approval is verax approve, and a CLI approval stays unsigned: the operator id is in the record the body signs.

What it doesn't do: approving is not paying. Verax records an authorization; a person or another system moves the money. The operator id is the id Verax knows that operator by, not a verified identity from your company directory. Since 0.4.3 a checkpoint can be registered with a transparency log someone else runs; without that, the same system keeps the record and signs it. No independent audit has been done.

Episode 4 of the series, animated in three.js and voiced with ElevenLabs.

Source (Apache-2.0): https://github.com/verax-ai/verax

Pulling the red lever on an AI agent

Emek Can Doğru — Sat, 03 Oct 2026 08:28:56 +0000

Sometimes you want an AI agent to stop everything, right now.

Verax has a halt switch for that. Once an operator pulls it, every call the agent makes after that point is refused, and each refusal is signed and recorded like any other decision.

Who can pull it, and who can let go

On an install the switch is the command line: verax halt, and since 0.4.1 verax resume. Behind them are two HTTP doors. POST /api/halt accepts any operator session. POST /api/resume needs verax:approve. The agent's token carries neither, so the agent cannot stop itself to dodge a check, and it cannot lift a halt someone else set.

GET /api/halt answers whether the body is halted and who halted it.

The resume is written down first

Who halted, who resumed and when go to halt-history.jsonl, a file next to the switch. The resume line is written before the halt is lifted. If that line cannot be written, the body stays halted.

That file is a plain log, not a signed one. Since 0.4.2 each halt and resume is also written to the ledger as a control record signed by the body's record key, beside the signed refusals made while the switch is down, and verax verify fails on any allow inside a halt window. The body signs that record, not the operator.

What it doesn't do

A call that is already running when the switch is pulled is not cut off. The switch stops everything after it.

The halt is a file in this machine's state directory. It stops the body it sits next to, not one it cannot see.

In the film the switch is a lever. On a released install it is the command line and those two doors; the panel that would carry a real button opens through verax desktop, which is not released yet.

Episode 3 of the series, animated in three.js and voiced with ElevenLabs.

Source (Apache-2.0): https://github.com/verax-ai/verax

When there is no rule, the answer is no

Emek Can Doğru — Wed, 30 Sep 2026 21:22:56 +0000

When an AI agent asks Verax for something there is no rule for, the answer is no. Nothing is allowed by default.

That covers the obvious case, like an agent trying to export your customer list. It also covers a quieter one. The agent gets refused, then tries the same thing under a different tool name. A new name has no rule either, so it gets refused again.

What that looks like in the policy

The policy Verax starts from names four tools and nothing else:

{
  "version": 1,
  "default": "deny",
  "rules": [
    { "id": "memory-get",    "tool": "memory.get",    "requires": ["verax:read"] },
    { "id": "memory-put",    "tool": "memory.put",    "requires": ["verax:memory"] },
    { "id": "audit-explain", "tool": "audit.explain", "requires": ["verax:read"] },
    { "id": "message-read",  "tool": "message.read",  "requires": ["verax:read"] }
  ]
}

A call to anything else, including a tool that exists on a server attached behind Verax, is refused before that server sees it. Two rules for the same tool are refused when the policy loads, so a second rule cannot quietly widen the first.

A refusal is a record too

Refusals are signed and recorded the same way approvals are: which agent, which tool, what time. When something goes wrong, the attempts that were stopped usually tell you more than the ones that went through.

The record stays on your machine. verax verify reads it with no server running and nothing on the network, and says how many signatures verify and whether the chain is unbroken.

What it doesn't do: the same system keeps the record and signs it, and no independent audit has been done.

Episode 2 of the series, animated in three.js and voiced with ElevenLabs.

Source (Apache-2.0): https://github.com/verax-ai/verax

What an agent's tool call leaves behind

Emek Can Doğru — Tue, 29 Sep 2026 17:43:27 +0000

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.

The EU AI Act's logging rule moved to December 2027. The logs did not get easier.

Emek Can Doğru — Thu, 17 Sep 2026 22:23:22 +0000

The Digital Omnibus on AI (Regulation (EU) 2026/1744) was published in the Official Journal on 24 July 2026 and entered into force three days later. The obligations for high-risk AI systems, including record-keeping, now apply from 2 December 2027 for the stand-alone systems in Annex III and from 2 August 2028 for AI built into regulated products. If you read a post this summer that said "August 2026", that date is gone. The rule is not.

Article 12 of the Act is short. A high-risk system must technically allow the automatic recording of events over its lifetime, and those records must be good enough to trace a situation that turned risky, to support monitoring after the system is on the market, and to follow how the system operates. That is the whole requirement, and it is a requirement about what the system can record, not about what a dashboard shows.

Why an agent's logs do not pass this today

Most agent stacks log. Almost none of them keep records. The difference is what is missing from the line:

Who asked. A log line names a service account, not the agent, its scopes, or the human who was behind it.
What was asked. The prompt is there, the actual tool call with its arguments often is not, and nothing ties the two together.
Which rule decided. The line says the call ran. It does not say which policy, at which version, allowed it, or why a refused call was refused.
What happened. The result is somewhere else, in another log, with another timestamp.
Whether the line is still the original. A text log can be edited, trimmed, or lost, and afterwards nobody can tell.

And the logs sit in a vendor's cloud. When the question is asked, the answer belongs to someone else.

What a record needs

We ended up with five parts, and each one answers a question an auditor actually asks.

Identity and scope. The agent connects with a token, and the token names what it may do: read, memory, act, pay, approve, audit. No default token; the gate does not open until this is configured.
The request. A hash of the exact call, so the record and the call cannot drift apart.
The decision. Allow, deny, or wait for a human, with the policy hash and a reason code. A refusal is written the same way as an approval; silence is not a record.
The effect. After the call runs, an effect row with the result hash, reconciled against the decision that allowed it. audit.explain reads a decision back with its chain, its signatures and its findings.
A signature and a chain. Each record is signed, each carries the hash of the one before it, and a copy of the ledger is kept beside the original. verax doctor says when the copy and the ledger disagree.

How Verax does it

Verax is an open-source MCP server (Apache-2.0) 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 call the policy will not decide alone is held until an operator on that machine approves it, from the panel or the command line. The ledger stays on the machine the body runs on, and the record does not leave it.

A few things we had to build this week to make that hold under load, measured on one laptop with 150 agents over 30 days of synthetic traffic (200,000 decisions), and shipped in 0.1.2: the ledger is cut into pieces of 50,000 rows with a persistent ref index, so a restart reads the open piece and the index rather than every record ever written (1.9 s and 518 MB at 200k with both pieces closed); a day's window costs the day's rows, not the ledger's age; verax doctor compares the evidence copy and the index to the pieces and says when they disagree. The same release closes six faults an outside review reproduced on the earlier code: parallel calls passing a rate limit, one ref running a tool more than once, a daily spend cap passed by parallel requests, one request approved more than once, a tenant's own memory record hidden by another tenant's, and a retry running on an approval after the token had lost its scope. Each has a guard now.

What it does not do

We keep this list on the website and it belongs here too. Today the same system keeps the record and signs it; a separate witness process exists, an independent one does not. There is no tenant boundary. On a single-copy ledger, silence cannot be told from nothing happening. Payloads sit in plaintext. No independent audit has been done. And whether a given deployment meets Article 12 is a conformity question for your assessor, not a claim we make.

Try it

npm install -g @verax-ai/body (0.1.2, published with provenance from the repository), then verax doctor names what the body still needs before it listens (Node 22.6 or newer). The entry in the official MCP Registry is io.github.verax-ai/verax; the code is at https://github.com/verax-ai/verax and the site is https://verax-ai.com. The free tier is the open-source install; the pilot is how companies run it with us. Questions and disagreements welcome in the comments; the record format is Cedulon's, and it is open too.