---
name: a-positive-control-must-cross-the-boundary-the-guard-faces
description: "hertz 2026-09-08 — 15 green positive controls shipped a guard that was blind to the one process class it existed to catch; a control fired inside your own security context proves the guard FIRES, never that it SEES"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 468c4c6e-2bd4-4c75-bb45-2cdfaa9a32d5
  modified: 2026-09-08T15:52:16.826Z
---

Shipped a clippy driver whose holders guard keys on `ExecutablePath -like '*<lane>*'`, with a positive-control suite that fired every arm on purpose — 15/15 green, including A6 "holders guard REFUSES", which injected a matching process and confirmed exit 5. Twenty minutes later doyle attributed the golden runner's own cargo (57412) by parent chain and it was invisible to that key: WMI returns an EMPTY STRING, not an error, for `ExecutablePath`/`CommandLine` on a process the querying user cannot fully open. 219 of 632 processes box-wide were in that class, all SessionId 0 service context — where the Actions runner's builds live. So the guard read EMPTY as "no holders" and would have built into a contended pool: a false clean in a REFUSING guard, which is the exact defect class the same script had just been rewritten to eliminate.

**Why:** A6 injected its match in MY OWN session, so it exercised the guard on the near side of the boundary the guard would actually face. It proved the predicate can MATCH. It could not, even in principle, prove the predicate can SEE — the control and the blind spot shared a security boundary, so the control was structurally incapable of detecting the blindness. "Every guard needs a positive control" (the day's own banked remedy) is necessary and NOT sufficient: a suite can be all-green and all-near-side. The tell is that the suite never once constructed the adversary the guard was written for.

**How to apply:** before calling a guard proven, name the boundary it exists to cross — security context / session, machine, user, process tree, encoding, filesystem, privilege — and ask whether ANY control instance was born on the far side. If none was, the suite proves firing, not seeing; say so in the report rather than banking a green. When the far side cannot be constructed cheaply (you cannot spawn a session-0 process to order), do NOT settle for the near-side control: put the far-side case behind an env seam and drive the real code path with injected far-side data (`SPT_CLIPPY_FAKE_UNREADABLE="111,222"` did this in three arms), then make the guard THREE-VALUED so the unreadable case has its own name — readable-match REFUSES, unreadable is reported as UNDETERMINED and does not refuse, and empty on the readable line reads "none I could read", never "none". No stronger predicate fixes this: nothing reads what the OS will not open. Scope the finding before reporting it — this bit an agent-written census, NOT core (`crates/spt-store/build.rs` has no process census; POOL_GUARD arbitrates on the claim record and lane git identity, immune by construction). Related: [[an-absence-is-data-only-if-it-has-a-way-to-appear]], [[a-path-predicate-builder-census-is-intermittently-blind]], [[negative-control-must-mutate-every-encoding]], [[pre-seed-the-exit-file-with-a-void-sentinel-before-the-leg-starts]], [[presence-control-scoped-to-the-faults-population]].