Disclosure: this article is from Truthlocks and was prepared with AI assistance. The runnable example was tested using both Truthlocks' current Go receipt-signing implementation and Node's built-in cryptography.
A successful API response is not proof that a signature is valid. This example lets you inspect a signed action, verify it locally, and see three ways cryptographic verification should fail.
Run it without an account
You need Node.js 18 or newer and Git. No npm install, credentials or signup is needed.
git clone https://github.com/truthlocks/maip.git
cd maip
git checkout c7cbb95
node examples/developer-validation/verify.mjs
Read the verifier and fixture before running them. The script makes no network requests and collects no telemetry.
You should see five PASS lines. The valid Ed25519 signature verifies; a changed action, corrupted signature and unrelated public key are rejected. A fifth check detects a displayed agent identity that differs from the signed payload.
What the signature binds
The synthetic record uses Truthlocks' receipt/v2 signing contract. Signed fields include the agent identity, key identifier, action, scopes, resource and metadata. The fixture was generated and verified using the current Go signing implementation; the standalone verifier checks the same bytes using Node's cryptography implementation. The ephemeral private key was discarded, not published.
Try changing signed_payload.action in fixture.json. The script should exit with a failed assertion: otherwise the displayed data and signed bytes could disagree. To return to the original fixture, use git restore examples/developer-validation/fixture.json in this fresh clone.
The key is a trust decision
This example deliberately treats its bundled public key as trusted only for a synthetic fixture. A real verifier must obtain the authorized agent key through a trusted registry or key-history channel. If an attacker can replace both the record and the key you trust, a valid signature will not save that trust decision.
Signed scopes describe claims. They do not enforce permissions in other applications. A signed action is not proof that the action happened. Offline verification cannot establish current key revocation, identity verification, authorization or transparency-log inclusion.
Help test the hosted path
The walkthrough also links the current sandbox agent-registration and receipt APIs. Use your own sandbox workspace and authorized credentials, and inspect signature and transparency verdicts separately.
We are recruiting external developers to report integration friction. A local PASS is a trial, not a hosted activation. Our proposed 14-day targets are 10 external trials and 3 hosted activations; they are not achieved results. Report runtime versions and sanitized failures in the developer feedback thread. Never share credentials or private records.
This is reproducible first-party evidence, not an independent audit or a production reliability benchmark. Payment acceptance and real-person identity checks remain separate gates.
If you choose to try the hosted sandbox, open Truthlocks. Website referral measurement is optional and consent-based; the offline verifier collects no telemetry.
Prefer Python?
The same synthetic receipt now has a Python verification example. It checks the original signed bytes using cryptography and runs the same valid-signature and tampering checks as the Node example. A Python virtual environment and one dependency are required; no Truthlocks account or API key is needed.
Open the tested Python walkthrough and setup commands.
The fixture is deliberately synthetic. Neither example establishes current authorization, revocation status or transparency-log inclusion. Tell us which language or integration you need through the trial feedback form.
Meet Truthlocks on Product Hunt
Verifiable AI agent identities and signed action receipts.
Our launch is scheduled for October 19, 2026 at 12:01 a.m. Pacific Daylight Time. Truthlocks is co-founded by Nnaa Igwiloh (CEO/CTO) and Emmanuel Adeyinka (COO).
Explore the launch and join the discussion →
Try the example above and tell us where you got stuck, what you would integrate first, or which trust assumptions need a clearer explanation. You can also report a trial directly on GitHub. Do not include credentials or private records.
Top comments (0)