You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Is the read set reconciled against anything, the way declared changes are? #1
The architecture diagram tags git as FACT and the transcript ingest as DECLARED, and drift scores the gap between them. That split is the part I keep thinking about.
On the write side there are two independent sources, so a claim can be checked against something. The sensitive-reads DLP looks like it has only one: the read set comes from the session transcript, which is the agent's own account of what it opened. If a session read a file and the transcript does not say so, I cannot see what would surface it.
Is there a fact-side source for reads that I have missed, or is the read set declared-only by design?
You had not missed anything: the read set was, and still is, single-source. Git is the second witness for writes; nothing plays that role for reads. What I can correct is how much of that single source we actually looked at, and how honest the docs were about it.
One nuance on "the agent's own account": the transcript is written by the harness, not by the model. Every tool call and result is logged mechanically, so the model cannot omit a read. It is still one process and one user-writable file, so treat the read set as a lower bound, not a proof.
Your question exposed real gaps, now fixed on main: reads through the shell (cat, sed -n, grep, source .env) and through Grep were not captured at all, Codex reads were not captured at all, and subagent transcripts were not discovered. The secret scan now also sees the full tool output rather than the inline preview. Every ingest pins the transcript byte range it consumed with a BLAKE3 digest, and brain0 verify fails if that range is later rewritten or truncated.
A fact-side source for reads would be an inline proxy on the model API base URL, which is the only place that knows what content actually left the machine, or kernel open events via fanotify or eBPF. Neither ships today. Both are written up in docs/governance.md under "What the read set is, and is not", together with exactly what the current extraction does and does not see.
Activity
nicolalessi commentedon Sep 9, 2026
You had not missed anything: the read set was, and still is, single-source. Git is the second witness for writes; nothing plays that role for reads. What I can correct is how much of that single source we actually looked at, and how honest the docs were about it.
One nuance on "the agent's own account": the transcript is written by the harness, not by the model. Every tool call and result is logged mechanically, so the model cannot omit a read. It is still one process and one user-writable file, so treat the read set as a lower bound, not a proof.
Your question exposed real gaps, now fixed on main: reads through the shell (cat, sed -n, grep, source .env) and through Grep were not captured at all, Codex reads were not captured at all, and subagent transcripts were not discovered. The secret scan now also sees the full tool output rather than the inline preview. Every ingest pins the transcript byte range it consumed with a BLAKE3 digest, and brain0 verify fails if that range is later rewritten or truncated.
A fact-side source for reads would be an inline proxy on the model API base URL, which is the only place that knows what content actually left the machine, or kernel open events via fanotify or eBPF. Neither ships today. Both are written up in docs/governance.md under "What the read set is, and is not", together with exactly what the current extraction does and does not see.
brain0 v0.1.1