Skip to content
C.W.K.
Stream
Lesson 02 of 05 · published

The Read That Leaves No Trace

~13 min · guardrails, evidence, verification, incident

Level 0Wet Clay
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete

The Asymmetry That Breaks Every Post-Hoc Check

Writing and reading feel like a symmetric pair, and for enforcement purposes they are nothing alike. A write leaves a diff. A gate can compare the tree to its previous state and be certain that a file was not edited. A read leaves nothing the gate can reach: no diff, no timestamp you can trust, no artifact in the tree. An operating system can be instrumented to record every file open — that facility is real, and it sits outside the workshop; the gate has the repository and nothing else. The output of a session that read the forbidden file and the output of a session that did not are, structurally, the same kind of object.

So the gate that proves "no source-language file was modified" is true, cheap, useful — and completely silent on the question anyone actually cares about, which is whether the author looked. For a while that gate was treated as if it answered both. It does not, and the belief that it did is what let the problem run.

Three Incidents, One Cause

Over two days, three separate runs on this workshop broke the same seal, across two different authoring systems and two different work batches.

In the first, a cold reviewer listed the target directory to orient itself, and the listing printed the forbidden filenames. In the second, an over-broad search during review surfaced a title from a forbidden file. In the third, a sweep looking for leaked strings ran an unscoped search across a directory and printed an entire prose field from the forbidden sibling straight into the working context.

Not one of them was a deliberate lookup. Not one of them was a file-opening tool call — every single one was a shell command pointed at a directory without a filter narrow enough to exclude the sibling. And every one of those runs passed the write-diff gate green, because none of them wrote anything.

Three Occurrences Is a Missing Guard

One incident is an accident. Two is a pattern worth a note. Three, across two independent actors and two batches, is a structural finding: the rule was correct, understood, and unenforceable by the person holding it, because the breach happens through a tool whose default behavior is to be helpfully broad.

Notice how ordinary the breaching commands are. Nobody types the dangerous version because they are being reckless; they type it because it is the version that gets the answer, and the filter that would have made it safe is an optional flag that the task at hand gives no reason to remember.

A green gate over writes is never evidence that a read-prohibition held. The only two things that can supply that evidence are the author saying so plainly, and a guard sitting in front of the tool call. The first is worth requiring anyway; the second is the subject of the next lesson.

Code

The command that breaches, the command that does not, and the gate that cannot tell·bash
# BREACHES - and looks completely reasonable while doing it
grep -rn "someString" ./target-dir/
ls -R ./target-dir/                    # filenames alone are a leak
cat ./target-dir/**/*                  # the obvious one
rg "someString" ./target-dir | head    # a pipe does not narrow it

# SAFE - the filter is the entire difference
rg --glob '*.target.json' "someString" ./target-dir/

# THE GATE, afterwards
git diff --stat -- './target-dir/**/*.source.json'
#   (empty)
#
# This output is TRUE and PROVES ONLY that nothing was written.
# All four breaching commands above leave it exactly this empty.
# Reading leaves no trace, so no command you can run after the
# fact will ever distinguish the clean run from the contaminated
# one. The check has to move to BEFORE the call.

External links

Exercise

List the rules in your process that forbid an action rather than requiring one. For each, write down what artifact the forbidden action would leave behind. Sort them into two piles: those that leave a trace and those that do not. Everything in the second pile is currently enforced by hope, no matter how many checks you have, and each one needs either a guard at the call site or an explicit attestation in the record.
Hint
Reading, copying to a clipboard, viewing a dashboard, and asking a colleague are the four that most often land in the traceless pile. Deleting is the interesting boundary case: it leaves a trace only if something was already watching.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.