A dual-lattice admission layer denies writes that inherit untrusted repo text

The join is the core mechanism here, and it is worth looking at first. `evaluate_plan` walks the plan's `depends_on` graph and combines labels componentwise: confidentiality takes the max, integrity takes the min ^[5]. Min is the half that does the work. An UNTRUSTED value joined with a SYSTEM intent stays UNTRUSTED, so taint does not wash out on the way to the sink ^[5]. Reads take their label from the path they touch, which is why reading repo text yields UNTRUSTED and reading a system file yields SYSTEM ^[6]. The propagation works this way regardless of whether a trigger word appears anywhere.

That is the point of the scenario the project added. A plan reads a planted `README.md` and writes `incident-report.md` sourced from `env.SECRET`, with the write depending on the read ^[9]. The old heuristic sees nothing, because the planted README contains none of its five hard-coded phrases ^[9][8]. The lattice denies on both axes, integrity from the README and confidentiality from the secret ^[9]. There is a test that re-runs the v0.1 scan over the materialized repo and asserts it reports no escalation, which is how you keep an eval from being vacuous ^[10].

Now the part that decides whether you can use it. `run_admission()` takes an explicit description of what the agent proposes to do and returns a verdict with a reason ^[2], and the planner emits one Plan per query ^[15]. The plan is supplied rather than observed: it is a library you call, and it does not watch a live agent the way a runtime firewall would ^[3]. So the verdict is exactly as complete as the dependency graph the planner declared, and the planner is the same component reading untrusted web pages, docs and tool output while holding authority over deploy keys and secret stores ^[20]. Two things have to hold in your harness before the lattice means anything: plan emission has to be harder to corrupt than action selection, and nothing may execute outside the admitted plan. Both conditions sit outside anything the library itself can guarantee.

On coverage, the numbers are small and stated. The suite covers three scenarios ^[11]. The harness study the post cites evaluated 13 attack objectives across 6 real coding-agent frameworks ^[14]. Three over thirteen is 23 percent ^[19], and only if each scenario maps to a distinct objective, which the post does not claim. Read the three passing tests as evidence that the mechanism behaves as described, not as a detection rate.

The audit is the best-engineered thing in the release. A fresh clone in a clean venv reproduced a defect introduced during the build: `_step_initial_label` returned (PUBLIC, SYSTEM) for every read, so propagation through `depends_on` only worked because of magic prefixes baked into `value_source` ^[16]. That is the standard way a taint tracker passes its own tests, with the fixtures carrying the labels the code failed to derive. The fix classifies the read by path, and a regression test now fails if the bug returns ^[17]. The audit also caught the CI regression the fix caused, a bandit B108 finding and a missed `ruff format`, both closed before merge ^[18].

One housekeeping note. The three papers the argument rests on are cited as arXiv:2608.27234, arXiv:2608.27141 and arXiv:2608.27299 ^[12][13][14], all sharing the 2608 prefix ^[21]. Resolve them yourself before you repeat the framing downstream.