Two roles is one too few
Systems ship with a user role and an admin role, and the business immediately needs something in between — a manager who can refund but not delete, support who can view but not export. The usual answer is to give them admin.
Over-granting is the default failure
Admin gets handed out because the alternative is a development ticket. Six months later most of the company has full access, and nobody can say who should — which makes what any automated agent may do impossible to scope too.
Every “just make them an admin for now” is a permission model decision made permanently, by default.
Model capabilities, not job titles
Roles named after departments go stale as the organisation changes. Permissions expressed as capabilities — view, edit, approve, export, delete — compose into roles and survive reorganisation.
Separate destructive from routine
Deletion, export, and financial actions deserve their own permissions regardless of role, and ideally a second confirmation. This is the same reasoning as making irreversible actions structurally unavailable to an AI teammate.
Log privileged actions separately
Who exported the customer list, who changed a price, who deleted the record. These belong in an audit trail distinct from application logs, and they are the first thing anyone asks for after an incident — the record that makes a decision explicable.
Review access on a cycle
Permissions accumulate as people change roles and never lose the old ones. A twice-yearly review of who has what is unglamorous, quick, and the only thing that stops the slow drift toward everyone being an admin.