The direction of the default decides the failure mode
Fail-safe defaults require that, absent explicit configuration, a system defaults to denying access rather than granting it — a new resource, a new feature, a new integration point starts out closed and requires a deliberate action to open, rather than starting open and requiring a deliberate action to close. This is a decision entirely about which direction a forgotten step fails toward: an unconfigured resource under a deny-by-default system stays inaccessible; the same oversight under an allow-by-default system stays quietly exposed.
An implicit grant is exactly the pattern fail-safe defaults are meant to prevent — access that exists purely because nothing explicitly denied it, rather than because anyone deliberately assigned it. Every new addition to a system inherits whichever default is in force, whether or not anyone thinks about it at the moment of adding it.
Why this has to be a platform-level default, not a habit
Relying on every individual engineer to remember to restrict access on every new resource, every time, doesn't scale — habits lapse under deadline pressure and across a large enough team, reliably. Setting deny-by-default at the platform level means the safe outcome happens automatically when someone forgets, rather than only when everyone remembers, which is the entire practical value of the principle over simply asking people to be careful.