Examples for API responses and MCP tool calls are in the README.

Website: https://www.peacprotocol.org

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.

Originary: https://www.originary.xyz PEAC: https://github.com/peacprotocol/peac

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.

Happy to answer technical questions.

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.

Try:

- git clone https://github.com/peacprotocol/peac - cd peac && pnpm install - cd examples/openclaw-capture && pnpm demo

It prints a trace + emits 3 example receipts.

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?

Such a creative solution to what might seem like a small, but really important, problem! I love how precise and responsive the blur is.

Thanks so much for making Posturr. It definitely deserves more recognition!

This is a super creative and fun project.

Does the job well!

Web Bot Auth solves authentication (“who is this bot?”) but not authorization/usage control. We still need a machine-readable policy layer so sites can express “what this bot may do, under which terms” (purpose limits, retention, attribution, optional pricing) at a well-known path, robots.txt-like, but enforceable via signatures.

A practical flow:

1. Bot self-identifies (Web Bot Auth)

2. Fetch policy

3. Accept terms or negotiate (HTTP 402 exists)

4. Present a signed receipt proving consent/payment

5. Origin/CDN verifies receipt and grants access

That keeps things decentralized: identity is transport; policy stays with the site; receipts provide auditability, no single gatekeeper required. There’s ongoing work in this direction (e.g., PEAC using /.well-known/peac.txt) that aims to pair Web Bot Auth with site-controlled terms and verifiable receipts.

Disclosure: I work on PEAC, but the pattern applies regardless of implementation.

Thanks for the thoughtful feedback, fair points all around. Let me clarify:

Who’s driving this: PEAC is open-source (Apache 2.0), started by a small group of developers who care about web standards, but it’s meant to be community-stewarded from the start. No one “owns” it; anyone can contribute, pilot, or join the working group (GitHub or the form). The real goal is collective evolution.

Business model: There isn’t one. It’s pure OSS, free to use or adapt, no strings or monetization. Just focused on enabling fair consent and attribution for everyone.

On “infrastructure”: Good catch. I meant the application layer (CDNs like Cloudflare, content platforms), not lower networking layers. This is about access and content rules, extending things like robots.txt.

On "X”: X is just one option. GitHub issues, HN, email, or the working group form all work (links in repo/blog).

If you or anyone here has thoughts or critiques, I’d love to hear. How would you design the ideal solution?