Skip to main content
The sample shows how Veriqa fits into a ready-made agent harness: a person approves sensitive agent actions — not only tool calls, but also heavy runs that burn time and tokens — and every approval, refusal and expiry lands in the Veriqa audit trail. This matters most for teams where several developers work with agents at once. Claude Code and development tasks are the example chosen here; the approach fits another harness and other tasks. The sample lives in samples/claude-code/ in the repository (veriqa.app/source), is MIT-licensed and is meant to be reworked for your own needs. Its README is the setup guide.

​
Three demos

The costly run takes two approvers in turn — a developer, then a manager — each from their own messenger account enrolled beforehand. A confirmation from any other account refuses the action.

​
How it works

  1. A hook of the plugin matches the action against its rules. Nothing matches — Claude Code goes on as usual.
  2. A rule matches — the plugin creates a confirmation with POST /api/transaction/confirmation (client credentials), and the call is refused for now.
  3. Claude shows the QR code Veriqa returned. The plugin ships a small MCP tool that takes only the transaction id and returns that image unchanged, so the agent copies nothing.
  4. Claude repeats the call, and this time the plugin waits for the outcome with GET /api/transaction/{id}/result. The action runs only on confirmed; declined, expired, a confirmation from the wrong account or an unreachable host all refuse it.
The person reads a wording declared on the host with typed slot values filled in — “Claude Code in demo-shop wants to push the branch to the remote repository” — never text the agent wrote.

​
Why not the harness’s own “Allow” button

  • A named person. The host checks which messenger account confirmed, not merely that someone pressed a button.
  • Someone other than the developer. A chain asks a second person, so nobody signs off their own spending.
  • A trail outside the agent’s session. Approvals are recorded on the Veriqa host, not in a local transcript the same user can edit.
  • A question the agent does not write, answered on a separate device over a channel the agent does not control.
For a single developer watching their own agent, the harness button is often enough; the difference shows when several people share agents, spending or responsibility.

​
Demo shortcuts

Veriqa runs on the developer’s machine only to make the demo quick to set up; in a team the approving host is a shared service. The second approver’s QR code is shown in the same conversation for the demonstration only — Veriqa does not deliver the question to that person, and in a real setup the link reaches them another way: their own chat, e-mail, a ticket.
The plugin puts a person in the loop; it is not a sandbox. The limits are listed in the sample’s README. The engineering background of the direction is on Approving AI-agent actions.