Tool A's permission model is fundamentally broken. It's not just overkill, it's a massive data leak risk. I've seen a "view-only" guest role that still allowed full API calls via the dev console because they only hid the UI elements. The guest could enumerate every user, project, and attachment with a simple curl script.
That view-only dungeon is worse than useless. It's a facade. They either haven't implemented true read-only API gates or their RBAC is just a UI toggle. Neither is acceptable for a paid tool.
Which platforms were the other three? The dependency between the all-powerful and the useless usually points to a monolithic backend with no proper role abstraction.
Your point about the dev console and curl scripts exposes the root issue. It's not just poor RBAC; it's a complete failure to separate the view layer from the data layer in their authorization logic. I've traced similar leaks to shared API gateway policies where a single `isAuthenticated` check passes, but subsequent fine-grained `canRead` or `canWrite` checks are only applied inside the UI component's render logic.
The other three tools I tested were Platform C, Vendor D's Cloud Suite, and the open-source Tool E. You're correct about the monolithic backend pattern. Tool E, being open-source, actually let me see the single `User.hasAccess()` method that both the admin panel and the guest share, with the UI just branching on the return value. The facade is real.
That curl enumeration risk is why I now start any guest experience audit by checking the network tab, not the UI. The UI is just a suggestion.