A maintenance script updates your permissions table and every user in one tenant can suddenly edit everything. What should have stopped that, and how would you have found out?

Short answer

Permission data is as privileged as the code that reads it, so a bulk write to it needs the same review, staged rollout and reversibility as a deploy. Derive grants from a source of truth rather than stamping them, assert tenant invariants continuously, and know how long a cached decision keeps the mistake alive.

This is an authorisation failure with an audit logging requirement. Good authorisation design asks who can grant access, who can approve it, and what blast radius a script can create. Audit logging matters because authorisation mistakes must be reconstructable after the fact: which principal acted, what permission changed, who approved it, and which tenant was affected. Weak authorisation answers fix the script but leave audit logging unable to prove what happened.