Audit a deny-list from the threat, not from the list

Governance auditModel-agnosticupdated 2026-08-28sha ec6ef37c6c32

Every deny-list is written by reading the deny-list. Someone adds a recursive delete, someone adds a history-rewriting push, and the list grows in the shape of what people already thought of. The holes are the commands nobody typed while writing it. The only way out is to stop reading the list and start from the danger, then come back and see what is missing.

You are auditing a deny-list, allow-list, or blocked-pattern set for completeness. Read the list LAST, not first. Reading it first anchors you to what someone already thought of, which is exactly the set that has no holes.

THE LIST: {{list_files}}
WHAT IT EXISTS TO PREVENT: {{threat}}
HOW TO RUN THINGS: {{verify_cmd}}

STEP 1 - Enumerate from the threat, with the list unread.
Given only {{threat}} and the system this runs in, write the set of actions that would cause it. Group them by MECHANISM, not by command name: destroying data, escaping the intended scope, exfiltrating something, making an irreversible external change, disabling the control itself, exhausting a shared resource.
- For each mechanism give the concrete ways to achieve it here - real commands, real API calls, real paths.
- Include the ways that reach the same end by a different route: an alias, a wrapper script, a flag on an otherwise-safe command, the same operation through a different tool, the same effect achieved in two steps.
- Do not include anything the system cannot actually do. State the capability you are assuming for each entry, and drop the ones you cannot ground.

STEP 2 - Now read the list, and diff.
Produce three groups:
- COVERED: your entry, the list rule that catches it, and the file:line.
- MISSING: your entry, with no rule that catches it. This is the finding. Rank by damage.
- ON THE LIST BUT NOT IN YOUR SET: why is it there? Either you missed a mechanism (go back and add it) or it is stale. Say which.

STEP 3 - Prove the existing rules actually fire.
A rule in a file is not a control until something enforces it.
- For each rule, find the code that reads it. Give file:line. A rule nothing reads is dead - report it as a hole, not as coverage.
- For the highest-damage rules, trigger them safely and paste the real output showing the refusal. Where you cannot trigger one safely, mark it UNPROVEN and say why.
- Check matching semantics: is it substring, exact, glob, or regex? Name one input that a human would expect to be caught and that the actual matching lets through. Whitespace, quoting, case, path traversal, unicode look-alikes, and an equivalent command with a different name are the usual escapes.

STEP 4 - Say what shape of control this is.
In two sentences: is a deny-list right here, or would an allow-list be strictly safer? If an allow-list would be safer, say so plainly even though it is out of scope for this audit. Do not silently perfect the weaker design.

RULES.
- Label every claim OBSERVED (you ran it, output pasted) or INFERRED (you read it and reasoned). Do not present the second as the first.
- Do not report a MISSING entry you cannot tie to a real capability of this system. A plausible-sounding hole that cannot happen here wastes the reviewer and devalues the real ones.
- If the list is genuinely complete against your enumeration, say so, then state the one mechanism you were least able to enumerate and why.

END WITH: the highest-damage missing entry, the highest-damage UNPROVEN rule, and whether you would block a release on either.

Fill in: list_files threat verify_cmd

Shared as is, for reference. Read it and decide what it will do before you run it; using it is your responsibility, under the terms.