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?
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?
Major web disputes like the Perplexity/Cloudflare clash over AI crawlers, OpenAI’s lawsuit with NYT, or Anthropic’s Claude facing publisher data concerns show that the “rules of access” for the web are more contested than ever.
Should these rules be set by individual publishers, infrastructure providers, AI companies, open standards, or by community consensus?
What would your ideal solution look like? Who should decide? What’s broken today?
Surprisingly, Claude has more fans! Glad you find it useful! We will be making changes to the UI. Many are willing to pay, but we don't know how much to charge for it yet! What do you think?
Sorry about the ChatGPT4 results, will restore it. Thank you for trying.