Security controls are usually judged by whether they exist and whether their tests pass. This paper examines a failure that both measures miss: a control that is present and looks correct in review, often with a green continuous-integration run, yet enforces nothing. It draws on 19 cases in 19 open-source projects: 18 from the author's public review work in August and September 2026 and one private disclosure. Thirteen are in access control or AI-agent tooling; six are in test, CI or deployment configuration and are included for their shape, not as security findings. Six shapes appear: tests and gates that cannot fail; degenerate inputs that fail open; integrity checks that read the wrong fields; gates keyed on the wrong identifier; configuration that nothing reads; and enforcement the rest of the system cannot see. Seventeen of the 19 have a fix, a test or a normative change merged in the project, and the other two were confirmed in writing. For each shape the paper gives a probe aimed at it, needing no special tooling: delete the control and re-run the suite, feed a known positive, sweep the degenerate inputs, trace which code consumes each field, substitute the identifier, and check what runs before the rule. The probes are not evaluated as detectors. The paper reads the cases through one lens: each control was accepted without evidence that it could fail. The probes are ordinary engineering; what they require is the habit of testing the control itself rather than the code it guards.
No takes yet. Share an insight, caveat, or question.
Santosh Kumar Puppala (2026) studied this question.
Synapse has enriched 5 closely related papers on similar clinical questions. Consider them for comparative context: