GeezerVison

Summary

Adds a technical blog post on the resolved-secret provenance system — how a credential is labeled when it resolves into a run, how the label travels through tool calls, sandboxes and durable storage, and where it is checked on the way out.

Content-only: one MDX file and three images. No application code.

Written in the register of the existing executor and multiplayer posts — flat engineering explanation, concrete specifics, takeaways for readers building something similar.

What it covers:

• Activation requires proof — an entry activates only when the resolved runtime value equals the configured catalog value, so the tracked set is the run's actual secrets rather than everything the workspace holds
• The four egress boundary classes, including why the model is treated as a network boundary rather than an internal component
• Fail-closed degradation, and the named-reason reporting from fix(provenance): record why a resolved-secret registry became incomplete #6478 / fix(provenance): report why a projection was refused, at the point of refusal #6483 / improvement(provenance): name every guard that can latch a registry #6513 that keeps a refusal explainable without widening what reaches the user
• Why the length floor beats an entropy floor, with the measurements
• The two production failures that retired the word-boundary tier in favour of one constant (fix(provenance): make one length floor the whole substitution rule #6551)

Type of Change

• Documentation

Testing

Verified through the real blog registry rather than by eye — post is discovered by getAllPostMeta, MDX compiles via getPostBySlug, author resolves, 7 FAQ entries parse, and ogImage resolves at 1200x675.

Accuracy was re-checked against origin/staging source after #6551 landed, since that PR deleted the word-boundary tier and the detect/render matcher mode the draft originally described. Sections describing that machinery were rewritten or removed rather than left stale.

Every third-party citation was fetched and confirmed to substantiate the claim made against it, per the sourcing rule in .claude/rules/landing-seo-geo.md — Denning 1976, Myers & Liskov 1997, Perl perlsec, Yelp detect-secrets, LangSmith and Langfuse masking docs, OWASP LLM02:2025. One claim ("moved from sixth to second") was cut because the linked page does not state it.

Reviewers should focus on whether the described semantics still match the code, and on the guarantees table.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing — n/a, content only
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

Screenshots/Videos

Cover plus two generated diagrams, in the existing house style so they sit alongside the executor post's figures:

• lifecycle.png — activation → propagation → projection, fanning into the four boundaries
• length-floor.png — which value classes clear the eight-character substitution floor

No product screenshots: the trace examples in the post are described rather than captured.

🤖 Generated with Claude Code