Skip to content

Is the read set reconciled against anything, the way declared changes are? #1

Closed

Description

@mahirhir

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?

Activity

  1. self-assigned this
    on Sep 8, 2026
  2. nicolalessi commented on Sep 9, 2026

    @nicolalessi
    Contributor

    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.

  3. added a commit that references this issue on Sep 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions