Fix the two reasons a consumer hand-rolled a control we publish

[hseshadr]

What happened

On 2026-08-02 the scheduled Consumer drift sweep went red for the first time since it shipped:

30 hand-rolled control(s) across 7 repo(s); 29 allowlisted; 1 new

run 30739082151. The 08-01 run read 29 … 0 new, so the window is one day.

The new control: aml-filter / .github/workflows/ci.yml / secret-scan, introduced by aml-filter#89 (2026-08-01).

That PR closed a real hole. aml-filter's gitleaks scan ran only in its weekly security-audit.yml sweep and never on a pull request, so a secret could merge and sit in public history for up to seven days. It closed that hole by inlining gitleaks/gitleaks-action — the exact control this repo publishes as secret-scan.yml, at the identical pinned action SHA. A security fix shipped by hand-rolling the shared brick.

Why — and it is partly our fault

secret-scan.yml was a genuine drop-in: no required inputs, same action SHA, and examples/aml-filter/security-audit.yml already showed aml-filter calling it. So part of the cause is habit. But two parts were ours, and both are fixed here.

#	ci-side cause	Fix in this PR
1	examples/aml-filter/ci.yml had no secret-scan job. The worked example we publish for the exact file being edited offered nothing to copy.	The example now carries the caller.
2	Nothing warned that adopting renames the check run. A caller job reports as <caller job> / <called job>. aml-filter's branch protection requires a context named literally gitleaks; adopting makes it Secret scan / gitleaks and blocks every merge until protection is updated.	New README section Adopting a reusable workflow renames its check run, plus the warning inline in the example.

Cause #2 is the interesting one. It is a real cost of adoption, paid by the person converging and invisible to the person who published the brick. Inlining never renames anything. Verified against this repo's own dogfood job, whose check run is literally Secret scan (own brick) / gitleaks.

Adoption is the fix, not an exemption

The consumer is converging — see the aml-filter PR linked below. The allowlist entry added here is a pointer to that open PR, not an exemption: it carries the full reason, and is marked for deletion when that PR lands. A stale entry warns and never fails, so deleting it early is free.

The detector was not weakened

It still exits 1 on any un-allowlisted control. What this PR adds is a regression test for the property the finding depended on.

aml-filter/ci.yml/frontend-gate has been allowlisted since 2026-07-26. Had the allowlist key been read at file granularity, that older entry would have swallowed the new secret-scan control and the sweep would have reported a clean run on the day it mattered most.

Proven by mutation, not asserted. Widening allowlist_index to compare <repo>/<workflow>:

halfknown  ci.yml  dependency-audit  DRIFT (allowlisted)
2 hand-rolled control(s) across 1 repo(s); 2 allowlisted; 0 new     <- new control swallowed, exit 0

and the new cases go red:

FAIL: an allowlisted control does not cover a second control in the same file (exit 0, expected 1)
FAIL: the un-allowlisted control in a partly-allowlisted file is named as NEW

Detector restored byte-identical; suite green again.

On the Dagger question

The 2026-07-31 decision not to adopt dagger.io set a disconfirming test: attempt the convergence sweep, and if new hand-rolled controls reappear within 60 days, the model is the problem, not the backlog.

This is not that test firing. Its precondition was never met — no drafted caller had been adopted, so nothing could "reappear" after converging, and one new control cannot tell "the model is wrong" apart from "nobody has run the sweep yet". The narrower true statement, recorded in the README: drift accrued while convergence had not started. One new control out of thirty, from a PR fixing a real security gap, does not re-open Dagger on its own. It is recorded so the next one lands on a record instead of a blank page.

Evidence

Check	Result
tests/security-policy.sh	passed
tests/consumer-drift-cases.sh	passed (3 new cases)
tests/example-fidelity-cases.sh	passed
tests/lineage-guard-cases.sh	passed
shellcheck -x	clean
actionlint (examples)	clean
zizmor 1.26.1 (examples, online)	no findings
example fidelity	173 resolved, 0 MISSING, 0 UNVERIFIABLE, 7 repos
guard can fail	shown red above

Not merging

Paired with the converging PR on hseshadr/aml-filter. Note that the aml-filter PR requires a branch-protection update (the gitleaks required context becomes Secret scan / gitleaks) — that is an owner action and is spelled out in that PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_0186xrrT9mYfCZTVkk8HN12p

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.