Logs are local, but some claims need to travel. As agents, MCP tools, metered APIs, and automated payment flows do more work, there needs to be a simple way for another system to verify what was reported later. PEAC issues portable signed records for that boundary.
Working on Originary, built around PEAC, an open protocol for signed interaction records.
The idea is to make agent, MCP, and API interactions verifiable across org boundaries instead of relying only on logs. Still early, but that’s the thing I’m most focused on right now.
Hey HN, I’ve been building Originary, and this is one small piece of it: Agent Auditor.
It opens a signed interaction record and shows who acted, what happened, and whether the signature verifies. You can try it in the browser with a sample file or use the CLI locally. No signup, no backend, no outbound fetches.
I built it because logs are useful for debugging, but not great when another team or customer needs something portable they can inspect independently later. I wanted a simple way to open a signed record and verify it with a public key.
The tool is deliberately narrow: it is read-only, verifies structure and signatures, and does not issue records or validate business logic.
Agent Auditor is a local browser/CLI tool for opening files describing agent actions and verifying their validity.
I built it because most agent logs are hard to review and easy to fake or misread. This gives you a readable timeline plus local verification for supported receipt/bundle files, with no account and no outbound verification.
I built a small runnable demo that turns OpenClaw tool-call events into a verifiable trace you can move between systems.
What it does:
- captures tool calls (input/output/timing/status) via the OpenClaw hook surface
- appends them to a tamper-evident chain (each entry links to the previous digest)
- emits a signed, portable receipt per tool call (JSON you can verify offline)
Why: If you’re running agents across services, the “truth” of what happened ends up split across logs. This gives you a single artifact you can attach to an incident, audit, customer ticket, or cross-team handoff.
Looking for feedback from OpenClaw users:
- which fields are missing for real debugging/auditing?
- do you want this to map to an existing trace model (OTel, etc.)?
- what storage/transport would you actually use for receipts in production?