the guard that blocks the class, not the instance

A credential reached a repository. The usual response is to remove it, which is necessary and mostly useless: the value is in the history, in the clones, in the mirrors, and in everyone's working copy. What was added alongside the removal is a pre-commit check that refuses a staged change containing a credential of a recognized class — a long hexadecimal string in a credential context, provider-shaped tokens, cloud keys, private key blocks, session tokens — plus an install record showing the guard live across every working copy, verified for both the blocking and the clean case.

The detail that separates a guard from a nuisance is the false-positive suite. Nine cases were tested, including one deliberately constructed to look exactly like a long key while being benign, and the guard's behaviour on it was decided rather than discovered. A guard with no false-positive story gets disabled by the first person it blocks, and then it protects nothing while appearing to exist.

What the guard does not do is stated plainly. It inspects what is staged, so it sees nothing written straight to a branch, nothing in a generated artifact that never passes through it, and nothing already in history. Scrubbing the history is a separate plan with a go/no-go list, deliberately not executed — a decision that costs credibility and buys the ability to be trusted about everything else.

What it proves: prevention was placed at the boundary where it is cheap, detection was kept for the places the boundary cannot see, and the gap between the two was written down instead of assumed away.