Unmatched tools default to allow, not deny.
const DEFAULT_DECISION: GateDecision = "allow";That is the wrong default for production, and project #3 says so in the file itself rather than pretending otherwise. It is worth understanding why it is the right default here, because the reasoning is about people rather than about security.
Default-deny is safer, and it has a failure mode
Set that constant to "ask" and every unclassified tool stops and asks a
human. Strictly safer. Nothing unexpected can happen.
Now run it.
An approval gate that trains you to click Approve reflexively is worse than no gate at all — because it also gives you the feeling of having one.
That second clause is the whole argument. A system with no gate makes you careful. A system with a gate you have learned to dismiss makes you careless and confident, which is strictly worse than either.
The real variable is how many prompts per hour
Framed properly, this is not a security-versus-convenience trade. It is a question about the quality of the attention each prompt receives, and that quality collapses as frequency rises.
| Prompts per session | What a human actually does |
|---|---|
| 1–2 | reads the arguments, thinks, decides |
| ~10 | skims the tool name, decides on vibes |
| 50+ | clicks Approve as a way of dismissing a dialog |
So the design goal is not "stop as much as possible." It is stop rarely enough that every stop gets read.
Which reframes the rule list from a denylist into a budget: you have a small number of interruptions to spend per session, and each rule you add spends some.
When you should flip it
The honest answer, and it is one line either way.
Keep default-allow when…
- the toolbox is small and you wrote most of it
- most tools are reads
- you can enumerate the dangerous ones
- the blast radius of a miss is a cookie jar
Flip to default-deny when…
- real money or real infrastructure
- tools arrive from servers you did not write
- the toolbox changes without your involvement
- you cannot enumerate what is dangerous, because you do not know what will be added next
That last one on the right is the real trigger, and it is worth stating separately.
If you flip it, the work is not the one-line change. It is building the allowlist of safe tools carefully enough that the prompt rate stays under the threshold where people still read them.
Say the tradeoff out loud
The thing project #3 actually gets right here is not the choice. It is that the choice is written down, in the file, with its reasoning and its escape hatch.
A default buried in a config object is a decision nobody made. A default with forty lines of comment above it explaining what it costs and when to change it is a decision somebody can revisit — including you, in six months, having forgotten every part of this.