From Authorised Agent Actions To Provable Outcomes

When an AI agent moves money or settles a payment, two questions follow. Was it allowed to? And does what actually happened match what was approved?

Vorim answers the first. Every agent has a cryptographic identity, its authority is checked before it acts, and the decision, including any policy modification or human approval, is signed into a portable receipt that anyone can verify offline.

The second question is harder, because it reaches outside Vorim.

The gap

If a counterparty settles a payment an agent triggered, they need to establish that the settled outcome corresponds to the authorisation that actually occurred. Our signed receipt proves the authorisation. On its own it does not tie that authorisation to a settlement somebody else executed.

That gap matters most in exactly the cases our customers care about. A policy reduces a proposed payment before it executes, and the settled amount needs to match the approved one rather than the original request. Or a consequential action pauses for a human approval, and the record needs to show that the approval happened before the money moved, not afterwards.

What we built with Zeko Labs

In a proof of concept completed this week, a privacy preserving commitment to Vorim's signed receipt is bound into the settlement evidence path. A customer, auditor or counterparty can reconcile the authorised action with its settlement outcome independently.

No prompts, customer records, policy payloads or personal data are published. Only a commitment.

The chain is straightforward. The agent has an identity. Vorim evaluates its authority and applies policy. Vorim signs a portable receipt for the action it actually approved. That receipt's digest is bound into the evidence record, and the commitment is anchored so the settlement can be reconciled against it later.

Two real workflows

The POC covers two of our customers rather than invented examples.

For FinFindr, a discovery agent proposes an operating action and policy reduces it before execution. The payment context is built from the approved amount, not the original request. This is the case that quietly goes wrong in most systems, because the payment is often assembled before the policy decision is applied.

For Kent AI, a maintenance agent requests a consequential payment that pauses for a separately signed human approval. The approval attestation is carried in the receipt, so the human authority is verifiable from the evidence itself rather than by a second lookup against a service that may not be reachable.

Verification never requires a chain

This is the part we want to be precise about, because it is the part most likely to be misread.

Vorim's signed evidence verifies offline with open source tooling, with no vendor and no blockchain in the trust path. That has not changed and will not. Export a bundle, hand it to whoever is asking, and they check it on their own machine. Vorim could disappear and the proof would still stand.

The Zeko anchor is additive evidence for customers who want independent observability of settlement. It is never a prerequisite for authorisation or verification. If you do not need it, nothing about how Vorim works changes.

What this is, and what it is not

This is a proof of concept. It demonstrates the complete evidence handoff between the two systems. The production path adds canonical Mission Bound Auth proof and live settlement, and the zkApp does not verify Vorim's signatures on chain today. We would rather say that plainly than let a reader assume otherwise.

Available now

Everything on the Vorim side ships today in @vorim/sdk 3.22.0 on npm and vorim 3.22.0 on PyPI. That includes portable signed receipts, the platform signed approval attestation for human resolved escalations, and the canonical byte exporter so a verifier never has to reimplement the canonical form.

Book a demo →

Questions, we read every email at team@vorim.ai.