docs(blog): One Chain, Two Channels, Zero Secrets#442
Draft
ojongerius wants to merge 9 commits into
Draft
Conversation
This was referenced May 16, 2026
Contributor
There was a problem hiding this comment.
Pull request overview
Adds a draft blog post documenting the agent-receipts-daemon v0.10.0 unified receipt chain + redaction demo, and wires it into the site’s blog index/sidebar. It also introduces a 0.10.0 daemon changelog entry describing redaction, agent-receipts list, and the mcp-proxy “thin emitter” shift.
Changes:
- Add new blog post: unified chain (hook + mcp-proxy) + peer attestation + redaction demo content.
- Link the new post from the blog index and add it to the Starlight “Blog” sidebar.
- Add
agent-receipts-daemon0.10.0changelog entry (features + dependency notes).
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| site/src/content/docs/blog/unified-chain-redaction-demo.mdx | New draft blog post describing unified chain + peer attestation + redaction demo. |
| site/src/content/docs/blog/index.mdx | Adds the new post to the blog index list. |
| site/astro.config.mjs | Adds the new post to the documentation sidebar under “Blog”. |
| daemon/CHANGELOG.md | Adds 0.10.0 changelog entry (redaction, CLI addition, mcp-proxy changes, deps). |
Comments suppressed due to low confidence (2)
site/src/content/docs/blog/unified-chain-redaction-demo.mdx:118
- This claims the daemon is “the only process that sees the raw payload,” but both emitters described here (mcp-proxy and agent-receipts-hook) necessarily see the raw request/response or tool_input/tool_response in order to forward it. The daemon is the only trusted receipt writer/enforcement point, but it’s not the only process that ever sees raw payloads. Suggest rewording to avoid the factual overstatement.
## Secret redaction
site/src/content/docs/blog/unified-chain-redaction-demo.mdx:188
- “The daemon is the only process that ever sees raw inputs” is not accurate: the hook and mcp-proxy both handle the raw tool input/output before forwarding frames. If the intent is that the daemon is the only trusted component that persists/signs receipts and applies mandatory redaction, please rephrase accordingly.
- Correlate cross-channel calls by `parameters_hash` when both channels capture the same event
| "peer.uid": "501", | ||
| "peer.gid": "20", | ||
| "peer.pid": "53707", | ||
| "peer.exe_path": "" |
Comment on lines
+46
to
+47
| - Bump `github.com/agent-receipts/ar/sdk/go` to `v0.9.1` | ||
| (DESC ordering and no silent 10k row cap in `QueryReceipts`). |
2 tasks
… redaction demo post
…alised storage is the real next step
… command/receipt mismatch
Same treatment as post 1: remove broken forward references, soften a few rhetorical shapes, and reframe the exe_path failure mode positively. - Strip the forward link to post 3 (not shipped yet) and update the backward link to use post 1's new title. Add a publish date. - Drop "Both were validated live" buildup before the real receipts. - Flatten "Two databases. Two chains. No way to correlate..." rule-of- three into one sentence. - Reframe the peer-credential paragraph: lead with uid/gid as the always-works property, then describe pid/exe_path as best-effort by design rather than a bug. Closer: "The kernel always wins on uid/gid; pid/exe_path is best-effort by design." - Soften the duplicate "persisted forever in a signed, immutable record" line; the earlier "Forever. In a signed record." in the history is the dramatic punch — restating it is overkill. - Trim "What's next" — drop the tactical daemon.toml item and reorder so architectural roadmap (storage, encryption) leads.
When post 2 ships, post 1 should point at it. Adds the "Next →" entry to post 1's series header and restores the closing "the next post is the demo" line that was stripped when post 1 shipped without its companions. Bundling this with post 2 means a single merge does the right thing — no separate post-publish housekeeping PR.
ojongerius
force-pushed
the
worktree-blog+receipts-redaction-demo
branch
from
afad6d1 to
0c8e00f
Compare
Per Copilot feedback on PR #442 — two spots claimed the daemon is "the only process that sees raw inputs / sees the raw payload." That's inaccurate: emitters (mcp-proxy, hook) necessarily see the raw payload to forward it. The accurate claim is that the daemon is the only place where receipts are persisted and signed, and the only convergence point all emitters funnel through. - Redaction section: reframe to "every emitter funnels through the same daemon socket, so redaction applied there runs unconditionally." - What this enables: "the daemon is the only process that persists receipts and holds the signing key — emitters are fire-and-forget, no local storage." Same point as before — trust boundary is structural, daemon is the chokepoint — but the wording no longer overclaims about who sees what.
| } | ||
| ``` | ||
|
|
||
| The daemon captures these at socket accept time, kernel-attested — the emitter cannot forge them. `uid` and `gid` come from `LOCAL_PEERCRED`, which snapshots them the moment the connection lands; they always come through. `pid` and `exe_path` are looked up just after via `LOCAL_PEEREPID` + `proc_pidpath`. Short-lived emitters that have already disconnected by then — the hook in particular, one connection per frame — leave those two empty (`LOCAL_PEEREPID` returns `ENOTCONN`). The kernel always wins on uid/gid; pid/exe_path is best-effort by design. |
| --- | ||
|
|
||
| _Published 2026-05-17_ · **Series: Auditing AI Agents** · Part 1 of 3 | ||
| _Published 2026-05-17_ · **Series: Auditing AI Agents** · Part 1 of 3 · [One Chain, Two Channels, Zero Secrets →](/blog/unified-chain-redaction-demo/) |
Comment on lines
+171
to
+174
| { | ||
| label: "One Chain, Two Channels, Zero Secrets", | ||
| slug: "blog/unified-chain-redaction-demo", | ||
| }, |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Draft blog post covering the v0.10.0 demo:
parameters_hashon consecutive sequence numbers[REDACTED]output in both command input and stdoutparameters_disclosurefrom OpenClaw'sparameterPreviewNot ready to publish — needs a read-through and any factual/tone adjustments.