Independent verification
Re-verify a mandate yourself. No account required.
Yebo's core claim is that approval evidence outlives the vendor, including us. Below is a real signed mandate, its public key, and the verifier. Prove the claim without trusting us.
Everything on this page works offline. The verifier makes no network calls, needs no API key, and never contacts Yebo. If Yebo disappeared tomorrow, this procedure would still work.
Step by step
Verify a real signed mandate
Three steps, one command. You need Node.js 18 or newer - nothing else.
- 1
Download the artifact and the public key
sample-mandate.json - a real signed mandate: an AI-initiated vendor disbursement of $18,500.00, over threshold, approved by a human. sample-public-key.pem - the approver's public key. - 2
Run the verifier
In a terminal, in the folder where you downloaded both files:npx yebo-verify sample-mandate.json --key sample-public-key.pem
Add--explainto include a plain-language explanation of every field. - 3
Read the output
The verifier recomputes the mandate's content hash, checks it against the hash the approver signed, and verifies the ECDSA signature under the public key you supplied. Expected output:
YEBO MANDATE VERIFICATION artifact sample-mandate.json key sample-public-key.pem RESULT: PASS - the artifact is exactly what the approver signed. Field breakdown action transfer.funds amount 18,500.00 USD (1850000 minor units) payee vendor:northwind-industrial requested by agent:ops-runner-3 approver cfo@acme.example policy version sha256:605ed3fac8ca6a2448a0… approved at 2026-07-23T05:11:03.480Z signature VALID (ECDSA P-256 / SHA-256) Checks [PASS] Artifact structure [PASS] Public key [PASS] Mandate integrity [PASS] Policy binding [PASS] Approval signature
The part that matters
Now try to break it
Verification you cannot break is verification you cannot trust. This artifact is the same mandate - with the amount changed from $18,500.00 to $98,500.00 after approval. Run the same command and watch it fail.
sample-mandate-tampered.json - download it into the same folder and run:
npx yebo-verify sample-mandate-tampered.json --key sample-public-key.pem
YEBO MANDATE VERIFICATION
artifact sample-mandate-tampered.json
key sample-public-key.pem
RESULT: FAIL - this artifact does not verify.
Checks
[PASS] Artifact structure
[PASS] Public key
[FAIL] Mandate integrity
The mandate contents do NOT match what was approved.
Recomputed hash cea0177725cc5906… differs from the
signed hash afa1f4aabdf7b2ae….
[PASS] Policy binding
[PASS] Approval signature
What did not verify:
- tampered mandate - the contents differ from what the
approver signedThis is the property that matters for control testing: the approval signature is still authentic, but the artifact no longer matches what the approver signed - so verification fails and says exactly why. Try it yourself: change any covered field (the payee, the timestamp, one cent of the amount) in either file and re-run. Every edit fails.
Also try verifying with the wrong key - generate any other P-256 public key and pass it as --key. The verifier fails and names the wrong key, because the artifact references its signer's key fingerprint.
Field reference
What each field is, and why an auditor cares
The artifact has two parts: the mandate (what the machine asked to do) and the approval (what a human authorized, cryptographically).
The action that was authorized, e.g. transfer.funds. An approval for one action cannot be reused for another.
The exact amount approved, in minor units (cents). Covered by the signed hash - altering it after approval fails verification. This is the field the tampered sample changes.
The vendor or account the funds were directed to. Also covered by the signed hash - the payee cannot be swapped after approval.
The machine actor that initiated the request. This is who asked - the approval below is who authorized.
The human who approved. For control testing, match this identity to your delegation of authority for the period.
A digest of the exact policy configuration in force at approval time. Lets you confirm which control governed the item.
A random value consumed at execution. Prevents the same approval from being replayed for a second payment.
Mandates are short-lived. An approval is bound to a specific request, not an open-ended permission.
When the approval signature was produced. Use it to test that approval preceded execution.
ECDSA P-256 signature over (mandate hash : policy hash : timestamp). Verifiable with the public key alone - no vendor access required.
Testing procedure
How to test this as an approval control
The same four steps you would apply to any approval control - except step 3 requires no vendor cooperation.
- 1
Sample
Select a sample of disbursements over threshold from the payment population, exactly as with any approval control. - 2
Obtain
For each sampled item, obtain the mandate artifact. Each disbursement carries one; artifacts are exportable in bulk for a testing period. - 3
Re-verify
Run the verifier against each artifact with the published public key, as you just did above. No access to the AP platform, the payment rail, or Yebo is required. The exit code is machine-readable (0 = pass), so a full sample can be verified in one scripted pass. - 4
Match authority
Match approval.approved_by against the delegation of authority in effect at the payment date, and match mandate_id against the system of record for the item.
The verifier is open source under the MIT license: view the source on GitHub. The complete integrity rule is about twenty lines of code and can be re-implemented in any language - you do not have to trust our binary either.
Practitioner validation
Did this hold up?
If you test approval controls for a living, your answer to these two questions is the test we care about.